(57)【要約】【課題】相手の電話番号と名称のほかに詳細なプロフィールデータを得ることができる通信端末装置を提供する。【解決手段】発呼側はＩＮＶＩＴＥ信号を送信すると共にプロフィールデータを送信する。着呼側はＩＮＶＩＴＥ信号を受信し（Ｓ２１）、プロフィールデータを受信すると（Ｓ２２、Ｙｅｓ）、１８０  ＲＩＮＧＩＮＧ信号を送信する（Ｓ２３）。次に受信したプロフィールデータを検査し（Ｓ２４）、検査結果が所定の基準を満足している場合は（Ｓ２５、Ｙｅｓ）、オフフックされると（Ｓ２６、Ｙｅｓ）、２００  ＯＫ信号を送信して通信チャネルが確保され通信が可能になる（Ｓ２７）。プロフィールデータを受信できなかった場合（Ｓ２２、Ｎｏ）、及び検査結果が所定の基準を満足していない場合（Ｓ２５、Ｎｏ）は、ＢＹＥ信号を送信して（Ｓ２８）、通信を拒否（呼設定終了）する。受信したプロフィールデータを表示することで相手側のプロフィールを知り、通信の許可・拒否を決めることができる。【選択図】図６
2006345542.tif 000002
【特許請求の範囲】
【請求項１】
呼設定用制御信号と相手装置に表示させる自装置のソフトタグ情報を送信する呼設定手段を備えたことを特徴とする通信端末装置。
【請求項２】
前記呼設定手段は、前記ソフトタグ情報を含んだ呼設定用制御信号を送信することを特徴とする請求項１記載の通信端末装置。
【請求項３】
前記呼設定手段は、前記呼設定用制御信号の送信とは別に、前記ソフトタグ情報を送信することを特徴とする請求項１記載の通信端末装置。
【請求項４】
前記呼設定手段は、前記呼設定用制御信号を送信した後に、前記ソフトタグ情報を送信することを特徴とする請求項１記載の通信端末装置。
【請求項５】
前記呼設定手段は、前記呼設定用制御信号を送信する前に、前記ソフトタグ情報を送信することを特徴とする請求項１記載の通信端末装置。
【請求項６】
前記呼設定手段は、前記相手装置から前記ソフトタグ情報の送信を要求する信号を受信した場合に、前記ソフトタグ情報を送信することを特徴とする請求項１から５のいずれか１項に記載の通信端末装置。
【請求項７】
相手装置に対してソフトタグ情報の送信を要求する信号を送信する呼設定手段を有することを特徴とする通信端末装置。
【請求項８】
前記呼設定手段は、前記相手装置から呼設定用制御信号を受信した後に、前記相手装置に対して前記ソフトタグ情報の送信を要求する信号を送信することを特徴とする請求項７記載の通信端末装置。
【請求項９】
前記相手装置から受信した前記ソフトタグ情報に基づいて前記相手装置のソフトタグを自装置に表示するソフトタグ表示手段を備えたことを特徴とする請求項７又は８の通信端末装置。
【請求項１０】
前記ソフトタグ情報を受信できなかった場合、又は受信したソフトタグ情報を検査し、所定の内容を満たさなかった場合には、相手装置に呼設定を拒否する通信接続判断手段を備えたことを特徴とする請求項７から９のいずれか１項に記載の通信端末装置。
【請求項１１】
前記ソフトタグ表示手段によって前記相手装置のソフトタグ情報を表示するとともに、前記受信したソフトタグ情報に基づいて相手装置の呼設定を拒否するか、呼設定を行うかを決定する通信接続判断手段を備えたことを特徴とする請求項７から１０のいずれか１項に記載の通信端末装置。
【請求項１２】
相手装置から受信した前記ソフトタグ情報を記憶する着信履歴手段を備えたことを特徴とする請求項７から１１のいずれか１項に記載の通信端末装置。
【請求項１３】
前記着信履歴手段の前記ソフトタグ情報を電話帳手段に登録する電話帳登録手段を備えたことを特徴とする請求項１２記載の通信端末装置。
【請求項１４】
前記相手装置の電話番号を検出する電話番号検出手段を備え、前記電話番号検出手段が検出した前記相手装置の電話番号のうち、プロバイダを示す番号に応じてそれに対応するプロバイダの名称又はそれに相当する情報、あるいは前記プロバイダで使用することができる機能の名称又はそれに相当する情報の少なくとも一方を報知する報知手段を備えたことを特徴とする請求項１から１３のいずれか１項に記載の通信端末装置。
【請求項１５】
前記ソフトタグ情報はレイアウト情報とプロフィールデータのうち少なくとも１以上から構成されていることを特徴とする請求項１〜１４の通信端末装置。
【請求項１６】
前記ソフトタグ情報はＭＬ（マークアップ・ランゲージ）言語で記述されたテキストファイルであることを特徴とする請求項１〜１５のいずれか１項記載の通信端末装置。
【請求項１７】
前記ソフトタグ情報はソフトタグ情報が存在するＵＲＩ情報であることを特徴とする請求項１から１６のいずれか１項に記載の通信端末装置。
【請求項１８】
前記ソフトタグ情報の送信は、ＨＴＴＰプロトコルを使用して送信することを特徴とする請求項１から１７のいずれか１項に記載の通信端末装置。
【請求項１９】
前記呼設定制御信号の送信は、呼制御用プロトコルを使用して送信することを特徴とする請求項１から１８のいずれか１項に記載の通信端末装置。
【請求項２０】
標準呼制御用プロトコルを使用して呼設定を行うと共に、前記標準呼制御用プロトコルとは別のローカルプロトコルによって呼設定を行うローカル呼設定手段を備えたことを特徴とする請求項１９記載の通信端末装置。
【請求項２１】
呼設定用制御信号と相手装置に表示させる自装置のソフトタグ情報を送信する呼設定処理をコンピュータに実行させるプログラム。
【請求項２２】
呼設定処理においては、前記相手装置からソフトタグ情報送信要求信号を受信した場合に前記ソフトタグ情報を送信することを特徴とする請求項２１記載のプログラム。
【請求項２３】
前記相手装置にソフトタグ情報の送信要求信号を送信する送信処理をコンピュータに実行させる請求項２１又は２２記載のプログラム。
【請求項２４】
前記相手装置から受信したソフトタグ情報を表示する表示処理をコンピュータに実行させる請求項２３記載のプログラム。
【請求項２５】
請求項２１から２４に記載のプログラムを記録したコンピュータ読み取り可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、自装置に関する情報を相手装置に伝える機能を有するＩＰ電話機等の通信端末装置に関する。
【背景技術】
【０００２】
従来の通信端末装置、特に電話機では電話をかけてきた相手が誰であるのか分からないという不具合があった。それを解決する手段としては、相手電話番号表示（いわゆるナンバーディスプレイ）や相手名称表示（いわゆるネームディスプレイ）等の各機能が知られている（例えば、特許文献１、２、３参照）。
【特許文献１】特開２０００−２１６８７５号公報
【特許文献２】特開２０００−２１６９０６号公報
【特許文献３】特開２００３−８７４３４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
しかしながら、上記各機能は単に相手の電話番号と相手の名称がわかるのみであり、相手についての詳細なデータを知る手段はなかった。また相手電話番号表示や相手名称表示もプロバイダの限定的なサービスであって、別のプロバイダでは使用できないなどの不具合があった。また相手電話番号や相手名称の表示の方法（表示の仕方）は、表示する装置側の表示用ソフトウェアの仕様によって決まるものであり、表示データを送る側からは表示方法を指定したり規定したりすることが出来なかった。
【０００４】
本発明は上記の問題を解決するためのもので、相手の電話番号と名称のほかに詳細なソフトタグ情報を得ることができる通信端末装置を提供することを目的とする。
【課題を解決するための手段】
【０００５】
上記の目的を達成するために本発明による通信端末装置は、請求項１では、呼設定用制御信号と相手装置に表示させる自装置のソフトタグ情報を送信する呼設定手段を備えたものである。
請求項２では、請求項１における前記呼設定手段が、前記ソフトタグ情報を含んだ呼設定用制御信号を送信するものである。
請求項３では、請求項１における前記呼設定手段が、前記呼設定用制御信号の送信とは別に、前記ソフトタグ情報を送信するものである。
【０００６】
請求項４では、請求項１における前記呼設定手段が、前記呼設定用制御信号を送信した後に、前記ソフトタグ情報を送信するものである。
請求項５では、請求項１における前記呼設定手段が、前記呼設定用制御信号を送信する前に、前記ソフトタグ情報を送信するものである。
請求項６では、請求項１から５において、前記呼設定手段が、前記相手装置から前記ソフトタグ情報の送信を要求する信号を受信した場合に、前記ソフトタグ情報を送信するものである。
【０００７】
請求項７では、相手装置に対してソフトタグ情報の送信を要求する信号を送信する呼設定手段を有するものである。
請求項８では、請求項７において、前記呼設定手段が、前記相手装置から呼設定用制御信号を受信した後に、前記相手装置に対して前記ソフトタグ情報の送信を要求する信号を送信するものである。
【０００８】
請求項９では、請求項７又は８において、前記相手装置から受信した前記ソフトタグ情報に基づいて前記相手装置のソフトタグ情報を自装置に表示するソフトタグ表示手段を備えたものである。
請求項１０では、請求項７から９のいずれか１項において、前記ソフトタグ情報を受信できなかった場合、又は受信したソフトタグ情報を検査し、所定の内容を満たさなかった場合には、相手装置に呼設定を拒否する通信接続判断手段を備えたものである。
【０００９】
請求項１１では、請求項７から１０のいずれか１項において、前記ソフトタグ表示手段によって前記相手装置のソフトタグ情報を表示すると共に、前記受信したソフトタグ情報に基づいて相手装置に呼設定を拒否するか、呼設定を行うかを決定する通信接続判断手段を備えたものである。
請求項１２では、請求項７から１１のいずれかにおいて、相手装置から受信した前記ソフトタグ情報を記憶する着信履歴手段を備えたものである。
【００１０】
請求項１３では、請求項１２において、前記着信履歴手段の前記ソフトタグ情報を電話帳手段に登録する電話帳登録手段を備えたものである。
請求項１４では、請求項１から１３のいずれか１項において、前記相手装置の電話番号を検出する電話番号検出手段を備え、前記電話番号検出手段が検出した前記相手装置の電話番号のうち、プロバイダを示す番号に応じてそれに対応するプロバイダの名称又はそれに相当する情報、あるいは前記プロバイダで使用することができる機能の名称又はそれに相当する情報の少なくとも一方を報知する報知手段を備えたものである。
【００１１】
請求項１５では、請求項１から１４のいずれか１項において、前記ソフトタグ情報はレイアウト情報とプロフィールデータのうち少なくとも１以上から構成されているものである。
請求項１６では、請求項１から１５のいずれか１項において、前記ソフトタグ情報をＭＬ(マークアップ・ランゲージ)言語で記述されたテキストファイルとしたものである。
請求項１７では、請求項１から１６のいずれか１項において、前記ソフトタグ情報をソフトタグ情報が存在するＵＲＩ情報としたものである。
請求項１８では、請求項１〜１７のいずれか１項において、前記ソフトタグ情報を、ＨＴＴＰプロトコルを使用して送信するようにしたものである。
【００１２】
請求項１９では、請求項１から１８のいずれか１項において、前記呼設定制御信号を、呼制御用プロトコルを使用して送信するようにしたものである。
請求項２０では、請求項１９において、標準呼制御用プロトコルを使用して呼設定を行うとともに、前記標準呼制御用プロトコルとは別のローカルプロトコルによって呼設定を行うローカル呼設定手段を備えたものである。
【００１３】
また、本発明によるプログラムは、請求項２１では、呼設定用制御信号と相手装置に表示させる自装置のソフトタグ情報を送信する呼設定処理をコンピュータに実行させるものである。
請求項２２では、請求項２１において、呼設定処理では前記相手装置からソフトタグ情報送信要求信号を受信した場合に前記ソフトタグ情報を送信するものである。
請求項２３では、請求項２１又は２２において、前記相手装置にこの相手装置のソフトタグ情報送信要求信号を送信する送信処理をコンピュータに実行させるものである。
請求項２４では、請求項２３において、前記相手装置から受信したソフトタグ情報を表示する表示処理をコンピュータに実行させるものである。
また、本発明によるコンピュータ読み取り可能な記録媒体は、請求項２１〜２４に記載のプログラムを記録したものである。
【００１４】
［作用］
従って、請求項１、２１によれば、相手装置のソフトタグ情報（プロフィール）を手に入れることができるので、通信する必要がある相手かどうか判断することができる。
請求項２によれば、ソフトタグ情報を呼設定用制御信号に含ませて送信しているので、呼設定用制御信号とは別の信号でソフトタグ情報を送信する必要がない。
請求項３、４、５によれば、呼設定用制御信号とは別にソフトタグ情報を送信するので、呼設定プロトコルとは別のプロトコルを使用することにより、よりフレキシブルなデータ送信ができる。
【００１５】
請求項６、２２によれば、ソフトタグ情報の送信要求に基づいてソフトタグ情報を送信しているので、通常の呼設定制御方式しか対応していない装置に対して無意味なデータを送信しなくてすむ。
請求項７、８、２３によれば、ソフトタグ情報を入手することができる。
請求項９、２４によれば、ソフトタグ情報を表示しているので、装置の使用者は相手先のプロフィールを見ることができる。
請求項１０、１１によれば、通信する必要がない相手装置に対して通信を拒否することができる。
請求項１２によれば、過去の着信履歴を確認することができる。
請求項１３によれば、ソフトタグ情報を確認することができる。
【００１６】
請求項１４によれば、プロバイダ名を知ることができるので、トラブル等があった場合には、プロバイダ名を特定し苦情を言う等の対応ができる。また同じプロバイダであれば、固有の機能を使用できるとか、電話料金が安い等のサービスを受けることができるため、それに応じた装置の使い方ができる。
請求項１５によれば、レイアウト情報を送信するので、相手装置に表示するソフトタグ情報の表示方法（レイアウト）を指定することができる。
請求項１６によれば、テキストベースのファイルなので、人間にとって理解しやすく扱いやすい。
請求項１７によれば、装置にソフトタグ情報を持つ必要がないため、メモリを節約できる。またサーバに登録すると公証性が増す。
請求項１８によれば、ＨＴＴＰプロトコルは汎用性が高いので、多くの製品に搭載することができる。
【００１７】
請求項１９によれば、呼制御用プロトコルは汎用性が高いので、多くの製品に搭載することができる。
請求項２０によれば、標準の呼制御用プロトコルに定義されている標準の通信方式以外の独自の通信（通話）方式を使用することができるため、状況に応じた最適な通信を行うことができる。
請求項２５によれば、記録媒体は、本発明による通信端末装置において使用できると共に、通信機能を有する他の通信装置に適用することにより、本発明の効果と同等の効果を得ることができる。
【発明の効果】
【００１８】
本発明によれば、呼設定を行う場合に、呼設定用制御信号を送信すると共に相手装置に表示させる自装置のソフトタグ情報を送信するようにしたので、相手装置のソフトタグ情報を入手することができ、通信を行う必要があるか否かを判断することができる。従って、ソフトタグ情報に従来のように電話番号や名前だけでなく、より詳細な情報を持たせることにより、さらに適確に判断することができる。また、従来のように特定のプロバイダによるサービスではないので、本発明の機能を持っている通信端末装置であればどのような相手からもそのソフトタグ情報を得ることができる。さらに、表示データを送る側から受ける側に対して、表示方法を指定したり規定したりすることができる。
【発明を実施するための最良の形態】
【００１９】
図１３は本発明の実施の形態によるＩＰ電話機のブロック図である。
図において、ＣＰＵ（中央処理装置）１は、装置全体を制御するものであり、その実行プログラムはＲＯＭ（リード・オンリー・メモリ）２に記憶され、ＣＰＵ１はその実行プログラムをＲＯＭ２から読み出し、その実行プログラムに含まれる命令を逐次解釈して装置全体の制御を行うものである。ＲＡＭ（ランダム・アクセス・メモリ）３は、その制御に必要なワークエリアが形成されると共に、保存パラメータやそのほか制御に必要ないろいろなパラメータや管理情報等を記憶するものである。操作入力・表示部４は、各種の操作キーと操作ガイダンス等を表示する表示器からなり、オペレータが装置を操作するためのものである。
【００２０】
ハンドセット５は、音声通話をするいわゆる受話器であり、音声を出力するスピーカや音声を入力するマイク等から構成される。通話回路６は、マイク等から入力された音声信号をＩＰ制御部７に送出し、ＩＰ制御部７から入力された音声信号をスピーカ等に出力するものである。また音声信号を増幅したり、あるいは減衰することにより音量を調整したり、音声信号の周波数特性を変化させることにより音質を良くしたりする回路も含まれているのが一般的である。また送話器から受話器への音の回り込みを制御するいわゆる側音制御もこの部分で行うのが一般的である。
【００２１】
ＩＰ制御部７は、通話回路６から送られてきたアナログの音声信号をデジタルデータに変換し、さらに必要であれば符号化圧縮する。次に音声信号データを送信用のＩＰパケットに埋め込み、順次回線接続Ｉ／Ｆ８に送り出す。また回線接続Ｉ／Ｆ８から入力される受信用のＩＰパケットから音声信号データを取り出し、必要であれば復号伸張し、さらにデジタルの音声信号データをアナログの音声信号に変換し、通話回路６に送出する。
【００２２】
またＩＰ制御部７は、呼制御を行うための制御用ＩＰパケットを組立て、順次回線接続Ｉ／Ｆ８に送り出す。さらに回線接続Ｉ／Ｆ８から入力される受信した制御用ＩＰパケットを分解する。このような制御用ＩＰパケットの送出、受信はＩＰ制御部７とは独立した別の手段で構成してもよい。ＩＰ制御部７の動作制御はＣＰＵ１で行う。
【００２３】
回線接続Ｉ／Ｆ８は、ＩＰ制御部７から入力される送信用ＩＰパケットを接続回線に送出する一方、接続回線から入力される受信用パケットをＩＰ制御部７に送出する。接続回線としてＮＴＴ等が供給している一般の電話網を使用する場合には、デジタル信号とアナログ信号を相互に変換するＸＤＳＬモデムが回線接続Ｉ／Ｆ８に含まれる。また接続回線がＬＡＮ等であれば回線接続Ｉ／Ｆ８はＬＡＮ用のＩ／Ｆ（イーサネット（登録商標）、トークンリング、ＦＴＴＨ、無線ＬＡＮ等）である。また携帯電話、ＰＨＳ等の無線Ｉ／Ｆであってもよい。またその複数のＩ／Ｆのうち少なくとも１つ以上を備えていてもよい。
【００２４】
ソフトタグ情報送信制御部９は、本発明の特徴部分であり、自装置についての情報であるソフトタグ情報を相手装置に送信する制御を行うものである。ソフトタグ情報は、自装置の電話番号、名前のほかに、後述する詳しい内容を有するデータである。このソフトタグ情報は、不揮発性メモリ等の記憶装置に保存されているものとする。
【００２５】
図１４は本発明の実施の形態によるＩＰテレビ電話機のブロック図である。
ＣＰＵ１、ＲＯＭ２、ＲＡＭ３、操作入力部４、回線接続Ｉ／Ｆ８、通話回路６、ハンドセット５及びソフトタグ情報送信制御部９は、ＩＰ電話機と同じであるので説明は省略する。カメラ１０は被写体を次々に画像データに変換するものである。その画像データは画像処理回路１１で送信データ用に画像処理される。画像処理されたデータはＩＰ制御部７で符号化圧縮され、画像信号データを送信用のＩＰパケットに埋め込み、順次回線接続Ｉ／Ｆ８に送り出す。また回線接続Ｉ／Ｆ８から入力される受信用のＩＰパケットから画像信号データを取り出すと共に復号伸張し、画像処理回路１１に送出する。画像処理回路１１は画像表示部１２に合わせた画像処理を行い、画像表示部２２に画像データを送出し、画像表示部１２は画像データを連続的に表示することにより動画像を得ることができる。
【００２６】
次にＩＰ電話機やＩＰテレビ電話機で使用されるプロトコルについて説明する。
ここで、本発明における呼設定手段は、標準で規定されている標準用呼制御用プロトコル（ＳＩＰ，Ｈ．３２３、ＭＥＧＡＣＯ、ＨＴＴＰ等）を使用して呼設定を行い、通信（通話を含む）を可能にするものである。
【００２７】
図１５にＳＩＰのプロトコルスタックを示す。
図１５に示されるように、呼・セッション制御用プロトコルとしてＳＩＰを使用する場合、Ｎｅｔｗｏｒｋ  Ｌａｙｅｒ（ネットワーク層）においてＩＰ（Internet Protocol ）が使用される。またこの場合、Ｔｒａｎｓｐｏｒｔ  Ｌａｙｅｒ（トランスポート層）においてＵＤＰ（User Datagram Protocol）、ＴＣＰ（Transmission Control Protocol ）、又はＳＣＴＰ（Stream Control Transmission Protocol）が使用される。またこの場合、ＳＩＰメッセージを記述する制御情報記述プロトコルとしてＳＤＰ（Session Descripition Protocol ）が使用される。またこの場合、ＵＤＰ（トランスポート層）と共に、動画／音声の送受信プロトコルとして、ＲＴＰ（Realtime Transport Protocol ）が使用される。
【００２８】
図１６はＳＩＰの制御用パケットの構造を示す図である。図示されるように、ＳＩＰの制御用パケットには、ＩＰヘッダとＵＤＰ（ＴＣＰ）ヘッダとＳＩＰメッセージとが含まれている。
図１７はＳＩＰのデータ用パケットの構造を示す図である。図示されるように、ＳＩＰのデータ用パケットには、ＩＰヘッダとＵＤＰヘッダとＲＴＰヘッダと音声・画像データとが含まれている。
図１８はＵＤＰデータグラムの構造を示す図である。図示されるように、ＵＤＰデータグラムには、送信ポート番号と宛先ポート番号とデータ長とチェックサムとデータとが含まれている。
【００２９】
図１９はＳＩＰで使用されるＩＰデータグラムの構造を示す図である。図示されるように、ＩＰパケットの構成は、バージョン情報とヘッダ長情報とサービスタイプ情報とトータル長情報と識別子（ＩＤ）とフラグ情報とフラグメント・オフセット情報と生存時間（ＴＴＬ）情報とプロトコルタイプ情報とヘッダチェックサム情報と送信元アドレスと宛先アドレスとオプションとパディングとデータ領域とからなる。
【００３０】
図２０に標準の呼制御プロトコルのうちの１つであるＳＩＰの通信モデルのプロトコル図を示す。
まず、発呼側からＩＮＶＩＴＥと言うリクエストメッセージを送出する。ＩＮＶＩＴＥはセッションの起動信号であり、それには発呼側が受信可能なセッションの属性がＳＤＰで示されている。具体的には、発呼側の受信条件（コーデック、ポート番号等）と送信条件を提示するものである。着呼側はＩＮＶＩＴＥを受信し、呼び出し状態になったことを通知するために１８０  ＲＩＮＧＩＮＧを発呼側へ送信する。この１８０  ＲＩＮＧＩＮＧで着呼側の受信条件（コーデック、ポート番号等）と送信条件を提示してもよいが、通常は次の２００  ＯＫで提示する。
【００３１】
次に、着呼側が通話可能状態になったことを通知するために２００  ＯＫを発呼側へ送信する。それには着呼側が受信可能なセッションの属性がＳＤＰで示されている。この２００  ＯＫで着呼側の受信条件（コーデック、ポート番号等）と送信条件を提示する。次に発呼側がＡＣＫを着呼側へ送信し、これにより通信に利用可能な属性がネゴシエーションされる。ここでは、便宜上ここまでを接続フェーズと定義している。次にメディア（音声、画像、動画等）の転送が開始される。ここでは、このメディアの転送期間中を便宜上、データ送受信フェーズと定義している。通信を終了するときには止める側がＢＹＥ信号を送信することにより通信終了を要求し、それを受信した側は、その応答である２００  ＯＫ信号を送信して通信を終了する。ここでは、このフェーズを便宜上切断フェーズと定義している。
【００３２】
次に、本発明の実施の形態による呼設定手段について説明する。
図１に本発明の第１の実施の形態によるプロトコル図を示す。
図２０との違いは発呼側がＩＮＶＩＴＥ信号を送信した後に、発呼側のソフトタグ情報をソフトタグ情報送信制御部９により着呼側へ送信していることである（請求項１、４・・・請求項１、４に関連する記載であることを示す。以下（）内同じ）。
尚、ＩＮＶＩＴＥ信号を送信する前にソフトタグ情報を送信してもよい（請求項１、５）。
ソフトタグ情報送信制御部９は、専用のハードウェアで構成されていてもよいし、ＣＰＵ、ＲＯＭ、ＲＡＭと若干のハードウェアで構成されていてもよい。ソフトタグ情報は不揮発性メモリなどの記憶装置に記憶されているのが通常である。
その他の動作については図２０と同様に行われる。
【００３３】
図２に本発明の第２の実施の形態によるプロトコル図を示す（請求項３、４、６、７）。
図１との違いは着呼側がＩＮＶＩＴＥ信号を受信した場合に、発呼側に対してソフトタグ情報の送信を要求する信号を送信していることである。発呼側はその要求信号を受信するとソフトタグ情報を着呼側へ送信する。その他の動作については図１、図２０と同様に行われる。
【００３４】
図１及び図２では、呼制御用信号（ＩＮＶＩＴＥ信号やその他の信号）とは別にソフトタグ情報やソフトタグ情報の要求信号を送信しているが、呼制御用信号にソフトタグ情報やソフトタグ情報の要求信号を含ませて送信してもよい。具体的にはＩＮＶＩＴＥ信号のＳＩＰメッセージ部あるいは拡張部分にソフトタグ情報を乗せて送信する（請求項２）。
【００３５】
図３に本発明の第３の実施の形態によるプロトコル図を示し、図４はそのフローチャートを示す。
図３、図４において、着呼側は、ＩＮＶＩＴＥ信号を受信した後（Ｓ１）、ソフトタグ情報を要求する信号を送信する（Ｓ２）。その要求信号を受信した発呼側はソフトタグ情報を送信する（請求項８）。
【００３６】
次に着呼側は、ソフトタグ情報を受信したかを判断し（Ｓ３）、受信した場合は、ソフトタグ情報を検査し（Ｓ４）、検査の結果、通信（呼設定）の許可・拒否を判断する（Ｓ５）。拒否する場合及びソフトタグ情報を受信しなかった場合には、呼設定を拒否する信号（１００  ＮＧ）を発呼側へ送信して呼設定シーケンスを終了させる（Ｓ８）。検査がＯＫの場合には、ハンドセットがオフフックされると（Ｓ６、Ｙｅｓ）、通信（通話）チャネルが確保され、通信（通話）が可能になる（Ｓ７）（通信接続判断手段）（請求項１０）。
【００３７】
ソフトタグ情報の検査は、具体的にはエラーのない正しいデータであるかどうか、ソフトタグ情報として必要なデータの種類やそのデータが存在しているかどうか、そのデータが着呼側の所望のデータと一致しているかどうか、データファイルが所望の種類であるかどうか、データ形式が所望のデータ形式であるかどうか、あるいは通信を許可してもよい相手なのかどうか等のように、通信を許可するか拒否するかの判断の基準になる事項について検査する。
【００３８】
その判断方法は、装置が自動的に判断して通信を許可又は拒否してもよい（請求項１０）。
あるいは、ソフトタグ情報を操作・入力表示部４で表示してよい（請求項９）。この表示を見てユーザが判断し、通信の許可又は拒否を装置に入力するようにしてもよい（請求項１１）。
【００３９】
またソフトタグ情報の要求信号を送信しても、発呼側がソフトタグ情報を送信しない場合や、発呼側がソフトタグ情報を送信したが、途中でデータが壊れて、あるいは失われて正しいデータが受信できなかった場合も同様に通信の許可・拒否の判断基準になるものである。以上説明したように、通信接続判断手段は、受信したソフトタグ情報を検査し、検査結果に基づいて通信の許可・拒否の判断を行う。
【００４０】
次に、ソフトタグ情報について説明する。
ソフトタグ情報はプロフィールデータ（データ情報）とレイアウト情報（表示方法の情報）の少なくとも１以上で構成されるものである。
プロフィールデータは、装置についての情報（装置の種類（携帯電話、ＰＨＳ、ＩＰ電話、ＩＰ端末装置、一般加入者電話機、ファクシミリ装置、通信機能付コンピュータ、ＰＤＡ等）、装置の名称、装置のスペック、設置場所、使用環境、使用履歴、装置のプロフィール等）、装置使用者についての情報（名前、性別、生年月日、年齢、勤務先会社名、住所、趣味、プロフィール等）、画像（装置の画像、使用者の顔画像、動画像、その他の画像）、音声データ（音声メッセージ、ＢＧＭ、音楽等）等の装置の説明情報である。
【００４１】
また、それは単なる装置の説明情報だけではなく、Ｊａｖａ（登録商標）に代表されるようなスクリプトデータでもよい。またソフトタグ情報として単なるデータではなく、アプリケーションそのもののデータであってもよい。これらのスクリプトやアプリケーションは受信した通信端末上で実行され、前記装置の説明情報を表示してもよいし、別の機能（伝言メッセージの出力、アニメーションの動作、ゲームの実行等）を実行してもよい。またソフトタグ情報のファイルを複数持っていてもよく、どれを送信するかを予め優先順位設定手段で設定しておくか、あるいは全てを送信してもよい。
【００４２】
レイアウト情報はプロフィールデータを表示部に表示する方法（表示の仕方）を示す情報である。すなわち、プロフィールデータはレイアウト情報に基づいて相手装置の表示部に表示されるものである。レイアウト情報としては例えば文字の種類（フォント）、文字の大きさ、文字の色、文字の修飾、文字の表示位置、画像の表示位置、画像の大きさ、背景色、アニメーションの位置、アニメーションの大きさ等であって、具体的にはＸＭＬやＨＴＭＬのＭＬ言語で扱っているレイアウト情報である。
【００４３】
また、ソフトタグ表示手段は、装置の操作・表示部４等の表示手段にソフトタグ情報を表示するものである。すなわち前記ソフトタグ表示手段はソフトタグ情報のレイアウト情報に基づいてプロフィールデータを表示部に表示するものである。ソフトタグ情報がＭＬ（マークアップ・ランゲージ）ベースのファイル（ＸＭＬ、ＨＴＭＬ等）である場合には、Ｗｅｂブラウザがファイルを読み込み、表示データに変換する。また、ソフトタグ情報を音声に変換する変換手段を備え、アナログの音声に変換された音声信号をスピーカ、ハンドセットなどの音響手段から出力してもよい。
【００４４】
図２３に、プロフィールデータの表示例を示す。この例においては、プロフィールデータとともにメッセージボタン２３１及びスクリプトボタン２３２を表示するようにレイアウト情報が設定されている。メッセージボタン２３１は、音声メッセージを再生するためのボタンであり、ユーザがこれを押下することによって音声メッセージが再生される。スクリプトボタン２３２は、アプリケーションを実行するためのボタンであり、ユーザがこれを押下することによってスクリプトボタン２３２に関連付けられたアプリケーションが実行される。
【００４５】
また端末装置（発呼側装置、着呼側装置）は複数の自身の前記端末識別情報を設定できる。すなわち、端末装置は自局端末識別情報設定手段を備え、複数の自局の端末識別情報をメモリ等の記憶手段に記憶する。あらかじめ使用する自局の端末識別情報を設定しておき、発呼した時に使用する端末識別情報として設定されている端末識別情報が選択される。また、発呼前あるいは発呼後に、使用する自局の端末識別情報を選択することができる。発呼した後は、複数の自局端末識別情報から選択された自局端末識別情報を相手端末装置あるいは通信網側に送信する。端末装置は複数の自局の端末識別情報毎にソフトタグ情報を持つことができる。従って、選択された自局の端末識別情報に対応したソフトタグ情報が相手装置に送信されるものである。このように複数の自局端末識別情報毎にソフトタグ情報を持つことにより、自局端末識別情報毎にソフトタグ情報を使い分けることが出来て、利便性が向上する。
【００４６】
次に、本発明の第４の実施の形態について説明する。
本実施の形態は、着信があった通信の履歴を記憶する着信履歴手段を備えたものである（請求項１２）。着信履歴手段は、受信したソフトタグ情報をその他のデータ（相手先電話番号、相手先名称、相手先メールアドレス、相手先のＵＲＩ、ＩＰアドレス、受信日時、応答したかどうかを示すデータ、通信時間等）と共に記憶装置に記憶するものである。記憶された複数の着信について着信履歴手段を選択することにより、他のデータと共にソフトタグ情報も装置の表示部に表示される。また、着信履歴からの選択による発呼動作も可能である。さらに複数の自局の端末識別情報毎に着信履歴データを記憶することができる。あるいは、着信履歴データに端末識別情報を付加してもよい。
【００４７】
次に、本発明の第５の実施の形態について説明する。
本実施の形態は、予め複数の相手先の名称、電話番号、メールアドレス、ＵＲＩ、ＩＰアドレス、その他の情報をメモリ等の記憶装置（電話帳手段）に記憶しておく電話帳登録手段を備えたものである（請求項１３）。この電話帳登録手段に記憶された複数の登録データから任意の登録データを選択することにより、相手装置に発呼できる。また登録データを選択することにより、ソフトタグ情報やその他の情報も表示部に表示することができる。さらに複数の自局の端末識別情報毎に電話帳データを記憶することができる。あるいは、着信履歴データに端末識別情報を付加してもよい。
【００４８】
また、ソフトタグ情報編集手段は、ソフトタグ情報を新規に作成したり、あらかじめ作成してあるソフトタグ情報を編集するテキストベースのエディターである。データは表示部に表示され、入力手段を使用してデータを編集する。このソフトタグ情報編集手段は、発呼装置あるいは着呼装置に搭載されるものである。このようにソフトタグ情報編集手段によって、編集用の外部機器（パソコン等）を接続しなくても、ソフトタグ情報を作成し編集することが出来る。
【００４９】
図５に本発明の第６の実施の形態によるフローチャートを示す。本実施の形態は、図２にさらにソフトタグ情報の検査を行うようにした場合である。
発呼側は呼設定を行うためにＩＮＶＩＴＥ信号を着呼側に送信し、着呼側はＩＮＶＩＴＥ信号を受信すると（Ｓ１１）、発呼側に対してソフトタグ情報を要求する要求信号を送信する（Ｓ１２）。発呼側は要求信号を受信すると着呼側に対してソフトタグ情報を送信し、着呼側はソフトタグ情報を受信した場合には（Ｓ１３、Ｙｅｓ）、１８０  ＲＩＮＧＩＮＧ信号（リングバックトーンに相当する信号）を送信し（Ｓ１４）、ソフトタグ情報を受信しなかった場合には（Ｓ１３、Ｎｏ）、ＢＹＥ信号を送信して（Ｓ１９）、通信を拒否（呼設定を終了）する。
【００５０】
次に受信したソフトタグ情報を検査し（Ｓ１６）、検査の結果が所定の基準を満足していない場合には、ＢＹＥ信号を送信する（Ｓ１９）。満足している場合には、ハンドセット等でオフフックすることにより応答した場合には（Ｓ１７、Ｙｅｓ）２００  ＯＫ信号を送信することにより、通信（通話）チャネルが確保され、通信が可能になる（Ｓ１８）。またソフトタグ情報の検査がＯＫになってから１８０  ＲＩＮＧＩＮＧ信号を送信するようにしてもよい。
【００５１】
図６に本発明の第７の実施の形態によるフローチャートを示す。本実施の形態は、図１にさらにソフトタグ情報の検査を行うようにした場合である。
発呼側はＩＮＶＩＴＥ信号を送信すると共にソフトタグ情報を送信する。着呼側はＩＮＶＩＴＥ信号を受信し（Ｓ２１）、ソフトタグ情報を受信すると（Ｓ２２、Ｙｅｓ）、１８０  ＲＩＮＧＩＮＧ信号を送信する（Ｓ２３）。次に受信したソフトタグ情報を検査し（Ｓ２４）、検査の結果が所定の基準を満足している場合は（Ｓ２５、Ｙｅｓ）、オフフックされると（Ｓ２６、Ｙｅｓ）、２００  ＯＫ信号を送信することにより、通信チャネルが確保され通信が可能になる（Ｓ２７）。ソフトタグ情報を受できなかった場合（Ｓ２２、Ｎｏ）、及び検査の結果が所定の基準を満足していない場合（Ｓ２５、Ｎｏ）には、ＢＹＥ信号を送信して（Ｓ２８）、通信を拒否（呼設定を終了）する。尚、ソフトタグ情報の検査がＯＫになってから１８０  ＲＩＮＧＩＮＧ信号を送信するようにしてもよい。
【００５２】
図７に本発明の第８の実施の形態によるフローチャートを示す（請求項１４）。
本実施の形態は、電話番号検出手段を備え、相手装置あるいはネットワーク側から送信された相手装置の電話番号を受信するとともに、受信した電話番号を記憶装置に記憶するようにしたものである。
図７において、相手装置が自装置に対して発呼すると、接続されている回線網から呼制御用のＩＰパケットが到来し（Ｓ３１、着呼）、自装置はそれを検出して呼の制御を行う。次に電話番号検出手段により例えばＣＰＵ１がＩＰ制御部７の受信した制御用ＩＰパケットに相手装置の電話番号が埋め込まれているかどうかを検査する（Ｓ３２、Ｓ３３）。
【００５３】
電話番号が埋め込まれていれば、電話番号からプロバイダ名に対応している番号を抽出し（Ｓ３４、Ｓ３５）、次に操作・表示部４の表示器等（報知手段）は、例えばＣＰＵ１がその番号に対応しているプロバイダがあるかどうかメモリ内のテーブル（番号とプロバイダの対応テーブル）を検査し、あればそのプロバイダの名称又はそれに相当する情報を表示する。また、そのプロバイダが単独で行っていて利用できるサービスあるいは機能（留守番電話、転送、着信拒否、通話料金表示、着メロダウンロード、キャッチホン、複数電話番号、ファックスサービス等、他の電話サービス、機能）の名称又はそれに相当するものを表示器等に表示する。名称に相当するものとしては、名前等の他に、商号、商標、マーク、愛称、記号、略称、その他がある。またプロバイダの名称等を発声する音声データ等音による報知でもよい。
【００５４】
図８に本発明の第９の実施の形態による通信モデルの１つであるプロトコル図を示す（請求項１９）。
本実施の形態は、ローカル呼設定手段を備えたものである。このローカル呼設定手段は、標準呼設定プロトコルのセッションの属性の他に（重複して持っていてもいいが）、独自のセッションの属性である受信条件（コーデック、ポート番号等）と送信条件と、さらに標準呼設定プロトコルが持っていない、装置に関わる独自の情報（装置が装備している機能、装置の状態を示す情報、相手装置の設定を変更する情報、相手装置の機能を実行する情報等）をＩＰパケットに挿入し、それを相手装置に送信するものである。
【００５５】
図８において、まず発呼側装置は発呼する際に自装置に備えられているプロトコルを調査し、最初に送出するプロトコルとして優先設定されているプロトコルで通信を開始するため（この例では標準プロトコルが設定されている）、まず発呼側は標準のプロトコルであるＳＩＰのＩＮＶＩＴＥ信号を着呼側へ送信する。次にそのすぐ後にローカル呼設定手段により、ローカルプロトコルの１つであるｉｎｖｉｔｅ信号を送信する（以後、標準プロトコル信号を大文字で表し、それに相当するローカルプロトコル信号を小文字で表す）。
【００５６】
着呼側はＩＮＶＩＴＥ信号とｉｎｖｉｔｅ信号の両方を受信し（順次記憶装置に蓄えておくことにより複数の制御信号を受信することができる）、ｉｎｖｉｔｅ信号を選択するとともに、呼び出し状態になったことを通知するために１８０  ｒｉｎｇｉｎｇを発呼側へ送信する（もちろん場合によっては、例えば標準プロトコルを優先設定されている場合等、ＩＮＶＩＴＥ信号を選択してもよい）。この後の動作は標準プロトコルがローカルプロトコルに代わる以外は、図２０のプロトコルとシーケンスは同じである。
【００５７】
その他の独自の受信条件としては、前記の他に、装備している通信プロトコルの種類、呼設定の方式に関係するもの、ネゴシエーションに関係するもの、端末の通信能力、データの圧縮方式、デジタル化方式、プロトコルの種類、それに使用するＩＰパケットの種類、ＩＰパケットの構造、ＩＰパケットの定義、再送処理方式、エラー処理方式、セキュリティ方式等、通信条件に関するあらゆるものが考えられる。また標準プロトコルのＩＮＶＩＴＥ信号を送出する前に、すなわち最初からローカルプロトコルのｉｎｖｉｔｅ信号を送信してもよい。また、ＩＮＶＩＴＥ信号は接続フェーズまたはデータ送受信フェーズまたは切断フェーズの期間中のどこでも送信してもよい。
【００５８】
例えば、データ送受信フェーズの場合には、ユーザが例えば音声の品質がよくないとか、画像の品質がよくない場合に、高品質な方式に切り換えたい場合に、例えば端末の入力手段から方式を切り替える操作を入力した場合に、ｉｎｖｉｔｅ信号を送出することが考えられる。着呼側は標準プロトコルであるＩＮＶＩＴＥ信号に対して１８０  ＲＩＮＧＩＮＧ信号または２００  ＯＫ信号を送信した場合、すなわち標準プロトコルで接続（ネゴシエーションが成立）した後でも、接続フェーズまたはデータ送受信フェーズまたは切断フェーズの期間中にｉｎｖｉｔｅ信号を受信することができ、その場合は再びネゴシエーションをやり直すことになる。
【００５９】
装置に関わる独自の情報（装置が装備している機能、装置の状態を示す情報、相手装置の設定を変更する情報、相手装置の機能を実行する情報等）とは、具体的には、
・装置が装備している機能：Ｗｅｂブラウザ機能、ストリームデータ再生機能、テレビ電話機能、留守番電話機能、留守番録画機能、録音機能、録画機能、着信メモリ、リダイヤルメモリ、電話帳機能、発信元番号通知機能、発信者名称通知機能、着信拒否機能、着信メロディー変更機能、転送機能、キャッチホン機能等。
【００６０】
・装置の状態を示す情報：留守番電話がセットされている情報、留守番録画がセットされている情報、装置に不具合があることを示す情報、装置が使用されていることを示す情報、装置のなんらかの機能がセットされていることを示す情報等。
・相手装置の設定を変更する情報：留守番電話をセットあるいは解除する命令、留守番録画をセットあるいは解除する命令、装置に備わっている機能が動作するようにセットあるいは解除する命令等。
・相手装置の機能を実行する情報：留守番電話に録音されている音声を再生させ送信させる命令、留守番録画に録画されている画像を再生させ送信させる命令、着信メロディを変更させる命令等である。
【００６１】
次に、本発明の第１０、１１の実施の形態を説明する。
本実施の形態は、ローカル呼設定手段の他の例であり、標準呼設定手段で使用する標準プロトコルのＩＰパケットに、ローカル呼設定手段で使用するローカルプロトコルで使用する情報を含ませるものである。
図９に第１０の実施の形態を示す。ＳＩＰの制御用パケットのＳＩＰメッセージ部分に、ローカル呼設定手段で使用するローカルプロトコルで使用する情報（ローカルプロトコル情報）を含ませた例である。
【００６２】
また、ＩＰヘッダのオプションフィールドにローカルプロトコル情報を載せてもよい。ＳＩＰプロトコルのみしか対応していない端末はローカル部分を無視するため、ＳＩＰで呼制御を行うが、ローカル呼設定手段に対応している端末は、このローカル部分を解釈し、必要に応じてローカルプロトコルで呼制御を行うものである。すなわち標準のセッションからローカルなセッションに移行することができる。
【００６３】
図１０に第１１の実施の形態を示す。これはＳＩＰのデータ用パケットのＲＴＰヘッダ以下の音声、画像データを載せる部分に、ローカル呼設定手段で使用するローカルプロトコルで使用する情報を含ませた例である。またＩＰヘッダのオプションフィールドにローカルプロトコル情報を載せてもよい。ＳＩＰプロトコルのみしか対応していない端末はローカル部分を無視するため、ＳＩＰで呼制御を行うが、ローカル呼設定手段に対応している端末は、このローカル部分を解釈し、必要に応じてローカルプロトコルで呼制御を行うものである。すなわち標準のセッションからローカルなセッションに移行することができる。
【００６４】
このように独自のローカルプロトコルに対応している端末はＩＰパケットのどの部分にローカルプロトコル情報が載せられているのかは、あらかじめ認識しているので、ローカルプロトコルの搭載形態は任意に構成することができる。
またＩＰ端末は発呼側および着呼側にもなり得るように、発呼側および着呼側で使用する両方のプロトコルを備えているのが一般的である。
【００６５】
また、標準のプロトコルでセッションが開始されたのか、あるいは独自のプロトコルでセッションが開始されたのかを表示部に表示することができる。例えば「ＳＩＰ」「Ｈ．３２３」「独自方式」等の表示をする。ユーザはこれを見ることにより通信の状態あるいは使用できる機能等を知ることができる。また接続に使用したプロトコルによって使用できる機能等を表示することもできる。また、発呼する場合、相手装置がどのプロトコルを装備しているか分からない場合には、発呼端末が装備している複数のプロトコルまたはすべてのプロトコルのＩＮＶＩＴＥ又はｉｎｖｉｔｅ信号を順次送出することができる。
【００６６】
着呼側はその複数のプロトコルのうちの１つを選択し、その選択したプロトコルに相当する応答信号を１つだけ返信することができる。又は複数のプロトコルのうち複数のプロトコルを選択し、その選択した複数のプロトコルに相当する応答信号を複数返信することもできる。この場合、発呼側は優先順位の高いプロトコルを選択することができる。
このようにローカル呼設定手段を備えることにより、標準呼設定手段で使用出来る機能以外の機能を使用することが出来るので、利便性が向上する。またローカル呼設定手段はメーカ独自に作成し実装することができるため、さまざまな制約を受けることなく仕様を決定することが出来るという利点がある。
【００６７】
今まで説明してきたソフトタグ情報のデータフォーマットやファイル形式の種類などには特に言明してこなかったが、ソフトタグ情報は、どのような種類のデータであっても本発明に適用可能である。しかしながらソフトタグ情報をＸＭＬ、ＨＴＭＬ、ＳＧＭＬ、ＸＨＴＭＬ、ＣＨＴＭＬ、ＨＤＭＬ、ＤＨＴＭＬ等に代表されるＭＬ（マークアップ・ランゲージ）で記述されたデータファイル（テキストファイル）を使用するとより汎用性が増す（請求項１５）。
【００６８】
また、ソフトタグ情報を扱う場合には、ソフトタグ情報そのものではなく、ソフトタグ情報が存在する場所を示すＵＲＩデータや場所情報をソフトタグ情報として使用してもよい。この場合、最終的なソフトタグ情報（場所情報が示す場所に記憶されているソフトタグ情報）はプロキシサーバやウェブサーバなどのサーバ手段に登録されることになり、ＵＲＩデータや場所情報を受信した装置は、その情報をサーバ手段に送信して、サーバ手段から最終的なソフトタグ情報を手に入れることができる（請求項１６）。
【００６９】
また、ソフトタグ情報の送受信はどのようなプロトコル（例えばＦＴＰ、メール用プロトコル等）を使用しても実施可能であるが、ＨＴＴＰプロトコルを使用することにより汎用性が増す（請求項１７）。
【００７０】
次に本発明の第１２に実施の形態を説明する。
自装置は盗聴などのセキュリティ対策のために、ＩＰアドレスを定期的に変更するアドレス変更手段を持つことも考えられる。例を挙げると、ＩＰアドレスの割り当てを要求するＩＰアドレス要求手段と、ＩＰパケットを使用して通信をＩＰパケット通信手段とを備えたＩＰ端末装置において、予め定められた規則に従って、前記ＩＰアドレス要求手段が前記ＩＰパケット通信手段を使用して新たなＩＰアドレスの割り当てを要求するＩＰアドレス変更要求手段を備えたことを特徴とするＩＰ端末装置である。
【００７１】
具体的には以下の実施例が考えられる。
・ある一定の通信量（パケット量）を送受した場合に、変更を要求する。
・前の変更から一定時間経過した後に要求する。
・ＩＰパケットの送受信がある時間以上途切れた時に、変更を要求する。
・通信相手以外のＩＰアドレスを持った装置からアクセスがあった場合に要求する。
・ＤＨＣＰ装置にＩＰアドレス変更を要求する。
・自分で持っている複数のＩＰアドレスを取り替える。
このようにＩＰアドレスを変更することにより、盗聴やデータの改ざん等に対するセキュリティを向上させることが出来る。
【００７２】
ここまでは、発呼側の装置のソフトタグ情報を着呼側の装置が受信し、着呼側の装置の表示部に発呼側のソフトタグ情報を表示する場合の各実施の形態を説明してきたが、次に、第１３の実施の形態として、着呼側のソフトタグ情報を発呼側の装置が受信し、発呼側の装置の表示部に着呼側のソフトタグ情報を表示することも考えられる。
【００７３】
図１１にそのプロトコルを示す。
発呼側はＩＮＶＩＴＥ信号を送信する前に、ソフトタグ情報を要求する信号を着呼側に送信し、それを受信した着呼側はソフトタグ情報を発呼側へ送信する。発呼側は受信したソフトタグ情報を検査し、呼設定を行うか、呼設定をやめるか判断するものである。呼設定を行う場合は、ＩＮＶＩＴＥ信号を送信し、その後は図２０の動作と同じであるため説明を省略する。
呼設定をやめる場合は、ＩＮＶＩＴＥ信号を送出するのをやめてそのままにする方法と、呼設定を行わない旨の信号（呼設定非継続信号）を着呼側に送信してもよい。
【００７４】
ここまでの説明における呼設定手段、ソフトタグ情報、ソフトタグ情報検査手段、その他のソフトタグ表示手段、報知手段、ローカル呼設定手段、電話帳手段等の動作は既に説明した内容に対して、発呼側と着呼側が逆になっている場合を除き同じであるので、詳細な説明は省略する。
また、前記着信履歴手段は発呼履歴手段に置き換わるものである（請求項１２、１３）。
また、着呼側装置も複数の自局の端末識別情報を設定することにより複数の端末識別情報を使用することができ、端末識別情報毎にソフトタグ情報、電話帳データ、着信履歴データ、発呼履歴データを記憶することができる。
【００７５】
次に、第１３の実施の形態を示す図１２のように、Ｗｅｂサーバ機能部１３を備えたＷｅｂサーバ機能付き通信端末装置も考えられる。Ｗｅｂサーバ機能部１３は記憶手段に複数のＭＬベースのファイルを記憶しており、クライアントの要求に応じてファイルを送信する。発呼側の端末装置はＷｅｂサーバ機能付き通信端末装置に発呼を行い、呼設定をした後に通信接続する。接続中に、発呼側は着呼側に対して、ＨＴＴＰプロトコルを使用して、ＭＬベースのファイル（その中にソフトタグ情報用のファイルも含まれる）の送受信を行う。
【００７６】
発呼側はＭＬベースのファイルを表示部に表示させるためのＷｅｂブラウザ手段を備え、さらに画像記録手段を備えている場合には、受信したＭＬベースのファイルを記録用画像データに変換してそれを画像記録装置で出力する。特にＭＬベースのファイルに含まれている画像を指定して記録することもできる。具体的にはＷｅｂサーバ機能を備えた携帯電話があり、基地局端末間無線プロトコル上で呼設定プロトコル（ＰＰＰ等）とＨＴＴＰプロトコルが動作する。
【００７７】
また、携帯電話が備えている赤外線Ｉ／Ｆ、ブルートゥースＩ／Ｆ、無線ＬＡＮＩ／Ｆあるいは専用Ｉ／Ｆのプロトコル上でも呼設定プロトコルとＨＴＴＰプロトコルを動作させてもよい。一例としては、カメラを搭載したＷｅｂサーバ付携帯電話（ＰＨＳ、ＩＰ電話、ＩＰテレビ電話等）が考えられ、カメラで撮影した静止画像あるいは動画像を所定の画像ファイル形式（JPEG、MPEG、TIFF、GIF等）に変換するＭＬ変換手段でファイル変換を行い、その後ＭＬベースのファイルとしてメモリ等の記憶手段に記憶する。あるいは、画像ファイルを他のサーバ手段に送信し記録し、そのＵＲＩをＭＬベースのファイルに記載する間接ＭＬ変換手段を持ってもよい。また前記装置はＨＴＴＰやＦＴＰのｇｅｔコマンド等のファイルを送信すべき命令を受信した場合には、カメラでリアルタイムに画像を撮影して送信するコマンド変換手段を持つこともできる。また、カメラで撮影した画像は、自装置が持つ画像処理手段によって画像処理（定型画像とのミックス、画像の集約、画像の分割、画像のエディット、画像の拡大縮小、画像と文字データとのミックス、その他の一般的な画像処理）された後に、ＭＬベースのファイルに変換してもよい。
【００７８】
ここで自装置をＷｅｂサーバとして使用するために、通常の電話として使用する電話モードからＷｅｂサーバモードへ設定を変更する。電話モードは着呼に対して応答すると通常の電話として使用できるモードであり、Ｗｅｂサーバモードは着呼に対して応答するとその後はサーバモードとして動作するものである。通常、Ｗｅｂサーバモードの場合は着呼があると自動応答するが、ユーザによるマニュアル応答も可能である。
【００７９】
画像記録手段を持つ発呼装置は、前記Ｗｅｂサーバ付き携帯電話に発呼して呼設定を行い、通信チャネルを確保し通信を開始する。この場合、パスワード等を使用して認証を行う認証手段を備えていてもよい。発呼装置はＨＴＴＰプロトコルにより携帯電話の記録手段に記録されているＭＬベースのファイル、画像ファイルをリスト表示するファイルや画像ファイルをダウンロードし、Ｗｅｂブラウザを使用して表示部にダウンロードしたファイルや画像データを表示させる。発呼装置上で必要な画像処理（定型画像とのミックス、画像のエディット、画像の拡大縮小、その他の一般的な画像処理）を行い記憶手段に記憶される。発呼装置上で必要な画像処理（定型画像とのミックス、画像の集約、画像の分割、画像のエディット、画像の拡大縮小、画像と文字データとのミックス、その他の一般的な画像処理）を行い記憶手段に記憶される。また、選択された画像は記録画像として例えば紙の上に印刷されて出力される。また修正や編集された画像はＨＴＴＰ等でＷｅｂサーバ付き携帯電話にアップロードすることも出来る。
【００８０】
また、前記Ｗｅｂサーバ付き携帯電話は他の端末装置（画像記録手段を持つ端末装置、他の携帯電話等）に対して発呼することにより呼設定を行い、通信チャネルを確保してから、サーバ手段の機能を実行するようにしてもよい。
【００８１】
次に第１４の実施形態について説明する。図２１にプリンタサーバ手段付き画像記録装置のブロック図を示す。画像記録部２４を持つ端末装置は、相手装置と通信チャネルを確保した後、相手装置からＭＬベースのファイルを転送されてきた場合（ＨＴＴＰプロトコルやＦＴＰプロトコルのｐｕｔコマンド等によるファイル転送）には、その転送コマンドを印刷命令と認識するコマンド変換部２９を備え、次にＭＬインタープリター部２５によって、前記受信したファイルを記録画像データに変換して、表示部に表示したり、記録画像を紙等の媒体に記録し出力するプリンターサーバ部２６を持つ端末装置も考えられる。この場合は、画像記録部２４を持つ端末装置を操作しなくても画像をプリントアウト出来るという効果がある。
【００８２】
従来の携帯電話ではカメラで撮影した画像を一旦、別のサーバにメールで送信し、別の出力装置からそのサーバへアクセスし、データをダウンロードしてから印刷するという複雑な方法を使用していたが、本発明のＷｅｂサーバ付き携帯電話は、カメラで撮影した画像を直接出力装置に送信することにより、前記の手間をかけずに簡単に出力装置から出力することができる。
【００８３】
このように通信端末装置がＷｅｂサーバ機能を備えることにより、ＭＬベースのファイルのように一般的なファイルフォーマットを使用できるようになり、汎用性が増す。またクライアント装置はＷｅｂサーバ付き通信端末装置にダイレクトに接続することが出来、所望のファイルを汎用のファイルフォーマットで入手することができる。
【００８４】
次に第１５の実施形態について説明する。図２２に示すようにＩＣタグ（ＲＦＩＤタグ、無線ＩＣタグ等と呼称されている）にＷｅｂサーバ手段を搭載したＷｅｂサーバ機能付ＩＣタグとそのＩＣタグと通信を行うリーダライタ装置（クライアント手段）も考えられる。
【００８５】
図２２（ａ）に、Ｗｅｂサーバ付きＩＣタグの構成を示す。ＩＣタグは電波信号を送受信するためのアンテナ用コイル、共振コンデンサ、変復調回路、整流平滑回路からなる無線通信部３７とその他はＣＰＵ３１、ＲＯＭ３２、ＲＡＭ３３、Ｗｅｂサーバ機能部３５、ソフトタグ情報送信部３６、ＩＰ制御部３４から構成される。リーダライタ装置から送信されてくる高周波の電力用電波信号をアンテナと共振用コンデンサで受信し、整流平滑回路で整流平滑化して、一定電圧の動作用電源を作成してＩＣタグ内部に供給する。またリーダライタ装置から送信されてくる信号は、電力用電波信号に重畳されており、受信した信号は変復調回路によって復調される。ＣＰＵ３１はＲＯＭ３２に記憶されたプログラムによって動作するものであり、ＲＡＭ３３上に動作に必要なワークエリアを形成しながら、ＩＣタグ全体の動作の制御を行うものである。Ｗｅｂサーバ機能部３５は前記Ｗｅｂサーバ手段付き通信端末装置のＷｅｂサーバ部と基本的には同じものであり、蓄積しているファイルをクライアントに送信するものである。
【００８６】
図２２（ｂ）に、リーダライタ装置の構成を示す。リーダライタ装置は電波信号を送信する送信アンテナ用コイルからなる無線送信部４１と電波信号を受信する受信用アンテナコイルからなる無線受信部４２と制御回路４３とから構成される。制御回路４３は、電力用電波信号を送信し、また送信する信号を電力用電波信号に重畳して送信用アンテナから送信する。また受信用アンテナからＩＣタグが送信した信号を受信し、それを復調して受信データを得る。
【００８７】
このようにＩＣタグとリーダライタ装置の間では電波信号を使用して通信を行う。この電波信号を使用したＩＣタグ用無線プロトコルは、例えばコマンド・レスポンスをベースとしたシンプルなプロトコルで構成されてもよいし、その他プロトコルはいろいろあり、また現在も多くのものが提案されているためここでは言及を避けるが、どのようなプロトコルであれ、本発明に使用できるものである。
【００８８】
また、本発明の特徴部分はＩＣタグ用無線プロトコル上で動作するＨＴＴＰ等のサーバクライアント用のプロトコルであり、その構成と動作は前記Ｗｅｂサーバ機能付き通信端末装置と基本的には同じであるので詳細は省略するが、サーバ手段として蓄積しているファイルの他に、ソフトタグ情報用のファイルがある。
【００８９】
また、前記Ｗｅｂサーバ付きＩＣタグを他の装置に組み込んで利用することも可能である。例えば、カード類（ＩＣカード、定期券、切符、身分証明書、キャッシュカード、クレジットカード等）、法定された書類（紙幣、有価証券、宝くじ等偽造が禁止されているもの）、画像機器装置とそのサプライ（プロセスカートリッジ、トナーカートリッジ、インクカートリッジ、現像ユニット、記録紙）、通信端末装置、その他あらゆる物や装置等に内臓して利用できる。リーダライタ装置も他の装置に組み込んで利用することが出来る。例えば、ＩＣカードリーダ、画像機器装置、通信端末装置などＩＣタグと通信する装置等がある。
【００９０】
このようにＩＣタグにＷｅｂサーバ機能を持たせることにより、より多くの情報を蓄積できるのと同時に、より多くの情報をそこから得ることができる。またプロトコルにＨＴＴＰを、ファイル形式にＭＬベースのファイルを使用することにより、より汎用性の高い利用が期待できる。
【００９１】
以上の各実施の形態では、通信端末装置としてＩＰ電話機を、その標準プロトコルとしてＳＩＰを例にとって説明しているが、その他に標準プロトコルとしてＨ．３２３、ＨＴＴＲ、ＭＥＧＡＣＯ、ＰＰＰ等があり、また標準プロトコルではなく、その他のローカルのプロトコルでも本発明の実施は可能である。また端末装置としてはＩＰ電話以外にＩＰテレビ電話機、ＩＰ携帯電話機、ＩＰ携帯端末装置、インターネットファックス等に代表されるＩＰ端末装置に適用可能であり、その端末装置で使用される標準プロトコルあるいはローカルプロトコルにも適用できる。
【００９２】
また、通信端末装置としてＩＰ電話機、ＩＰテレビ電話機を挙げたが、通信端末装置としてはその他に無線ＬＡＮを使用したＩＰ電話、ＩＰ端末装置、一般加入者電話機、ファクシミリ装置、通信機能付コンピュータ、携帯電話、ＰＨＳ、ＰＤＡ等の通信機能を備えた端末装置があり、それぞれの通信端末装置が使用できる通信プロトコルを使用して実施可能である。ぞれぞれの通信端末装置の構成は公知であるため、ブロック図による図示は省略するが、本発明の特徴に係る手段は各実施の形態と同様に備えているものである。
【００９３】
また、本文中に記載があって、特にブロック図等で図示していない「〜手段」は、専用ハードウェアで構成されているか、あるいはＣＰＵ、ＲＯＭ、ＲＡＭと若干のハードウェアで構成されているものである。
【００９４】
また、各フローチャート及びシーケンスチャートに示す処理を、ＣＰＵ１が実行するためのプロラムは本発明によるプロラムを構成し、このプロラムを記録する記録媒体は、本発明によるコンピュータ読み取り可能な記録媒体を構成する。この記録媒体としては、半導体記憶装置や光学的又は磁気的な記憶装置等を用いることができる。このようなプロラム及び記録媒体を、上述した実施の形態とは異なる構成のシステム等で用い、そこのＣＰＵで上記プロラムを実行させることにより、本発明と実質的に同じ効果を得ることができる。
【図面の簡単な説明】
【００９５】
【図１】本発明の第１の実施の形態による動作を示すシーケンスチャートである。
【図２】本発明の第２の実施の形態による動作を示すシーケンスチャートである。
【図３】本発明の第３の実施の形態による動作を示すシーケンスチャートである。
【図４】本発明の第３の実施の形態による動作を示すフローチャートである。
【図５】本発明の第６の実施の形態による動作を示すフローチャートである。
【図６】本発明の第７の実施の形態による動作を示すフローチャートである。
【図７】本発明の第８の実施の形態による動作を示すフローチャートである。
【図８】本発明の第９の実施の形態による動作を示すシーケンスチャートである。
【図９】本発明の第１０実施の形態による制御用パケットの構成図である。
【図１０】本発明の第１１実施の形態による制御用パケットの構成図である。
【図１１】本発明の第１２の実施の形態による動作を示すシーケンスチャートである。
【図１２】本発明の第１３の実施の形態によるＩＰ電話機の構成を示すブロック図である。
【図１３】本発明の実施の形態によるＩＰ電話機の構成を示すブロック図である。
【図１４】本発明の実施の形態によるテレビＩＰ電話機の構成を示すブロック図である。
【図１５】ＳＩＰのプロトコルスタックを示す構成図である。
【図１６】ＳＩＰの制御用パケットの構成図である。
【図１７】ＳＩＰのデータ用パケットの構成図である。
【図１８】ＵＤＰデータグラムを示す構成図である。
【図１９】ＩＰデータグラムを示す構成図である。
【図２０】ＳＩＰの通信シーケンスチャートである。
【図２１】本発明の第１４の実施形態によるプリンタサーバ手段付き画像記録装置の構成を示すブロック図である。
【図２２】本発明の第１５の実施形態によるＷｅｂサーバ機能付ＩＣタグとそのＩＣタグと通信を行うリーダライタ装置の構成を示すブロック図であり、（ａ）は、Ｗｅｂサーバ機能付きＩＣタグの構成を示し、（ｂ）は、リーダライタ装置の構成を示す。
【図２３】プロフィールデータの表示例を示す図である。
【符号の説明】
【００９６】
１、２１、３１    ＣＰＵ
２、２２、３２    ＲＯＭ
３、３２、３３    ＲＯＭ
４    操作入力・表示部
５    ハンドセット
６    通話回路
７、２７、３４    ＩＰ制御部
８    回線接続Ｉ／Ｆ
９、３０、３６    ソフトタグ情報送信制御部
１１    画像処理部
１３、３５    Ｗｅｂサーバ機能部
２４    画像記録部
２５    ＭＬインタープリタ部
２６    プリンタサーバ部
２８    無線通信部
２９、３５    コマンド変換部
３７    無線通信部
４１    無線送信部
４２    無線受信部
４３    制御回路
２３１    メッセージボタン
２３２    スクリプトボタン
【図１】
2006345542.tif 000003
【図２】
2006345542.tif 000004
【図３】
2006345542.tif 000005
【図４】
2006345542.tif 000006
【図５】
2006345542.tif 000007
【図６】
2006345542.tif 000008
【図７】
2006345542.tif 000009
【図８】
2006345542.tif 000010
【図９】
2006345542.tif 000011
【図１０】
2006345542.tif 000012
【図１１】
2006345542.tif 000013
【図１２】
2006345542.tif 000014
【図１３】
2006345542.tif 000015
【図１４】
2006345542.tif 000016
【図１５】
2006345542.tif 000017
【図１６】
2006345542.tif 000018
【図１７】
2006345542.tif 000019
【図１８】
2006345542.tif 000020
【図１９】
2006345542.tif 000021
【図２０】
2006345542.tif 000022
【図２１】
2006345542.tif 000023
【図２２】
2006345542.tif 000024
【図２３】
2006345542.tif 000025