JP2006345542A - 通信端末装置、プログラム及びコンピュータ読み取り可能な記録媒体 - Google Patents

通信端末装置、プログラム及びコンピュータ読み取り可能な記録媒体 Download PDF

Info

Publication number
JP2006345542A
JP2006345542A JP2006182672A JP2006182672A JP2006345542A JP 2006345542 A JP2006345542 A JP 2006345542A JP 2006182672 A JP2006182672 A JP 2006182672A JP 2006182672 A JP2006182672 A JP 2006182672A JP 2006345542 A JP2006345542 A JP 2006345542A
Authority
JP
Japan
Prior art keywords
tag information
soft tag
call
communication terminal
call setting
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2006182672A
Other languages
English (en)
Inventor
Masakatsu Takahashi
正勝 高橋
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Ricoh Co Ltd
Original Assignee
Ricoh Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Ricoh Co Ltd filed Critical Ricoh Co Ltd
Priority to JP2006182672A priority Critical patent/JP2006345542A/ja
Publication of JP2006345542A publication Critical patent/JP2006345542A/ja
Pending legal-status Critical Current

Links

Images

Landscapes

  • Facsimile Transmission Control (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)

Abstract

【課題】相手の電話番号と名称のほかに詳細なプロフィールデータを得ることができる通信端末装置を提供する。
【解決手段】発呼側はINVITE信号を送信すると共にプロフィールデータを送信する。着呼側はINVITE信号を受信し(S21)、プロフィールデータを受信すると(S22、Yes)、180 RINGING信号を送信する(S23)。次に受信したプロフィールデータを検査し(S24)、検査結果が所定の基準を満足している場合は(S25、Yes)、オフフックされると(S26、Yes)、200 OK信号を送信して通信チャネルが確保され通信が可能になる(S27)。プロフィールデータを受信できなかった場合(S22、No)、及び検査結果が所定の基準を満足していない場合(S25、No)は、BYE信号を送信して(S28)、通信を拒否(呼設定終了)する。受信したプロフィールデータを表示することで相手側のプロフィールを知り、通信の許可・拒否を決めることができる。
【選択図】図6

Description

本発明は、自装置に関する情報を相手装置に伝える機能を有するIP電話機等の通信端末装置に関する。
従来の通信端末装置、特に電話機では電話をかけてきた相手が誰であるのか分からないという不具合があった。それを解決する手段としては、相手電話番号表示(いわゆるナンバーディスプレイ)や相手名称表示(いわゆるネームディスプレイ)等の各機能が知られている(例えば、特許文献1、2、3参照)。
特開2000−216875号公報 特開2000−216906号公報 特開2003−87434号公報
しかしながら、上記各機能は単に相手の電話番号と相手の名称がわかるのみであり、相手についての詳細なデータを知る手段はなかった。また相手電話番号表示や相手名称表示もプロバイダの限定的なサービスであって、別のプロバイダでは使用できないなどの不具合があった。また相手電話番号や相手名称の表示の方法(表示の仕方)は、表示する装置側の表示用ソフトウェアの仕様によって決まるものであり、表示データを送る側からは表示方法を指定したり規定したりすることが出来なかった。
本発明は上記の問題を解決するためのもので、相手の電話番号と名称のほかに詳細なソフトタグ情報を得ることができる通信端末装置を提供することを目的とする。
上記の目的を達成するために本発明による通信端末装置は、請求項1では、呼設定用制御信号と相手装置に表示させる自装置のソフトタグ情報を送信する呼設定手段を備えたものである。
請求項2では、請求項1における前記呼設定手段が、前記ソフトタグ情報を含んだ呼設定用制御信号を送信するものである。
請求項3では、請求項1における前記呼設定手段が、前記呼設定用制御信号の送信とは別に、前記ソフトタグ情報を送信するものである。
請求項4では、請求項1における前記呼設定手段が、前記呼設定用制御信号を送信した後に、前記ソフトタグ情報を送信するものである。
請求項5では、請求項1における前記呼設定手段が、前記呼設定用制御信号を送信する前に、前記ソフトタグ情報を送信するものである。
請求項6では、請求項1から5において、前記呼設定手段が、前記相手装置から前記ソフトタグ情報の送信を要求する信号を受信した場合に、前記ソフトタグ情報を送信するものである。
請求項7では、相手装置に対してソフトタグ情報の送信を要求する信号を送信する呼設定手段を有するものである。
請求項8では、請求項7において、前記呼設定手段が、前記相手装置から呼設定用制御信号を受信した後に、前記相手装置に対して前記ソフトタグ情報の送信を要求する信号を送信するものである。
請求項9では、請求項7又は8において、前記相手装置から受信した前記ソフトタグ情報に基づいて前記相手装置のソフトタグ情報を自装置に表示するソフトタグ表示手段を備えたものである。
請求項10では、請求項7から9のいずれか1項において、前記ソフトタグ情報を受信できなかった場合、又は受信したソフトタグ情報を検査し、所定の内容を満たさなかった場合には、相手装置に呼設定を拒否する通信接続判断手段を備えたものである。
請求項11では、請求項7から10のいずれか1項において、前記ソフトタグ表示手段によって前記相手装置のソフトタグ情報を表示すると共に、前記受信したソフトタグ情報に基づいて相手装置に呼設定を拒否するか、呼設定を行うかを決定する通信接続判断手段を備えたものである。
請求項12では、請求項7から11のいずれかにおいて、相手装置から受信した前記ソフトタグ情報を記憶する着信履歴手段を備えたものである。
請求項13では、請求項12において、前記着信履歴手段の前記ソフトタグ情報を電話帳手段に登録する電話帳登録手段を備えたものである。
請求項14では、請求項1から13のいずれか1項において、前記相手装置の電話番号を検出する電話番号検出手段を備え、前記電話番号検出手段が検出した前記相手装置の電話番号のうち、プロバイダを示す番号に応じてそれに対応するプロバイダの名称又はそれに相当する情報、あるいは前記プロバイダで使用することができる機能の名称又はそれに相当する情報の少なくとも一方を報知する報知手段を備えたものである。
請求項15では、請求項1から14のいずれか1項において、前記ソフトタグ情報はレイアウト情報とプロフィールデータのうち少なくとも1以上から構成されているものである。
請求項16では、請求項1から15のいずれか1項において、前記ソフトタグ情報をML(マークアップ・ランゲージ)言語で記述されたテキストファイルとしたものである。
請求項17では、請求項1から16のいずれか1項において、前記ソフトタグ情報をソフトタグ情報が存在するURI情報としたものである。
請求項18では、請求項1〜17のいずれか1項において、前記ソフトタグ情報を、HTTPプロトコルを使用して送信するようにしたものである。
請求項19では、請求項1から18のいずれか1項において、前記呼設定制御信号を、呼制御用プロトコルを使用して送信するようにしたものである。
請求項20では、請求項19において、標準呼制御用プロトコルを使用して呼設定を行うとともに、前記標準呼制御用プロトコルとは別のローカルプロトコルによって呼設定を行うローカル呼設定手段を備えたものである。
また、本発明によるプログラムは、請求項21では、呼設定用制御信号と相手装置に表示させる自装置のソフトタグ情報を送信する呼設定処理をコンピュータに実行させるものである。
請求項22では、請求項21において、呼設定処理では前記相手装置からソフトタグ情報送信要求信号を受信した場合に前記ソフトタグ情報を送信するものである。
請求項23では、請求項21又は22において、前記相手装置にこの相手装置のソフトタグ情報送信要求信号を送信する送信処理をコンピュータに実行させるものである。
請求項24では、請求項23において、前記相手装置から受信したソフトタグ情報を表示する表示処理をコンピュータに実行させるものである。
また、本発明によるコンピュータ読み取り可能な記録媒体は、請求項21〜24に記載のプログラムを記録したものである。
[作用]
従って、請求項1、21によれば、相手装置のソフトタグ情報(プロフィール)を手に入れることができるので、通信する必要がある相手かどうか判断することができる。
請求項2によれば、ソフトタグ情報を呼設定用制御信号に含ませて送信しているので、呼設定用制御信号とは別の信号でソフトタグ情報を送信する必要がない。
請求項3、4、5によれば、呼設定用制御信号とは別にソフトタグ情報を送信するので、呼設定プロトコルとは別のプロトコルを使用することにより、よりフレキシブルなデータ送信ができる。
請求項6、22によれば、ソフトタグ情報の送信要求に基づいてソフトタグ情報を送信しているので、通常の呼設定制御方式しか対応していない装置に対して無意味なデータを送信しなくてすむ。
請求項7、8、23によれば、ソフトタグ情報を入手することができる。
請求項9、24によれば、ソフトタグ情報を表示しているので、装置の使用者は相手先のプロフィールを見ることができる。
請求項10、11によれば、通信する必要がない相手装置に対して通信を拒否することができる。
請求項12によれば、過去の着信履歴を確認することができる。
請求項13によれば、ソフトタグ情報を確認することができる。
請求項14によれば、プロバイダ名を知ることができるので、トラブル等があった場合には、プロバイダ名を特定し苦情を言う等の対応ができる。また同じプロバイダであれば、固有の機能を使用できるとか、電話料金が安い等のサービスを受けることができるため、それに応じた装置の使い方ができる。
請求項15によれば、レイアウト情報を送信するので、相手装置に表示するソフトタグ情報の表示方法(レイアウト)を指定することができる。
請求項16によれば、テキストベースのファイルなので、人間にとって理解しやすく扱いやすい。
請求項17によれば、装置にソフトタグ情報を持つ必要がないため、メモリを節約できる。またサーバに登録すると公証性が増す。
請求項18によれば、HTTPプロトコルは汎用性が高いので、多くの製品に搭載することができる。
請求項19によれば、呼制御用プロトコルは汎用性が高いので、多くの製品に搭載することができる。
請求項20によれば、標準の呼制御用プロトコルに定義されている標準の通信方式以外の独自の通信(通話)方式を使用することができるため、状況に応じた最適な通信を行うことができる。
請求項25によれば、記録媒体は、本発明による通信端末装置において使用できると共に、通信機能を有する他の通信装置に適用することにより、本発明の効果と同等の効果を得ることができる。
本発明によれば、呼設定を行う場合に、呼設定用制御信号を送信すると共に相手装置に表示させる自装置のソフトタグ情報を送信するようにしたので、相手装置のソフトタグ情報を入手することができ、通信を行う必要があるか否かを判断することができる。従って、ソフトタグ情報に従来のように電話番号や名前だけでなく、より詳細な情報を持たせることにより、さらに適確に判断することができる。また、従来のように特定のプロバイダによるサービスではないので、本発明の機能を持っている通信端末装置であればどのような相手からもそのソフトタグ情報を得ることができる。さらに、表示データを送る側から受ける側に対して、表示方法を指定したり規定したりすることができる。
図13は本発明の実施の形態によるIP電話機のブロック図である。
図において、CPU(中央処理装置)1は、装置全体を制御するものであり、その実行プログラムはROM(リード・オンリー・メモリ)2に記憶され、CPU1はその実行プログラムをROM2から読み出し、その実行プログラムに含まれる命令を逐次解釈して装置全体の制御を行うものである。RAM(ランダム・アクセス・メモリ)3は、その制御に必要なワークエリアが形成されると共に、保存パラメータやそのほか制御に必要ないろいろなパラメータや管理情報等を記憶するものである。操作入力・表示部4は、各種の操作キーと操作ガイダンス等を表示する表示器からなり、オペレータが装置を操作するためのものである。
ハンドセット5は、音声通話をするいわゆる受話器であり、音声を出力するスピーカや音声を入力するマイク等から構成される。通話回路6は、マイク等から入力された音声信号をIP制御部7に送出し、IP制御部7から入力された音声信号をスピーカ等に出力するものである。また音声信号を増幅したり、あるいは減衰することにより音量を調整したり、音声信号の周波数特性を変化させることにより音質を良くしたりする回路も含まれているのが一般的である。また送話器から受話器への音の回り込みを制御するいわゆる側音制御もこの部分で行うのが一般的である。
IP制御部7は、通話回路6から送られてきたアナログの音声信号をデジタルデータに変換し、さらに必要であれば符号化圧縮する。次に音声信号データを送信用のIPパケットに埋め込み、順次回線接続I/F8に送り出す。また回線接続I/F8から入力される受信用のIPパケットから音声信号データを取り出し、必要であれば復号伸張し、さらにデジタルの音声信号データをアナログの音声信号に変換し、通話回路6に送出する。
またIP制御部7は、呼制御を行うための制御用IPパケットを組立て、順次回線接続I/F8に送り出す。さらに回線接続I/F8から入力される受信した制御用IPパケットを分解する。このような制御用IPパケットの送出、受信はIP制御部7とは独立した別の手段で構成してもよい。IP制御部7の動作制御はCPU1で行う。
回線接続I/F8は、IP制御部7から入力される送信用IPパケットを接続回線に送出する一方、接続回線から入力される受信用パケットをIP制御部7に送出する。接続回線としてNTT等が供給している一般の電話網を使用する場合には、デジタル信号とアナログ信号を相互に変換するXDSLモデムが回線接続I/F8に含まれる。また接続回線がLAN等であれば回線接続I/F8はLAN用のI/F(イーサネット(登録商標)、トークンリング、FTTH、無線LAN等)である。また携帯電話、PHS等の無線I/Fであってもよい。またその複数のI/Fのうち少なくとも1つ以上を備えていてもよい。
ソフトタグ情報送信制御部9は、本発明の特徴部分であり、自装置についての情報であるソフトタグ情報を相手装置に送信する制御を行うものである。ソフトタグ情報は、自装置の電話番号、名前のほかに、後述する詳しい内容を有するデータである。このソフトタグ情報は、不揮発性メモリ等の記憶装置に保存されているものとする。
図14は本発明の実施の形態によるIPテレビ電話機のブロック図である。
CPU1、ROM2、RAM3、操作入力部4、回線接続I/F8、通話回路6、ハンドセット5及びソフトタグ情報送信制御部9は、IP電話機と同じであるので説明は省略する。カメラ10は被写体を次々に画像データに変換するものである。その画像データは画像処理回路11で送信データ用に画像処理される。画像処理されたデータはIP制御部7で符号化圧縮され、画像信号データを送信用のIPパケットに埋め込み、順次回線接続I/F8に送り出す。また回線接続I/F8から入力される受信用のIPパケットから画像信号データを取り出すと共に復号伸張し、画像処理回路11に送出する。画像処理回路11は画像表示部12に合わせた画像処理を行い、画像表示部22に画像データを送出し、画像表示部12は画像データを連続的に表示することにより動画像を得ることができる。
次にIP電話機やIPテレビ電話機で使用されるプロトコルについて説明する。
ここで、本発明における呼設定手段は、標準で規定されている標準用呼制御用プロトコル(SIP,H.323、MEGACO、HTTP等)を使用して呼設定を行い、通信(通話を含む)を可能にするものである。
図15にSIPのプロトコルスタックを示す。
図15に示されるように、呼・セッション制御用プロトコルとしてSIPを使用する場合、Network Layer(ネットワーク層)においてIP(Internet Protocol )が使用される。またこの場合、Transport Layer(トランスポート層)においてUDP(User Datagram Protocol)、TCP(Transmission Control Protocol )、又はSCTP(Stream Control Transmission Protocol)が使用される。またこの場合、SIPメッセージを記述する制御情報記述プロトコルとしてSDP(Session Descripition Protocol )が使用される。またこの場合、UDP(トランスポート層)と共に、動画/音声の送受信プロトコルとして、RTP(Realtime Transport Protocol )が使用される。
図16はSIPの制御用パケットの構造を示す図である。図示されるように、SIPの制御用パケットには、IPヘッダとUDP(TCP)ヘッダとSIPメッセージとが含まれている。
図17はSIPのデータ用パケットの構造を示す図である。図示されるように、SIPのデータ用パケットには、IPヘッダとUDPヘッダとRTPヘッダと音声・画像データとが含まれている。
図18はUDPデータグラムの構造を示す図である。図示されるように、UDPデータグラムには、送信ポート番号と宛先ポート番号とデータ長とチェックサムとデータとが含まれている。
図19はSIPで使用されるIPデータグラムの構造を示す図である。図示されるように、IPパケットの構成は、バージョン情報とヘッダ長情報とサービスタイプ情報とトータル長情報と識別子(ID)とフラグ情報とフラグメント・オフセット情報と生存時間(TTL)情報とプロトコルタイプ情報とヘッダチェックサム情報と送信元アドレスと宛先アドレスとオプションとパディングとデータ領域とからなる。
図20に標準の呼制御プロトコルのうちの1つであるSIPの通信モデルのプロトコル図を示す。
まず、発呼側からINVITEと言うリクエストメッセージを送出する。INVITEはセッションの起動信号であり、それには発呼側が受信可能なセッションの属性がSDPで示されている。具体的には、発呼側の受信条件(コーデック、ポート番号等)と送信条件を提示するものである。着呼側はINVITEを受信し、呼び出し状態になったことを通知するために180 RINGINGを発呼側へ送信する。この180 RINGINGで着呼側の受信条件(コーデック、ポート番号等)と送信条件を提示してもよいが、通常は次の200 OKで提示する。
次に、着呼側が通話可能状態になったことを通知するために200 OKを発呼側へ送信する。それには着呼側が受信可能なセッションの属性がSDPで示されている。この200 OKで着呼側の受信条件(コーデック、ポート番号等)と送信条件を提示する。次に発呼側がACKを着呼側へ送信し、これにより通信に利用可能な属性がネゴシエーションされる。ここでは、便宜上ここまでを接続フェーズと定義している。次にメディア(音声、画像、動画等)の転送が開始される。ここでは、このメディアの転送期間中を便宜上、データ送受信フェーズと定義している。通信を終了するときには止める側がBYE信号を送信することにより通信終了を要求し、それを受信した側は、その応答である200 OK信号を送信して通信を終了する。ここでは、このフェーズを便宜上切断フェーズと定義している。
次に、本発明の実施の形態による呼設定手段について説明する。
図1に本発明の第1の実施の形態によるプロトコル図を示す。
図20との違いは発呼側がINVITE信号を送信した後に、発呼側のソフトタグ情報をソフトタグ情報送信制御部9により着呼側へ送信していることである(請求項1、4・・・請求項1、4に関連する記載であることを示す。以下()内同じ)。
尚、INVITE信号を送信する前にソフトタグ情報を送信してもよい(請求項1、5)。
ソフトタグ情報送信制御部9は、専用のハードウェアで構成されていてもよいし、CPU、ROM、RAMと若干のハードウェアで構成されていてもよい。ソフトタグ情報は不揮発性メモリなどの記憶装置に記憶されているのが通常である。
その他の動作については図20と同様に行われる。
図2に本発明の第2の実施の形態によるプロトコル図を示す(請求項3、4、6、7)。
図1との違いは着呼側がINVITE信号を受信した場合に、発呼側に対してソフトタグ情報の送信を要求する信号を送信していることである。発呼側はその要求信号を受信するとソフトタグ情報を着呼側へ送信する。その他の動作については図1、図20と同様に行われる。
図1及び図2では、呼制御用信号(INVITE信号やその他の信号)とは別にソフトタグ情報やソフトタグ情報の要求信号を送信しているが、呼制御用信号にソフトタグ情報やソフトタグ情報の要求信号を含ませて送信してもよい。具体的にはINVITE信号のSIPメッセージ部あるいは拡張部分にソフトタグ情報を乗せて送信する(請求項2)。
図3に本発明の第3の実施の形態によるプロトコル図を示し、図4はそのフローチャートを示す。
図3、図4において、着呼側は、INVITE信号を受信した後(S1)、ソフトタグ情報を要求する信号を送信する(S2)。その要求信号を受信した発呼側はソフトタグ情報を送信する(請求項8)。
次に着呼側は、ソフトタグ情報を受信したかを判断し(S3)、受信した場合は、ソフトタグ情報を検査し(S4)、検査の結果、通信(呼設定)の許可・拒否を判断する(S5)。拒否する場合及びソフトタグ情報を受信しなかった場合には、呼設定を拒否する信号(100 NG)を発呼側へ送信して呼設定シーケンスを終了させる(S8)。検査がOKの場合には、ハンドセットがオフフックされると(S6、Yes)、通信(通話)チャネルが確保され、通信(通話)が可能になる(S7)(通信接続判断手段)(請求項10)。
ソフトタグ情報の検査は、具体的にはエラーのない正しいデータであるかどうか、ソフトタグ情報として必要なデータの種類やそのデータが存在しているかどうか、そのデータが着呼側の所望のデータと一致しているかどうか、データファイルが所望の種類であるかどうか、データ形式が所望のデータ形式であるかどうか、あるいは通信を許可してもよい相手なのかどうか等のように、通信を許可するか拒否するかの判断の基準になる事項について検査する。
その判断方法は、装置が自動的に判断して通信を許可又は拒否してもよい(請求項10)。
あるいは、ソフトタグ情報を操作・入力表示部4で表示してよい(請求項9)。この表示を見てユーザが判断し、通信の許可又は拒否を装置に入力するようにしてもよい(請求項11)。
またソフトタグ情報の要求信号を送信しても、発呼側がソフトタグ情報を送信しない場合や、発呼側がソフトタグ情報を送信したが、途中でデータが壊れて、あるいは失われて正しいデータが受信できなかった場合も同様に通信の許可・拒否の判断基準になるものである。以上説明したように、通信接続判断手段は、受信したソフトタグ情報を検査し、検査結果に基づいて通信の許可・拒否の判断を行う。
次に、ソフトタグ情報について説明する。
ソフトタグ情報はプロフィールデータ(データ情報)とレイアウト情報(表示方法の情報)の少なくとも1以上で構成されるものである。
プロフィールデータは、装置についての情報(装置の種類(携帯電話、PHS、IP電話、IP端末装置、一般加入者電話機、ファクシミリ装置、通信機能付コンピュータ、PDA等)、装置の名称、装置のスペック、設置場所、使用環境、使用履歴、装置のプロフィール等)、装置使用者についての情報(名前、性別、生年月日、年齢、勤務先会社名、住所、趣味、プロフィール等)、画像(装置の画像、使用者の顔画像、動画像、その他の画像)、音声データ(音声メッセージ、BGM、音楽等)等の装置の説明情報である。
また、それは単なる装置の説明情報だけではなく、Java(登録商標)に代表されるようなスクリプトデータでもよい。またソフトタグ情報として単なるデータではなく、アプリケーションそのもののデータであってもよい。これらのスクリプトやアプリケーションは受信した通信端末上で実行され、前記装置の説明情報を表示してもよいし、別の機能(伝言メッセージの出力、アニメーションの動作、ゲームの実行等)を実行してもよい。またソフトタグ情報のファイルを複数持っていてもよく、どれを送信するかを予め優先順位設定手段で設定しておくか、あるいは全てを送信してもよい。
レイアウト情報はプロフィールデータを表示部に表示する方法(表示の仕方)を示す情報である。すなわち、プロフィールデータはレイアウト情報に基づいて相手装置の表示部に表示されるものである。レイアウト情報としては例えば文字の種類(フォント)、文字の大きさ、文字の色、文字の修飾、文字の表示位置、画像の表示位置、画像の大きさ、背景色、アニメーションの位置、アニメーションの大きさ等であって、具体的にはXMLやHTMLのML言語で扱っているレイアウト情報である。
また、ソフトタグ表示手段は、装置の操作・表示部4等の表示手段にソフトタグ情報を表示するものである。すなわち前記ソフトタグ表示手段はソフトタグ情報のレイアウト情報に基づいてプロフィールデータを表示部に表示するものである。ソフトタグ情報がML(マークアップ・ランゲージ)ベースのファイル(XML、HTML等)である場合には、Webブラウザがファイルを読み込み、表示データに変換する。また、ソフトタグ情報を音声に変換する変換手段を備え、アナログの音声に変換された音声信号をスピーカ、ハンドセットなどの音響手段から出力してもよい。
図23に、プロフィールデータの表示例を示す。この例においては、プロフィールデータとともにメッセージボタン231及びスクリプトボタン232を表示するようにレイアウト情報が設定されている。メッセージボタン231は、音声メッセージを再生するためのボタンであり、ユーザがこれを押下することによって音声メッセージが再生される。スクリプトボタン232は、アプリケーションを実行するためのボタンであり、ユーザがこれを押下することによってスクリプトボタン232に関連付けられたアプリケーションが実行される。
また端末装置(発呼側装置、着呼側装置)は複数の自身の前記端末識別情報を設定できる。すなわち、端末装置は自局端末識別情報設定手段を備え、複数の自局の端末識別情報をメモリ等の記憶手段に記憶する。あらかじめ使用する自局の端末識別情報を設定しておき、発呼した時に使用する端末識別情報として設定されている端末識別情報が選択される。また、発呼前あるいは発呼後に、使用する自局の端末識別情報を選択することができる。発呼した後は、複数の自局端末識別情報から選択された自局端末識別情報を相手端末装置あるいは通信網側に送信する。端末装置は複数の自局の端末識別情報毎にソフトタグ情報を持つことができる。従って、選択された自局の端末識別情報に対応したソフトタグ情報が相手装置に送信されるものである。このように複数の自局端末識別情報毎にソフトタグ情報を持つことにより、自局端末識別情報毎にソフトタグ情報を使い分けることが出来て、利便性が向上する。
次に、本発明の第4の実施の形態について説明する。
本実施の形態は、着信があった通信の履歴を記憶する着信履歴手段を備えたものである(請求項12)。着信履歴手段は、受信したソフトタグ情報をその他のデータ(相手先電話番号、相手先名称、相手先メールアドレス、相手先のURI、IPアドレス、受信日時、応答したかどうかを示すデータ、通信時間等)と共に記憶装置に記憶するものである。記憶された複数の着信について着信履歴手段を選択することにより、他のデータと共にソフトタグ情報も装置の表示部に表示される。また、着信履歴からの選択による発呼動作も可能である。さらに複数の自局の端末識別情報毎に着信履歴データを記憶することができる。あるいは、着信履歴データに端末識別情報を付加してもよい。
次に、本発明の第5の実施の形態について説明する。
本実施の形態は、予め複数の相手先の名称、電話番号、メールアドレス、URI、IPアドレス、その他の情報をメモリ等の記憶装置(電話帳手段)に記憶しておく電話帳登録手段を備えたものである(請求項13)。この電話帳登録手段に記憶された複数の登録データから任意の登録データを選択することにより、相手装置に発呼できる。また登録データを選択することにより、ソフトタグ情報やその他の情報も表示部に表示することができる。さらに複数の自局の端末識別情報毎に電話帳データを記憶することができる。あるいは、着信履歴データに端末識別情報を付加してもよい。
また、ソフトタグ情報編集手段は、ソフトタグ情報を新規に作成したり、あらかじめ作成してあるソフトタグ情報を編集するテキストベースのエディターである。データは表示部に表示され、入力手段を使用してデータを編集する。このソフトタグ情報編集手段は、発呼装置あるいは着呼装置に搭載されるものである。このようにソフトタグ情報編集手段によって、編集用の外部機器(パソコン等)を接続しなくても、ソフトタグ情報を作成し編集することが出来る。
図5に本発明の第6の実施の形態によるフローチャートを示す。本実施の形態は、図2にさらにソフトタグ情報の検査を行うようにした場合である。
発呼側は呼設定を行うためにINVITE信号を着呼側に送信し、着呼側はINVITE信号を受信すると(S11)、発呼側に対してソフトタグ情報を要求する要求信号を送信する(S12)。発呼側は要求信号を受信すると着呼側に対してソフトタグ情報を送信し、着呼側はソフトタグ情報を受信した場合には(S13、Yes)、180 RINGING信号(リングバックトーンに相当する信号)を送信し(S14)、ソフトタグ情報を受信しなかった場合には(S13、No)、BYE信号を送信して(S19)、通信を拒否(呼設定を終了)する。
次に受信したソフトタグ情報を検査し(S16)、検査の結果が所定の基準を満足していない場合には、BYE信号を送信する(S19)。満足している場合には、ハンドセット等でオフフックすることにより応答した場合には(S17、Yes)200 OK信号を送信することにより、通信(通話)チャネルが確保され、通信が可能になる(S18)。またソフトタグ情報の検査がOKになってから180 RINGING信号を送信するようにしてもよい。
図6に本発明の第7の実施の形態によるフローチャートを示す。本実施の形態は、図1にさらにソフトタグ情報の検査を行うようにした場合である。
発呼側はINVITE信号を送信すると共にソフトタグ情報を送信する。着呼側はINVITE信号を受信し(S21)、ソフトタグ情報を受信すると(S22、Yes)、180 RINGING信号を送信する(S23)。次に受信したソフトタグ情報を検査し(S24)、検査の結果が所定の基準を満足している場合は(S25、Yes)、オフフックされると(S26、Yes)、200 OK信号を送信することにより、通信チャネルが確保され通信が可能になる(S27)。ソフトタグ情報を受できなかった場合(S22、No)、及び検査の結果が所定の基準を満足していない場合(S25、No)には、BYE信号を送信して(S28)、通信を拒否(呼設定を終了)する。尚、ソフトタグ情報の検査がOKになってから180 RINGING信号を送信するようにしてもよい。
図7に本発明の第8の実施の形態によるフローチャートを示す(請求項14)。
本実施の形態は、電話番号検出手段を備え、相手装置あるいはネットワーク側から送信された相手装置の電話番号を受信するとともに、受信した電話番号を記憶装置に記憶するようにしたものである。
図7において、相手装置が自装置に対して発呼すると、接続されている回線網から呼制御用のIPパケットが到来し(S31、着呼)、自装置はそれを検出して呼の制御を行う。次に電話番号検出手段により例えばCPU1がIP制御部7の受信した制御用IPパケットに相手装置の電話番号が埋め込まれているかどうかを検査する(S32、S33)。
電話番号が埋め込まれていれば、電話番号からプロバイダ名に対応している番号を抽出し(S34、S35)、次に操作・表示部4の表示器等(報知手段)は、例えばCPU1がその番号に対応しているプロバイダがあるかどうかメモリ内のテーブル(番号とプロバイダの対応テーブル)を検査し、あればそのプロバイダの名称又はそれに相当する情報を表示する。また、そのプロバイダが単独で行っていて利用できるサービスあるいは機能(留守番電話、転送、着信拒否、通話料金表示、着メロダウンロード、キャッチホン、複数電話番号、ファックスサービス等、他の電話サービス、機能)の名称又はそれに相当するものを表示器等に表示する。名称に相当するものとしては、名前等の他に、商号、商標、マーク、愛称、記号、略称、その他がある。またプロバイダの名称等を発声する音声データ等音による報知でもよい。
図8に本発明の第9の実施の形態による通信モデルの1つであるプロトコル図を示す(請求項19)。
本実施の形態は、ローカル呼設定手段を備えたものである。このローカル呼設定手段は、標準呼設定プロトコルのセッションの属性の他に(重複して持っていてもいいが)、独自のセッションの属性である受信条件(コーデック、ポート番号等)と送信条件と、さらに標準呼設定プロトコルが持っていない、装置に関わる独自の情報(装置が装備している機能、装置の状態を示す情報、相手装置の設定を変更する情報、相手装置の機能を実行する情報等)をIPパケットに挿入し、それを相手装置に送信するものである。
図8において、まず発呼側装置は発呼する際に自装置に備えられているプロトコルを調査し、最初に送出するプロトコルとして優先設定されているプロトコルで通信を開始するため(この例では標準プロトコルが設定されている)、まず発呼側は標準のプロトコルであるSIPのINVITE信号を着呼側へ送信する。次にそのすぐ後にローカル呼設定手段により、ローカルプロトコルの1つであるinvite信号を送信する(以後、標準プロトコル信号を大文字で表し、それに相当するローカルプロトコル信号を小文字で表す)。
着呼側はINVITE信号とinvite信号の両方を受信し(順次記憶装置に蓄えておくことにより複数の制御信号を受信することができる)、invite信号を選択するとともに、呼び出し状態になったことを通知するために180 ringingを発呼側へ送信する(もちろん場合によっては、例えば標準プロトコルを優先設定されている場合等、INVITE信号を選択してもよい)。この後の動作は標準プロトコルがローカルプロトコルに代わる以外は、図20のプロトコルとシーケンスは同じである。
その他の独自の受信条件としては、前記の他に、装備している通信プロトコルの種類、呼設定の方式に関係するもの、ネゴシエーションに関係するもの、端末の通信能力、データの圧縮方式、デジタル化方式、プロトコルの種類、それに使用するIPパケットの種類、IPパケットの構造、IPパケットの定義、再送処理方式、エラー処理方式、セキュリティ方式等、通信条件に関するあらゆるものが考えられる。また標準プロトコルのINVITE信号を送出する前に、すなわち最初からローカルプロトコルのinvite信号を送信してもよい。また、INVITE信号は接続フェーズまたはデータ送受信フェーズまたは切断フェーズの期間中のどこでも送信してもよい。
例えば、データ送受信フェーズの場合には、ユーザが例えば音声の品質がよくないとか、画像の品質がよくない場合に、高品質な方式に切り換えたい場合に、例えば端末の入力手段から方式を切り替える操作を入力した場合に、invite信号を送出することが考えられる。着呼側は標準プロトコルであるINVITE信号に対して180 RINGING信号または200 OK信号を送信した場合、すなわち標準プロトコルで接続(ネゴシエーションが成立)した後でも、接続フェーズまたはデータ送受信フェーズまたは切断フェーズの期間中にinvite信号を受信することができ、その場合は再びネゴシエーションをやり直すことになる。
装置に関わる独自の情報(装置が装備している機能、装置の状態を示す情報、相手装置の設定を変更する情報、相手装置の機能を実行する情報等)とは、具体的には、
・装置が装備している機能:Webブラウザ機能、ストリームデータ再生機能、テレビ電話機能、留守番電話機能、留守番録画機能、録音機能、録画機能、着信メモリ、リダイヤルメモリ、電話帳機能、発信元番号通知機能、発信者名称通知機能、着信拒否機能、着信メロディー変更機能、転送機能、キャッチホン機能等。
・装置の状態を示す情報:留守番電話がセットされている情報、留守番録画がセットされている情報、装置に不具合があることを示す情報、装置が使用されていることを示す情報、装置のなんらかの機能がセットされていることを示す情報等。
・相手装置の設定を変更する情報:留守番電話をセットあるいは解除する命令、留守番録画をセットあるいは解除する命令、装置に備わっている機能が動作するようにセットあるいは解除する命令等。
・相手装置の機能を実行する情報:留守番電話に録音されている音声を再生させ送信させる命令、留守番録画に録画されている画像を再生させ送信させる命令、着信メロディを変更させる命令等である。
次に、本発明の第10、11の実施の形態を説明する。
本実施の形態は、ローカル呼設定手段の他の例であり、標準呼設定手段で使用する標準プロトコルのIPパケットに、ローカル呼設定手段で使用するローカルプロトコルで使用する情報を含ませるものである。
図9に第10の実施の形態を示す。SIPの制御用パケットのSIPメッセージ部分に、ローカル呼設定手段で使用するローカルプロトコルで使用する情報(ローカルプロトコル情報)を含ませた例である。
また、IPヘッダのオプションフィールドにローカルプロトコル情報を載せてもよい。SIPプロトコルのみしか対応していない端末はローカル部分を無視するため、SIPで呼制御を行うが、ローカル呼設定手段に対応している端末は、このローカル部分を解釈し、必要に応じてローカルプロトコルで呼制御を行うものである。すなわち標準のセッションからローカルなセッションに移行することができる。
図10に第11の実施の形態を示す。これはSIPのデータ用パケットのRTPヘッダ以下の音声、画像データを載せる部分に、ローカル呼設定手段で使用するローカルプロトコルで使用する情報を含ませた例である。またIPヘッダのオプションフィールドにローカルプロトコル情報を載せてもよい。SIPプロトコルのみしか対応していない端末はローカル部分を無視するため、SIPで呼制御を行うが、ローカル呼設定手段に対応している端末は、このローカル部分を解釈し、必要に応じてローカルプロトコルで呼制御を行うものである。すなわち標準のセッションからローカルなセッションに移行することができる。
このように独自のローカルプロトコルに対応している端末はIPパケットのどの部分にローカルプロトコル情報が載せられているのかは、あらかじめ認識しているので、ローカルプロトコルの搭載形態は任意に構成することができる。
またIP端末は発呼側および着呼側にもなり得るように、発呼側および着呼側で使用する両方のプロトコルを備えているのが一般的である。
また、標準のプロトコルでセッションが開始されたのか、あるいは独自のプロトコルでセッションが開始されたのかを表示部に表示することができる。例えば「SIP」「H.323」「独自方式」等の表示をする。ユーザはこれを見ることにより通信の状態あるいは使用できる機能等を知ることができる。また接続に使用したプロトコルによって使用できる機能等を表示することもできる。また、発呼する場合、相手装置がどのプロトコルを装備しているか分からない場合には、発呼端末が装備している複数のプロトコルまたはすべてのプロトコルのINVITE又はinvite信号を順次送出することができる。
着呼側はその複数のプロトコルのうちの1つを選択し、その選択したプロトコルに相当する応答信号を1つだけ返信することができる。又は複数のプロトコルのうち複数のプロトコルを選択し、その選択した複数のプロトコルに相当する応答信号を複数返信することもできる。この場合、発呼側は優先順位の高いプロトコルを選択することができる。
このようにローカル呼設定手段を備えることにより、標準呼設定手段で使用出来る機能以外の機能を使用することが出来るので、利便性が向上する。またローカル呼設定手段はメーカ独自に作成し実装することができるため、さまざまな制約を受けることなく仕様を決定することが出来るという利点がある。
今まで説明してきたソフトタグ情報のデータフォーマットやファイル形式の種類などには特に言明してこなかったが、ソフトタグ情報は、どのような種類のデータであっても本発明に適用可能である。しかしながらソフトタグ情報をXML、HTML、SGML、XHTML、CHTML、HDML、DHTML等に代表されるML(マークアップ・ランゲージ)で記述されたデータファイル(テキストファイル)を使用するとより汎用性が増す(請求項15)。
また、ソフトタグ情報を扱う場合には、ソフトタグ情報そのものではなく、ソフトタグ情報が存在する場所を示すURIデータや場所情報をソフトタグ情報として使用してもよい。この場合、最終的なソフトタグ情報(場所情報が示す場所に記憶されているソフトタグ情報)はプロキシサーバやウェブサーバなどのサーバ手段に登録されることになり、URIデータや場所情報を受信した装置は、その情報をサーバ手段に送信して、サーバ手段から最終的なソフトタグ情報を手に入れることができる(請求項16)。
また、ソフトタグ情報の送受信はどのようなプロトコル(例えばFTP、メール用プロトコル等)を使用しても実施可能であるが、HTTPプロトコルを使用することにより汎用性が増す(請求項17)。
次に本発明の第12に実施の形態を説明する。
自装置は盗聴などのセキュリティ対策のために、IPアドレスを定期的に変更するアドレス変更手段を持つことも考えられる。例を挙げると、IPアドレスの割り当てを要求するIPアドレス要求手段と、IPパケットを使用して通信をIPパケット通信手段とを備えたIP端末装置において、予め定められた規則に従って、前記IPアドレス要求手段が前記IPパケット通信手段を使用して新たなIPアドレスの割り当てを要求するIPアドレス変更要求手段を備えたことを特徴とするIP端末装置である。
具体的には以下の実施例が考えられる。
・ある一定の通信量(パケット量)を送受した場合に、変更を要求する。
・前の変更から一定時間経過した後に要求する。
・IPパケットの送受信がある時間以上途切れた時に、変更を要求する。
・通信相手以外のIPアドレスを持った装置からアクセスがあった場合に要求する。
・DHCP装置にIPアドレス変更を要求する。
・自分で持っている複数のIPアドレスを取り替える。
このようにIPアドレスを変更することにより、盗聴やデータの改ざん等に対するセキュリティを向上させることが出来る。
ここまでは、発呼側の装置のソフトタグ情報を着呼側の装置が受信し、着呼側の装置の表示部に発呼側のソフトタグ情報を表示する場合の各実施の形態を説明してきたが、次に、第13の実施の形態として、着呼側のソフトタグ情報を発呼側の装置が受信し、発呼側の装置の表示部に着呼側のソフトタグ情報を表示することも考えられる。
図11にそのプロトコルを示す。
発呼側はINVITE信号を送信する前に、ソフトタグ情報を要求する信号を着呼側に送信し、それを受信した着呼側はソフトタグ情報を発呼側へ送信する。発呼側は受信したソフトタグ情報を検査し、呼設定を行うか、呼設定をやめるか判断するものである。呼設定を行う場合は、INVITE信号を送信し、その後は図20の動作と同じであるため説明を省略する。
呼設定をやめる場合は、INVITE信号を送出するのをやめてそのままにする方法と、呼設定を行わない旨の信号(呼設定非継続信号)を着呼側に送信してもよい。
ここまでの説明における呼設定手段、ソフトタグ情報、ソフトタグ情報検査手段、その他のソフトタグ表示手段、報知手段、ローカル呼設定手段、電話帳手段等の動作は既に説明した内容に対して、発呼側と着呼側が逆になっている場合を除き同じであるので、詳細な説明は省略する。
また、前記着信履歴手段は発呼履歴手段に置き換わるものである(請求項12、13)。
また、着呼側装置も複数の自局の端末識別情報を設定することにより複数の端末識別情報を使用することができ、端末識別情報毎にソフトタグ情報、電話帳データ、着信履歴データ、発呼履歴データを記憶することができる。
次に、第13の実施の形態を示す図12のように、Webサーバ機能部13を備えたWebサーバ機能付き通信端末装置も考えられる。Webサーバ機能部13は記憶手段に複数のMLベースのファイルを記憶しており、クライアントの要求に応じてファイルを送信する。発呼側の端末装置はWebサーバ機能付き通信端末装置に発呼を行い、呼設定をした後に通信接続する。接続中に、発呼側は着呼側に対して、HTTPプロトコルを使用して、MLベースのファイル(その中にソフトタグ情報用のファイルも含まれる)の送受信を行う。
発呼側はMLベースのファイルを表示部に表示させるためのWebブラウザ手段を備え、さらに画像記録手段を備えている場合には、受信したMLベースのファイルを記録用画像データに変換してそれを画像記録装置で出力する。特にMLベースのファイルに含まれている画像を指定して記録することもできる。具体的にはWebサーバ機能を備えた携帯電話があり、基地局端末間無線プロトコル上で呼設定プロトコル(PPP等)とHTTPプロトコルが動作する。
また、携帯電話が備えている赤外線I/F、ブルートゥースI/F、無線LANI/Fあるいは専用I/Fのプロトコル上でも呼設定プロトコルとHTTPプロトコルを動作させてもよい。一例としては、カメラを搭載したWebサーバ付携帯電話(PHS、IP電話、IPテレビ電話等)が考えられ、カメラで撮影した静止画像あるいは動画像を所定の画像ファイル形式(JPEG、MPEG、TIFF、GIF等)に変換するML変換手段でファイル変換を行い、その後MLベースのファイルとしてメモリ等の記憶手段に記憶する。あるいは、画像ファイルを他のサーバ手段に送信し記録し、そのURIをMLベースのファイルに記載する間接ML変換手段を持ってもよい。また前記装置はHTTPやFTPのgetコマンド等のファイルを送信すべき命令を受信した場合には、カメラでリアルタイムに画像を撮影して送信するコマンド変換手段を持つこともできる。また、カメラで撮影した画像は、自装置が持つ画像処理手段によって画像処理(定型画像とのミックス、画像の集約、画像の分割、画像のエディット、画像の拡大縮小、画像と文字データとのミックス、その他の一般的な画像処理)された後に、MLベースのファイルに変換してもよい。
ここで自装置をWebサーバとして使用するために、通常の電話として使用する電話モードからWebサーバモードへ設定を変更する。電話モードは着呼に対して応答すると通常の電話として使用できるモードであり、Webサーバモードは着呼に対して応答するとその後はサーバモードとして動作するものである。通常、Webサーバモードの場合は着呼があると自動応答するが、ユーザによるマニュアル応答も可能である。
画像記録手段を持つ発呼装置は、前記Webサーバ付き携帯電話に発呼して呼設定を行い、通信チャネルを確保し通信を開始する。この場合、パスワード等を使用して認証を行う認証手段を備えていてもよい。発呼装置はHTTPプロトコルにより携帯電話の記録手段に記録されているMLベースのファイル、画像ファイルをリスト表示するファイルや画像ファイルをダウンロードし、Webブラウザを使用して表示部にダウンロードしたファイルや画像データを表示させる。発呼装置上で必要な画像処理(定型画像とのミックス、画像のエディット、画像の拡大縮小、その他の一般的な画像処理)を行い記憶手段に記憶される。発呼装置上で必要な画像処理(定型画像とのミックス、画像の集約、画像の分割、画像のエディット、画像の拡大縮小、画像と文字データとのミックス、その他の一般的な画像処理)を行い記憶手段に記憶される。また、選択された画像は記録画像として例えば紙の上に印刷されて出力される。また修正や編集された画像はHTTP等でWebサーバ付き携帯電話にアップロードすることも出来る。
また、前記Webサーバ付き携帯電話は他の端末装置(画像記録手段を持つ端末装置、他の携帯電話等)に対して発呼することにより呼設定を行い、通信チャネルを確保してから、サーバ手段の機能を実行するようにしてもよい。
次に第14の実施形態について説明する。図21にプリンタサーバ手段付き画像記録装置のブロック図を示す。画像記録部24を持つ端末装置は、相手装置と通信チャネルを確保した後、相手装置からMLベースのファイルを転送されてきた場合(HTTPプロトコルやFTPプロトコルのputコマンド等によるファイル転送)には、その転送コマンドを印刷命令と認識するコマンド変換部29を備え、次にMLインタープリター部25によって、前記受信したファイルを記録画像データに変換して、表示部に表示したり、記録画像を紙等の媒体に記録し出力するプリンターサーバ部26を持つ端末装置も考えられる。この場合は、画像記録部24を持つ端末装置を操作しなくても画像をプリントアウト出来るという効果がある。
従来の携帯電話ではカメラで撮影した画像を一旦、別のサーバにメールで送信し、別の出力装置からそのサーバへアクセスし、データをダウンロードしてから印刷するという複雑な方法を使用していたが、本発明のWebサーバ付き携帯電話は、カメラで撮影した画像を直接出力装置に送信することにより、前記の手間をかけずに簡単に出力装置から出力することができる。
このように通信端末装置がWebサーバ機能を備えることにより、MLベースのファイルのように一般的なファイルフォーマットを使用できるようになり、汎用性が増す。またクライアント装置はWebサーバ付き通信端末装置にダイレクトに接続することが出来、所望のファイルを汎用のファイルフォーマットで入手することができる。
次に第15の実施形態について説明する。図22に示すようにICタグ(RFIDタグ、無線ICタグ等と呼称されている)にWebサーバ手段を搭載したWebサーバ機能付ICタグとそのICタグと通信を行うリーダライタ装置(クライアント手段)も考えられる。
図22(a)に、Webサーバ付きICタグの構成を示す。ICタグは電波信号を送受信するためのアンテナ用コイル、共振コンデンサ、変復調回路、整流平滑回路からなる無線通信部37とその他はCPU31、ROM32、RAM33、Webサーバ機能部35、ソフトタグ情報送信部36、IP制御部34から構成される。リーダライタ装置から送信されてくる高周波の電力用電波信号をアンテナと共振用コンデンサで受信し、整流平滑回路で整流平滑化して、一定電圧の動作用電源を作成してICタグ内部に供給する。またリーダライタ装置から送信されてくる信号は、電力用電波信号に重畳されており、受信した信号は変復調回路によって復調される。CPU31はROM32に記憶されたプログラムによって動作するものであり、RAM33上に動作に必要なワークエリアを形成しながら、ICタグ全体の動作の制御を行うものである。Webサーバ機能部35は前記Webサーバ手段付き通信端末装置のWebサーバ部と基本的には同じものであり、蓄積しているファイルをクライアントに送信するものである。
図22(b)に、リーダライタ装置の構成を示す。リーダライタ装置は電波信号を送信する送信アンテナ用コイルからなる無線送信部41と電波信号を受信する受信用アンテナコイルからなる無線受信部42と制御回路43とから構成される。制御回路43は、電力用電波信号を送信し、また送信する信号を電力用電波信号に重畳して送信用アンテナから送信する。また受信用アンテナからICタグが送信した信号を受信し、それを復調して受信データを得る。
このようにICタグとリーダライタ装置の間では電波信号を使用して通信を行う。この電波信号を使用したICタグ用無線プロトコルは、例えばコマンド・レスポンスをベースとしたシンプルなプロトコルで構成されてもよいし、その他プロトコルはいろいろあり、また現在も多くのものが提案されているためここでは言及を避けるが、どのようなプロトコルであれ、本発明に使用できるものである。
また、本発明の特徴部分はICタグ用無線プロトコル上で動作するHTTP等のサーバクライアント用のプロトコルであり、その構成と動作は前記Webサーバ機能付き通信端末装置と基本的には同じであるので詳細は省略するが、サーバ手段として蓄積しているファイルの他に、ソフトタグ情報用のファイルがある。
また、前記Webサーバ付きICタグを他の装置に組み込んで利用することも可能である。例えば、カード類(ICカード、定期券、切符、身分証明書、キャッシュカード、クレジットカード等)、法定された書類(紙幣、有価証券、宝くじ等偽造が禁止されているもの)、画像機器装置とそのサプライ(プロセスカートリッジ、トナーカートリッジ、インクカートリッジ、現像ユニット、記録紙)、通信端末装置、その他あらゆる物や装置等に内臓して利用できる。リーダライタ装置も他の装置に組み込んで利用することが出来る。例えば、ICカードリーダ、画像機器装置、通信端末装置などICタグと通信する装置等がある。
このようにICタグにWebサーバ機能を持たせることにより、より多くの情報を蓄積できるのと同時に、より多くの情報をそこから得ることができる。またプロトコルにHTTPを、ファイル形式にMLベースのファイルを使用することにより、より汎用性の高い利用が期待できる。
以上の各実施の形態では、通信端末装置としてIP電話機を、その標準プロトコルとしてSIPを例にとって説明しているが、その他に標準プロトコルとしてH.323、HTTR、MEGACO、PPP等があり、また標準プロトコルではなく、その他のローカルのプロトコルでも本発明の実施は可能である。また端末装置としてはIP電話以外にIPテレビ電話機、IP携帯電話機、IP携帯端末装置、インターネットファックス等に代表されるIP端末装置に適用可能であり、その端末装置で使用される標準プロトコルあるいはローカルプロトコルにも適用できる。
また、通信端末装置としてIP電話機、IPテレビ電話機を挙げたが、通信端末装置としてはその他に無線LANを使用したIP電話、IP端末装置、一般加入者電話機、ファクシミリ装置、通信機能付コンピュータ、携帯電話、PHS、PDA等の通信機能を備えた端末装置があり、それぞれの通信端末装置が使用できる通信プロトコルを使用して実施可能である。ぞれぞれの通信端末装置の構成は公知であるため、ブロック図による図示は省略するが、本発明の特徴に係る手段は各実施の形態と同様に備えているものである。
また、本文中に記載があって、特にブロック図等で図示していない「〜手段」は、専用ハードウェアで構成されているか、あるいはCPU、ROM、RAMと若干のハードウェアで構成されているものである。
また、各フローチャート及びシーケンスチャートに示す処理を、CPU1が実行するためのプロラムは本発明によるプロラムを構成し、このプロラムを記録する記録媒体は、本発明によるコンピュータ読み取り可能な記録媒体を構成する。この記録媒体としては、半導体記憶装置や光学的又は磁気的な記憶装置等を用いることができる。このようなプロラム及び記録媒体を、上述した実施の形態とは異なる構成のシステム等で用い、そこのCPUで上記プロラムを実行させることにより、本発明と実質的に同じ効果を得ることができる。
本発明の第1の実施の形態による動作を示すシーケンスチャートである。 本発明の第2の実施の形態による動作を示すシーケンスチャートである。 本発明の第3の実施の形態による動作を示すシーケンスチャートである。 本発明の第3の実施の形態による動作を示すフローチャートである。 本発明の第6の実施の形態による動作を示すフローチャートである。 本発明の第7の実施の形態による動作を示すフローチャートである。 本発明の第8の実施の形態による動作を示すフローチャートである。 本発明の第9の実施の形態による動作を示すシーケンスチャートである。 本発明の第10実施の形態による制御用パケットの構成図である。 本発明の第11実施の形態による制御用パケットの構成図である。 本発明の第12の実施の形態による動作を示すシーケンスチャートである。 本発明の第13の実施の形態によるIP電話機の構成を示すブロック図である。 本発明の実施の形態によるIP電話機の構成を示すブロック図である。 本発明の実施の形態によるテレビIP電話機の構成を示すブロック図である。 SIPのプロトコルスタックを示す構成図である。 SIPの制御用パケットの構成図である。 SIPのデータ用パケットの構成図である。 UDPデータグラムを示す構成図である。 IPデータグラムを示す構成図である。 SIPの通信シーケンスチャートである。 本発明の第14の実施形態によるプリンタサーバ手段付き画像記録装置の構成を示すブロック図である。 本発明の第15の実施形態によるWebサーバ機能付ICタグとそのICタグと通信を行うリーダライタ装置の構成を示すブロック図であり、(a)は、Webサーバ機能付きICタグの構成を示し、(b)は、リーダライタ装置の構成を示す。 プロフィールデータの表示例を示す図である。
符号の説明
1、21、31 CPU
2、22、32 ROM
3、32、33 ROM
4 操作入力・表示部
5 ハンドセット
6 通話回路
7、27、34 IP制御部
8 回線接続I/F
9、30、36 ソフトタグ情報送信制御部
11 画像処理部
13、35 Webサーバ機能部
24 画像記録部
25 MLインタープリタ部
26 プリンタサーバ部
28 無線通信部
29、35 コマンド変換部
37 無線通信部
41 無線送信部
42 無線受信部
43 制御回路
231 メッセージボタン
232 スクリプトボタン

Claims (25)

  1. 呼設定用制御信号と相手装置に表示させる自装置のソフトタグ情報を送信する呼設定手段を備えたことを特徴とする通信端末装置。
  2. 前記呼設定手段は、前記ソフトタグ情報を含んだ呼設定用制御信号を送信することを特徴とする請求項1記載の通信端末装置。
  3. 前記呼設定手段は、前記呼設定用制御信号の送信とは別に、前記ソフトタグ情報を送信することを特徴とする請求項1記載の通信端末装置。
  4. 前記呼設定手段は、前記呼設定用制御信号を送信した後に、前記ソフトタグ情報を送信することを特徴とする請求項1記載の通信端末装置。
  5. 前記呼設定手段は、前記呼設定用制御信号を送信する前に、前記ソフトタグ情報を送信することを特徴とする請求項1記載の通信端末装置。
  6. 前記呼設定手段は、前記相手装置から前記ソフトタグ情報の送信を要求する信号を受信した場合に、前記ソフトタグ情報を送信することを特徴とする請求項1から5のいずれか1項に記載の通信端末装置。
  7. 相手装置に対してソフトタグ情報の送信を要求する信号を送信する呼設定手段を有することを特徴とする通信端末装置。
  8. 前記呼設定手段は、前記相手装置から呼設定用制御信号を受信した後に、前記相手装置に対して前記ソフトタグ情報の送信を要求する信号を送信することを特徴とする請求項7記載の通信端末装置。
  9. 前記相手装置から受信した前記ソフトタグ情報に基づいて前記相手装置のソフトタグを自装置に表示するソフトタグ表示手段を備えたことを特徴とする請求項7又は8の通信端末装置。
  10. 前記ソフトタグ情報を受信できなかった場合、又は受信したソフトタグ情報を検査し、所定の内容を満たさなかった場合には、相手装置に呼設定を拒否する通信接続判断手段を備えたことを特徴とする請求項7から9のいずれか1項に記載の通信端末装置。
  11. 前記ソフトタグ表示手段によって前記相手装置のソフトタグ情報を表示するとともに、前記受信したソフトタグ情報に基づいて相手装置の呼設定を拒否するか、呼設定を行うかを決定する通信接続判断手段を備えたことを特徴とする請求項7から10のいずれか1項に記載の通信端末装置。
  12. 相手装置から受信した前記ソフトタグ情報を記憶する着信履歴手段を備えたことを特徴とする請求項7から11のいずれか1項に記載の通信端末装置。
  13. 前記着信履歴手段の前記ソフトタグ情報を電話帳手段に登録する電話帳登録手段を備えたことを特徴とする請求項12記載の通信端末装置。
  14. 前記相手装置の電話番号を検出する電話番号検出手段を備え、前記電話番号検出手段が検出した前記相手装置の電話番号のうち、プロバイダを示す番号に応じてそれに対応するプロバイダの名称又はそれに相当する情報、あるいは前記プロバイダで使用することができる機能の名称又はそれに相当する情報の少なくとも一方を報知する報知手段を備えたことを特徴とする請求項1から13のいずれか1項に記載の通信端末装置。
  15. 前記ソフトタグ情報はレイアウト情報とプロフィールデータのうち少なくとも1以上から構成されていることを特徴とする請求項1〜14の通信端末装置。
  16. 前記ソフトタグ情報はML(マークアップ・ランゲージ)言語で記述されたテキストファイルであることを特徴とする請求項1〜15のいずれか1項記載の通信端末装置。
  17. 前記ソフトタグ情報はソフトタグ情報が存在するURI情報であることを特徴とする請求項1から16のいずれか1項に記載の通信端末装置。
  18. 前記ソフトタグ情報の送信は、HTTPプロトコルを使用して送信することを特徴とする請求項1から17のいずれか1項に記載の通信端末装置。
  19. 前記呼設定制御信号の送信は、呼制御用プロトコルを使用して送信することを特徴とする請求項1から18のいずれか1項に記載の通信端末装置。
  20. 標準呼制御用プロトコルを使用して呼設定を行うと共に、前記標準呼制御用プロトコルとは別のローカルプロトコルによって呼設定を行うローカル呼設定手段を備えたことを特徴とする請求項19記載の通信端末装置。
  21. 呼設定用制御信号と相手装置に表示させる自装置のソフトタグ情報を送信する呼設定処理をコンピュータに実行させるプログラム。
  22. 呼設定処理においては、前記相手装置からソフトタグ情報送信要求信号を受信した場合に前記ソフトタグ情報を送信することを特徴とする請求項21記載のプログラム。
  23. 前記相手装置にソフトタグ情報の送信要求信号を送信する送信処理をコンピュータに実行させる請求項21又は22記載のプログラム。
  24. 前記相手装置から受信したソフトタグ情報を表示する表示処理をコンピュータに実行させる請求項23記載のプログラム。
  25. 請求項21から24に記載のプログラムを記録したコンピュータ読み取り可能な記録媒体。
JP2006182672A 2006-06-30 2006-06-30 通信端末装置、プログラム及びコンピュータ読み取り可能な記録媒体 Pending JP2006345542A (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2006182672A JP2006345542A (ja) 2006-06-30 2006-06-30 通信端末装置、プログラム及びコンピュータ読み取り可能な記録媒体

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2006182672A JP2006345542A (ja) 2006-06-30 2006-06-30 通信端末装置、プログラム及びコンピュータ読み取り可能な記録媒体

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2003205116A Division JP2005051445A (ja) 2003-07-31 2003-07-31 通信端末装置、プログラム及びコンピュータ読み取り可能な記録媒体

Publications (1)

Publication Number Publication Date
JP2006345542A true JP2006345542A (ja) 2006-12-21

Family

ID=37642069

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2006182672A Pending JP2006345542A (ja) 2006-06-30 2006-06-30 通信端末装置、プログラム及びコンピュータ読み取り可能な記録媒体

Country Status (1)

Country Link
JP (1) JP2006345542A (ja)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008236350A (ja) * 2007-03-20 2008-10-02 Nec Corp 通信端末および通訳サーバおよび通信システム
JP2009246878A (ja) * 2008-03-31 2009-10-22 Brother Ind Ltd Ip電話端末およびip電話端末を制御するプログラム
JP2010081767A (ja) * 2008-09-29 2010-04-08 Toshiba Corp 電力系統保護制御システム
US8275105B2 (en) 2008-03-31 2012-09-25 Brother Kogyo Kabushiki Kaisha IP telephone terminal
JP2017135535A (ja) * 2016-01-27 2017-08-03 京セラ株式会社 通話装置および通話装置の制御方法、制御プログラム並びに制御装置

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008236350A (ja) * 2007-03-20 2008-10-02 Nec Corp 通信端末および通訳サーバおよび通信システム
JP2009246878A (ja) * 2008-03-31 2009-10-22 Brother Ind Ltd Ip電話端末およびip電話端末を制御するプログラム
JP4683065B2 (ja) * 2008-03-31 2011-05-11 ブラザー工業株式会社 Ip電話システムおよびip電話システム用プログラム
US8275105B2 (en) 2008-03-31 2012-09-25 Brother Kogyo Kabushiki Kaisha IP telephone terminal
JP2010081767A (ja) * 2008-09-29 2010-04-08 Toshiba Corp 電力系統保護制御システム
JP2017135535A (ja) * 2016-01-27 2017-08-03 京セラ株式会社 通話装置および通話装置の制御方法、制御プログラム並びに制御装置

Similar Documents

Publication Publication Date Title
US7791748B2 (en) Image communication control method, image communication control program, and image communication apparatus
US7453827B2 (en) IP telephone and IP adaptor
JP6151911B2 (ja) 画像処理装置、その制御方法、及びプログラム
US7283273B2 (en) Image communication apparatus using IP addresses and control method thereof, program, and storage medium
JP4185891B2 (ja) 通信端末、および通信端末の制御方法
JP2005109920A (ja) 画像情報・タグ情報制御システム、デジタルカメラ装置、携帯型電話機、画像情報・タグ情報制御方法、画像処理プログラムおよび記録媒体
JP2006345542A (ja) 通信端末装置、プログラム及びコンピュータ読み取り可能な記録媒体
US7068763B2 (en) Communication terminal device
US7433699B2 (en) Information processing system and information processing method
JP2005051445A (ja) 通信端末装置、プログラム及びコンピュータ読み取り可能な記録媒体
US20050243871A1 (en) Communication deivce and communication method
JP2007300648A (ja) 通信端末装置
JP3875710B2 (ja) 通信装置及び通信方法
JP2006121731A (ja) 呼出システム、呼出装置及び発呼装置
JP4039973B2 (ja) Ip端末装置
JP2006014008A (ja) 呼出システム及び呼出方法
JP4787577B2 (ja) 携帯端末装置
JP2006014355A (ja) 通信端末装置
JP3925728B2 (ja) ファクシミリ装置
JP3930030B2 (ja) 画像処理装置、通信装置及び画像処理装置の制御方法
JP2005354689A (ja) 通信装置及び通信方法
JP2005159788A (ja) 画情報編集システム、画情報編集装置、及び、通信装置
JP3997934B2 (ja) インターネットファクシミリ装置及びその制御方法
JP2022183642A (ja) 電話システム及び電話接続方法
JP2006203883A (ja) 通信端末装置

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20080912

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20080924

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20081105

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20090623

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20090807

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20100209