(57)【要約】【課題】相手側の端末操作を不要にして相手側の端末に画像データを登録できる画像登録方法および画像登録装置を提供する。【解決手段】第一の端末（発信側端末）の識別データが登録されたデータレコードが第二の端末（受信側端末）に存在し、且つ、そのデータレコードの所定フィールドにデータが登録されていない場合に、第二の端末から第一の端末へデータ転送要求を送信し、このデータ転送要求に応答して第一の端末から第二の端末へ送信されたデータを、第二の端末の上記データレコードの所定フィールドに登録する。【選択図】      図７
2008136252.tif 000002
【特許請求の範囲】
【請求項１】
第一の端末から第二の端末へ該第一の端末の識別データを含む第一のデータ群を送信する第１ステップと、
該第一のデータ群の受信イベントに応答して第一のデータ群に含まれる識別データに一致するデータを持つデータレコードを検索する第２ステップと、
該当するデータレコードが第二の端末に存在し且つそのデータレコードの所定フィールドにデータが格納されていない場合に第二の端末から第一の端末に対してデータ要求情報を含む第二のデータ群を送信する第３ステップと、
該第二のデータ群の受信イベントに応答して予め用意されたデータを含む第三のデータ群を第一の端末から第二の端末に送信する第４ステップと、
該第三のデータ群の受信イベントに応答して該第三のデータ群からデータを取り出して前記データレコードの所定フィールドに登録する第５ステップと、
を含むことを特徴とするデータ登録方法。
【請求項２】
ユーザ−ユーザインフォメーションをサポートする通信プロトコルに従って相互にデータ伝送を行う発信側端末および受信側端末を有する通信システムにおいて、
発信側端末は、
自己の登録番号をユーザ−ユーザインフォメーションにセットして送信する第１送信手段と、
受信側端末から送信されたユーザ−ユーザインフォメーションにデータ転送要求がセットされていた場合に所定のデータをユーザ−ユーザインフォメーションにセットして送信する第２送信手段と、
を備え、受信側端末は、
発信側端末から送信されたユーザ−ユーザインフォメーションにセットされた登録番号をキーワードにして自端末のデータレコードから同一の登録番号を有するレコードを検索する検索手段と、
この検索手段による検索結果により当該レコードの所定フィールドにデータが登録されていないことを判別した場合にデータ転送要求をユーザ−ユーザインフォメーションにセットして発信側端末に送信する第３送信手段と、
該データ転送要求に応答して発信側端末から送信されたユーザ−ユーザインフォメーションにセットされたデータを取り出し前記レコードの所定フィールドに登録するデータ登録手段と、
を備えたことを特徴とするデータ登録装置。
【請求項３】
受信側端末は、さらに、前記検索手段が、発信側端末から送信されたユーザ−ユーザインフォメーションにセットされた登録番号をキーワードにして自端末のデータレコードから同一の登録番号を有するレコードを検索した結果、該当するレコードが見つからなかった場合に、当該データレコードの空きレコードに当該登録番号を登録する登録番号登録手段を備えたことを特徴とする請求項２記載のデータ登録装置。
【請求項４】
ユーザ−ユーザインフォメーションをサポートする通信プロトコルに従って他の通信端末との間で相互にデータ伝送を行う通信端末において、
自己の登録番号をユーザ−ユーザインフォメーションにセットして送信する第１送信手段と、
受信側端末から送信されたユーザ−ユーザインフォメーションにデータ転送要求がセットされていた場合に所定のデータをユーザ−ユーザインフォメーションにセットして送信する第２送信手段と、
を備えたことを特徴とする通信端末。
【請求項５】
ユーザ−ユーザインフォメーションをサポートする通信プロトコルに従って他の通信端末との間で相互にデータ伝送を行う通信端末において、
発信側端末から送信されたユーザ−ユーザインフォメーションにセットされた登録番号をキーワードにして自端末のデータレコードから同一の登録番号を有するレコードを検索する検索手段と、
この検索手段の検索結果により当該レコードの所定フィールドにデータが登録されていないことが判別された場合にデータ転送要求をユーザ−ユーザインフォメーションにセットして発信側端末に送信する第３送信手段と、
該データ転送要求に応答して発信側端末から送信されたユーザ−ユーザインフォメーションにセットされたデータを取り出し前記レコードの所定フィールドに登録するデータ登録手段と、
を備えたことを特徴とする通信端末。
【請求項６】
発信側端末から送信されたユーザ−ユーザインフォメーションにセットされた登録番号をキーワードにして自端末のデータレコードから同一の登録番号を有するレコードを検索した結果、該当するレコードが見つからなかった場合に、当該データレコードの空きレコードに当該登録番号を登録する登録番号登録手段を備えたことを特徴とする請求項５記載の通信端末。
【請求項７】
第一の端末から第二の端末へ該第一の端末の機種データを送信する第１ステップと、
該機種データを受信した前記第二の端末で当該機種データをデータレコードに登録する第２ステップと、
前記第二の端末から前記第一の端末へ所定のデータ通信を行う際に前記データレコードを検索して前記第一の端末の機種データを取り出すとともに該機種データに対応したデータ通信動作態様となるように前記第二の端末の動作態様を変化させる第３ステップと、
を含むことを特徴とするデータ登録方法。
【請求項８】
前記所定のデータ通信はメール通信であることを特徴とする請求項７記載のデータ登録方法。
【請求項９】
前記動作態様はプログラム制御方式によるものであって、プログラムの選択によって動作態様の変更を行うものであることを特徴とする請求項７記載のデータ登録方法。
【請求項１０】
第一の端末から第二の端末へ該第一の端末の機種データを送信する送信手段と、
該機種データを受信して前記第二の端末のデータレコードに登録する登録手段と、
前記第二の端末から前記第一の端末へ所定のデータ通信を行う際に前記データレコードを検索して前記第一の端末の機種データを取り出すとともに該機種データに対応したデータ通信動作態様となるように前記第二の端末の動作態様を変化させる動作態様変更手段と、
を備えたことを特徴とするデータ登録装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、例えば、画像や文字情報の表示が可能な表示装置を備えた携帯型通信端末など（以下、単に「端末」という。）に適用して好ましいデータ登録方法およびデータ登録装置ならびに通信端末に関する。詳しくは、相手側の端末操作を不要にして相手側の端末に画像データ等を遠隔登録したり、相手側端末がサポートする文字メールの規格に関する情報を取得してその情報を自端末の電話帳等に登録したりするデータ登録方法およびデータ登録装置ならびに通信端末に関する。
【背景技術】
【０００２】
近時、携帯電話機などの携帯型通信端末にあっては、画像の表示が可能な高精細な表示装置（一般に液晶ディスプレイ）を備えることが普通になってきており、こうしたハードウェアの進歩を踏まえて、上記端末にあっては、例えば、アドレス帳（または「電話帳」ともいう。）に顔写真等の画像データを登録することにより、電話番号や名前といった文字主体の情報による旧来の情報管理のみならず、画像も表示可能にして視覚効果に訴える直感的で分かりやすい情報管理を採用する傾向になってきた。
【０００３】
具体的な例を説明する。一般に携帯電話機は、通話先の電話番号（端末の登録番号）や名前等の文字情報を登録するデータエリアを備え、さらに、自分の情報を登録するデータエリアを備える。これらのデータエリアは、通常、フラッシュメモリ等の不揮発性の半導体記憶デバイスによって構成されている。便宜的に、前者のデータエリアを「アドレス帳」、後者のデータエリアを「自己紹介データエリア」と呼ぶことにすると、アドレス帳には上記のとおり、通話先の登録番号や名前等が適宜に登録されており、自己紹介データエリアには、その携帯電話機の登録番号（携帯電話機の購入時に既定値として登録される情報）や使用者名が登録されているが、近時、上記アドレス帳に顔写真等の画像データを登録することによって、通話相手を視覚的に確認できるようにし、電話のかけ間違い等を防止できる情報管理が行われるようになってきた。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
（１）  しかしながら、上記アドレス帳に顔写真等の画像データを登録して、その画像データを表示するようにした場合、電話のかけ間違い等を防ぐことができる点で有益であるものの、画像データの登録作業が面倒であり、使い勝手の点で改善すべき技術課題があった。すなわち、アドレス帳に顔写真等の画像データを登録するには、相手から顔写真データを送信してもらって、その画像データを自分の携帯電話機に登録するか、または、ディジタルカメラ等を用いて相手の顔写真を撮影し、その画像データを自分の携帯電話機に登録するかのいずれかの作業を行う必要があり、いずれの作業も手間がかかって面倒であるという問題点があった。
【０００５】
（２）  また、近時の携帯電話機は、音声通話のみならず、文字メール等のショートメッセージ送受信機能（以下、単に「メール機能」という。）を備えているものが多く、このようなメール機能を備えた携帯電話機にあっては、情報を文字の形で伝達できるため、音声による情報伝達の欠点（聞き間違い）を解消できるばかりか、相手の都合のよいときに情報を確認してもらえるという音声通話にない利便性が得られる。
【０００６】
しかしながら、かかるメール機能の規格（送受信プロトコルや取り扱い可能な文字種あるいは文字数など）は、携帯電話のサービス会社（以下「電話会社」という。）ごとにまちまち（例えば、Ｃメール、Ｅメール、αメールなどと略称される規格が知られている。）であり、当然ながら規格の異なるメール機能同士の正常な情報伝達は保証されないから、メール伝達の相手が同一メール機能の携帯電話機を所持するユーザ間に限定されることとなる。
【０００７】
ここで、メール機能を利用しようとするユーザの行動を検証する。上記のとおり、携帯電話機のメール機能は電話会社ごとに規格がまちまちで同一規格同士でなければ正常な情報伝達を行うことができないため、ユーザは、まず、自分の所有する携帯電話機（自端末）のメール機能の規格を把握する。次に、ユーザは、知人等、メール伝達の可能性のある他ユーザの携帯電話機（他端末）の機種や型番などから当該他端末のメール規格を把握する。そして、自端末と同一のメール規格をサポートする他端末を所有するユーザとの間でメール伝達が可能であることを把握し、以降、このユーザとの間で適宜にメールのやり取りを行うことになる。
【０００８】
しかしながら、このような人為的把握は不正確であるうえ、他ユーザの所有する携帯電話機の機種変更（特に異なる電話会社への機種変更）にも即応的に対応できないという欠点がある。すなわち、他端末の機種や型番などの聞き間違いによる誤ったメール機能の把握を否めないばかりか、あるユーザが自端末と同じ電話会社の携帯電話機に機種変更した場合または自端末と異なる電話会社の携帯電話機に機種変更した場合などのケースを即座に把握することができないという欠点があり、したがって、あるユーザとの間のメール伝達が突然できなくなったり、あるいは、あるユーザとの間でメール伝達が可能であるにもかかわらず、そのことを知らないばかりに、当該ユーザとの間でせっかくのメール機能を利用できないといった問題点があった。
【０００９】
そこで、本発明が解決しようとする課題は、相手側の端末操作を不要にして相手側の端末に画像データ等の所要のデータを登録できるようにし、または、相手側端末がサポートするメール規格に関する情報を取得してその情報を自端末の電話帳等に登録できるようにしたデータ登録方法およびデータ登録装置を提供し、以って、このデータ登録方法およびデータ登録装置を適用した携帯電話機などの携帯型通信端末の使い勝手向上を図ることにある。
【課題を解決するための手段】
【００１０】
この発明によるデータ登録方法は、第一の端末から第二の端末へ該第一の端末の識別データを含む第一のデータ群を送信する第１ステップと、該第一のデータ群の受信イベントに応答して第一のデータ群に含まれる識別データに一致するデータを持つデータレコードを検索する第２ステップと、該当するデータレコードが第二の端末に存在し且つそのデータレコードの所定フィールドにデータが格納されていない場合に第二の端末から第一の端末に対してデータ要求情報を含む第二のデータ群を送信する第３ステップと、該第二のデータ群の受信イベントに応答して予め用意されたデータを含む第三のデータ群を第一の端末から第二の端末に送信する第４ステップと、該第三のデータ群の受信イベントに応答して該第三のデータ群からデータを取り出して前記データレコードの所定フィールドに登録する第５ステップと、を含むというものである。
これによれば、第一の端末の識別データが登録されたデータレコードが第二の端末に存在し、且つ、そのデータレコードの所定フィールドにデータが登録されていない場合、第二の端末から第一の端末へデータ転送要求が送信され、このデータ転送要求に応答して第一の端末から第二の端末へ送信されたデータが、第二の端末の上記データレコードの所定フィールドに登録される。
また、この発明によるデータ登録装置は、ユーザ−ユーザインフォメーションをサポートする通信プロトコルに従って相互にデータ伝送を行う発信側端末および受信側端末を有する通信システムにおいて、発信側端末は、自己の登録番号をユーザ−ユーザインフォメーションにセットして送信する第１送信手段と、受信側端末から送信されたユーザ−ユーザインフォメーションにデータ転送要求がセットされていた場合に所定のデータをユーザ−ユーザインフォメーションにセットして送信する第２送信手段と、を備え、受信側端末は、発信側端末から送信されたユーザ−ユーザインフォメーションにセットされた登録番号をキーワードにして自端末のデータレコードから同一の登録番号を有するレコードを検索する検索手段と、この検索手段による検索結果により当該レコードの所定フィールドにデータが登録されていないことを判別した場合にデータ転送要求をユーザ−ユーザインフォメーションにセットして発信側端末に送信する第３送信手段と、該データ転送要求に応答して発信側端末から送信されたユーザ−ユーザインフォメーションにセットされたデータを取り出し前記レコードの所定フィールドに登録するデータ登録手段と、を備えるというものである。
これによれば、発信側端末の登録番号が登録されたデータレコードが受信側端末に存在し、且つ、そのデータレコードの所定フィールドにデータが登録されていない場合、受信側端末から発信側端末へデータ転送要求が送信され、このデータ転送要求に応答して発信側端末から受信側端末へ送信されたデータが、受信側端末の上記データレコードの所定フィールドに登録される。
または、前記受信側端末は、さらに、前記検索手段が、発信側端末から送信されたユーザ−ユーザインフォメーションにセットされた登録番号をキーワードにして自端末のデータレコードから同一の登録番号を有するレコードを検索した結果、該当するレコードが見つからなかった場合、空きレコードに当該登録番号を登録する登録番号登録手段を備えるというものである。
これによれば、発信側端末の登録番号が受信側端末のデータレコードに自動登録される。
または、この発明によるデータ登録方法は、第一の端末から第二の端末へ該第一の端末の機種データを送信する第１ステップと、該機種データを受信した前記第二の端末で当該機種データをデータレコードに登録する第２ステップと、前記第二の端末から前記第一の端末へ所定のデータ通信を行う際に前記データレコードを検索して前記第一の端末の機種データを取り出すとともに該機種データに対応したデータ通信動作態様となるように前記第二の端末の動作態様を変化させる第３ステップと、を含む。
これによれば、第二の端末に第一の端末の機種データを登録し、第二の端末から第一の端末宛てに所定のデータ通信を行う際に、第二の端末の動作態様が第一の端末の機種データに対応した特定の動作態様に変更される。
または、前記所定のデータ通信はメール通信である。
これによれば、第二の端末から第一の端末宛てにメール送信する際に、第一の端末の機種データに対応して特定規格のメールが送信される。
または、前記動作態様はプログラム制御方式によるものであって、プログラムの選択によって動作態様の変更を行うものである。
これによれば、プログラムを入れ替えるだけで様々な動作態様に対応できる。
または、この発明によるデータ登録装置は、第一の端末から第二の端末へ該第一の端末の機種データを送信する送信手段と、該機種データを受信して前記第二の端末のデータレコードに登録する登録手段と、前記第二の端末から前記第一の端末へ所定のデータ通信を行う際に前記データレコードを検索して前記第一の端末の機種データを取り出すとともに該機種データに対応したデータ通信動作態様となるように前記第二の端末の動作態様を変化させる動作態様変更手段と、を備える。
これによれば、第二の端末に第一の端末の機種データを登録し、第二の端末から第一の端末宛てに所定のデータ通信を行う際に、第二の端末の動作態様が第一の端末の機種データに対応した特定の動作態様に変更される。
【発明の効果】
【００１１】
この発明によるデータ登録方法によれば、第一の端末の識別データが登録されたデータレコードが第二の端末に存在し、且つ、そのデータレコードの所定フィールドにデータが登録されていない場合、第二の端末から第一の端末へデータ転送要求が送信され、このデータ転送要求に応答して第一の端末から第二の端末へ送信されたデータが、第二の端末の上記データレコードの所定フィールドに登録される。
したがって、第二の端末におけるデータレコードの検索操作やデータの未登録チェックおよび当該データレコードへのデータの登録操作を自動化でき、第二の端末における当該一連の操作を不要化できる。
また、この発明によるデータ登録装置によれば、発信側端末の登録番号が登録されたデータレコードが受信側端末に存在し、且つ、そのデータレコードの所定フィールドにデータが登録されていない場合、受信側端末から発信側端末へデータ転送要求が送信され、このデータ転送要求に応答して発信側端末から受信側端末へ送信されたデータが、受信側端末の上記データレコードの所定フィールドに登録される。
したがって、受信側端末におけるデータレコードの検索操作やデータの未登録チェックおよび当該データレコードへのデータの登録操作を自動化でき、受信側端末における当該一連の操作を不要化できる。
また、この発明によるデータ登録装置によれば、前記受信側端末は、さらに、前記検索手段が、発信側端末から送信されたユーザ−ユーザインフォメーションにセットされた登録番号をキーワードにして自端末のデータレコードから同一の登録番号を有するレコードを検索した結果、該当するレコードが見つからなかった場合、空きレコードに当該登録番号を登録する登録番号登録手段を備えるので、発信側端末の登録番号が受信側端末のデータレコードに自動登録される。
したがって、受信側端末のアドレス帳の新規登録を、発信側端末から遠隔操作で行うことができる。
また、この発明によるデータ登録方法およびデータ登録装置によれば、第二の端末に第一の端末の機種データを登録し、第二の端末から第一の端末宛てに所定のデータ通信を行う際に、第二の端末の動作態様が第一の端末の機種データに対応した特定の動作態様に変更される。したがって、両端末間の機種の違いに伴うデータ通信の不整合を回避することができる。
また、前記所定のデータ通信をメール通信とすることにより、規格の異なるメールの送信を防止でき、メール不達を確実に回避することができる。
また、前記動作態様をプログラム制御方式にすることにより、プログラムを入れ替えるだけで様々な動作態様に対応することができ、システムの柔軟性を向上できる。
【発明を実施するための最良の形態】
【００１２】
以下、本発明の実施の形態を、ＰＨＳ（personal handy-phone system）方式に基づく携帯電話機を例にして図面を参照しながら説明する。なお、この例示はあくまでも説明上の便宜であり、当該方式（ＰＨＳ）または携帯電話機に限定されないことはもちろんである。例えば、自動車電話やＣＤＭＡ（Code DivisionMultiple Access）等の方式であってもよいし、携帯電話機以外の携帯型通信端末〔例：モデム機能を搭載したＰＤＡ（personal digital assistant）やモバイルパソコン等の携帯情報端末またはページャなど〕であってもよい。
【００１３】
＜第１の実施の形態＞
図１は、発明の要旨に記載の第一の端末、第二の端末、発信側端末、受信側端末に相当する携帯電話機１のブロック図であり、１０は所定の周波数域（主として１．９ＧＨｚ帯）に同調したアンテナ、１１はアンテナ１０を送受信で共有する送受共有部、１２は送信信号の増幅等を行う送信部、１３は受信信号の増幅等を行う受信部、１４は送信信号／受信信号の変調／復調を行う変復調部、１５は送受信信号のＴＤＭＡ（Time Division Multiple Access）／ＴＤＤ（Time Division Duplex）処理等を行うチャネルコーデック部、１６は音声信号のＡＤＰＣＭ（Adaptive Differential Predictive Coding Modulation）処理等を行う音声コーデック部、１７は音声の送受話を行う送受話器、１８は携帯電話機の動作制御を行う制御部（発明の要旨に記載の第１送信手段、第２送信手段、第３送信手段、データ登録手段、登録番号登録手段、検索手段、送信手段、登録手段、動作態様変更手段に相当）である。
【００１４】
制御部１８は、図示の例の場合、特に限定しないが、プログラム制御型のものであり、例えば、図中破線で示すように、チャネルコーデック１５などとの間でデータの入出力を行う入出力部１８ａ、携帯電話機の制御プログラムを格納するプログラムＲＯＭ１８ｂ、主記憶として用いられるユーザワークＲＡＭ１８ｃ、アドレス帳などのユーザデータを格納する不揮発性メモリ１８ｄ、電話番号や送受信情報（ショートメッセージ等の文字情報および画像情報）および動作メッセージ表示用の表示部１８ｅ、電話番号入力用や文字情報入力用のキー群（テンキーなど）ならびに各種機能キー群（オフフックキーなど）を含むキー入力部１８ｆ、プログラムＲＯＭ１８ｂに格納された制御プログラムを実行するＣＰＵ１８ｇ、外部装置（例えば、パソコンやディジタルカメラ等）との間でデータの入出力を行う外部インターフェース１８ｈなどを備えている。
【００１５】
制御部１８は、プログラムＲＯＭ１８ｂに格納された制御プログラムをＣＰＵ１８ｇで実行することにより、チャネルコーデック部１５などをコントロールしてＰＨＳ基地局との間の通信制御を所定のプロトコル（後述）に従って実行し、端末間の音声通話やデータ伝送を行い、さらに、ショートメッセージの作成および閲覧、ならびにアドレス帳や自己紹介データの管理などの各種制御を実行する。
【００１６】
かかる構成を有する携帯電話機１は、ＰＨＳ通信システムの移動機（ＰＳ：Personal Stationともいう。）として用いられる。ＰＨＳ通信システムは、サービスエリアを複数のゾーン（セルともいう。）に分け、各ゾーンの中央部付近に基地局（ＣＳ：Cell Stationともいう。）を設けるとともに、各基地局をサービス統合ディジタル通信網（ＩＳＤＮ：Integrated Services Digital Network）などの公衆回線網に接続して構成される。携帯電話機１は、最寄りの基地局ＣＳからのセル情報（ＣＳ−ＩＤ）を受信して自ら記憶しているセル情報と比較し、セル情報が異なる場合に、当該基地局ＣＳを介してシステム内のデータベースに現在位置（ＣＳ−ＩＤ）を登録するとともに、当該基地局ＣＳを介して他の端末を随時に呼び出し、または、他の端末からの呼び出しに応答して、その端末との間で呼を設定して音声やデータの送受信を行う。
【００１７】
例えば、他の端末との間で音声による通信を行う場合は、まず、キー入力部１８ｆのテンキーを操作して呼び出し先端末の登録番号を入力する。または、その登録番号がアドレス帳に登録済みであれば表示部１８ｅに表示されたアドレス帳リストから当該登録番号を選択する。そして、キー入力部１８ｆのオフフックキーを押して呼び出し先端末の音声応答を待ってから音声による通信を開始する。
【００１８】
あるいは、他の端末との間でデータ通信、例えば、ショートメッセージの送信を行う場合は、まず、キー入力部１８ｆのテンキーを操作して呼び出し先端末の登録番号を入力する。または、その登録番号がアドレス帳に登録済みであれば表示部１８ｅに表示されたアドレス帳リストから当該登録番号を選択する。そして、キー入力部１８ｆのテンキーを文字入力モードに切り換えて、所要の文字列を入力し、ショートメッセージを作成した後、キー入力部１８ｆのオフフックキーを押して呼び出し先端末にショートメッセージを送信する。
【００１９】
一般にショートメッセージ等の付加データは、後述の発着信シーケンスにおける付加情報として受信側端末に送られており、受信側端末では応答操作（キー入力部１８ｆのオフフックキー操作等）を行うことなく当該付加データを受信できるようになっている。なお、かかる付加データは、上記ショートメッセージのみならず、例えば、受信側端末が親子式のような複数の端末で構成された電話機である場合に、各々の端末にあらかじめ割り当てられた識別情報（いわゆるサブアドレス）を送るためにも利用されている。
【００２０】
かかるショートメッセージやサブアドレス等を送るための付加情報としては、例えば、ＡＴＭ（Asynchronous Transfer Mode）ネットワークプロトコルで規定されたＡＴＭアダプテーションレイヤ、いわゆるＡＡＬレイヤの“ユーザ−ユーザインフォメーション”（以下「ＵＵＩ」と略す）を使用することができる。ＵＵＩは、後述するように、移動機ＰＳと基地局ＣＳの間で行われる発着信シーケンスの呼設定メッセージと呼設定受付けメッセージに付加することが認められており、また、移動機ＰＳと基地局ＣＳの間で行われる切断シーケンスの切断メッセージに付加することも認められている。
【００２１】
図２は、不揮発性メモリ１８ｄに形成されたアドレス帳２０の概念図であり、アドレス帳２０の各データレコードは、例えば、“ＩＤ”、“登録番号”、“氏名”および“顔写真データ”といった適宜の名称が与えられた複数のフィールド２０ａ〜２０ｄに分けられている。ここに、ＩＤフィールド２０ａは各データレコードのインデックス格納用フィールドであり、アドレス帳２０の内部で重複しないユニークな値（図では最大レコード数を１０００と仮定し、００１から９９９までの一連番号）が格納されている。登録番号フィールド２０ｂは通話相手の携帯電話機の登録番号（いわゆる電話番号）格納用フィールドであり、図では便宜的に３桁−４桁−４桁（この桁構成は自動車電話やＰＨＳの番号方式“０Ａ０”系であるが、これに限定されないことはもちろんである。他の番号形式、例えば一般加入電話の“０ＡＢＣＤＥＦＧＨＪ”系などであってもよい。）の情報が格納されている。氏名フィールド２０ｃは通話相手の名前（またはニックネーム等）格納用フィールドであり、図では便宜的に記号で模式化した情報が格納されている。顔写真データフィールド２０ｄ（発明の要旨に記載の所定フィールドに相当）は顔写真等の画像データ格納用フィールドであり、図では便宜的に人間の上半身を模したマークで画像データ格納済みを表し、横線で画像データ未格納を表している。
【００２２】
ここで、ＩＤコード＝“９９９”のレコードは、携帯電話機の所有者情報格納用であり、このレコードに格納された電話番号（“０７０−１１１１−９９９９”）、氏名（“◎◎◎◎”）および顔写真データは、その携帯電話機の登録番号、使用者名および同者の顔写真データである。したがって、ＩＤコード＝“９９９”のレコード（以下「最終レコード」ともいう。）は、前述の従来技術で説明した二つのデータエリアのうちの「自己紹介データエリア」に相当し、最終レコード以外のレコード群（ＩＤコード＝“００１”からＩＤコード＝“９９８”までの９９９レコード）は、前述の従来技術で説明した二つのデータエリアのうちの「アドレス帳」に相当する。
【００２３】
図３は、携帯電話機１（ＰＳ）と基地局ＣＳの間で行われる発着信シーケンスのタイムランを示す図である。まず、発信シーケンスを説明する。発信とは、携帯電話機（以下「端末」と略す）からの要求によって、音声通信やデータ伝送を行うために使用するサービスチャネル（ＳＣＨ：Service Channel）を確立するための呼接続フェーズである。
【００２４】
図３（ａ）において、ＳＣＨを確立するためには、リンクチャネル確立要求とリンクチャネル割り当ての二つのメッセージを論理制御チャネル（ＬＣＣＨ：Logical Control Channel）で送受信する。端末がリンクチャネル割り当てを受信後、割り当てられたリンクチャネル（ＬＣＨ：Link Channel）が空きチャネルであり、通信に使用できることが可能であることを確認し、指定されたＬＣＨにおいて同期バーストを送受信する。基地局ＣＳは端末ＰＳからの同期バーストの受信後、端末ＰＳに同期バーストを送信する。
【００２５】
端末ＰＳは、基地局ＣＳからの同期バースト受信によりＬＣＨの同期を確立し、端末ＰＳ−基地局ＣＳ間のＬＣＨにおけるＯＳＩ（Open System Interconnection）参照モデルのレイヤ１（物理媒体からなる通信回線を用いてビット列の伝送を保証し、使用周波数、送信出力、変調方式やアクセス方式などを規定するレイヤ）を確立する。
【００２６】
次いで、低速付随制御チャネル（ＳＡＣＣＨ：Slow Associated Channel）と高速付随制御チャネル（ＦＡＣＣＨ：Fast Associated Channel）の両チャネルを用いてレイヤ２（レイヤ１の提供するビット列の伝送機能を利用してノード間でトランスペアレントな高信頼のデータ伝送を実現するレイヤ）を確立し、その後、レイヤ３（レイヤ２の提供するデータ伝送機能を使ってエンドシステム相互間でデータ転送を行い、発着信の呼接続、回線監視、基地局間移動時の接続切り換え、終話処理などを規定するレイヤ）の呼制御機能（ＣＣ：Call Control）、無線管理機能（ＲＴ：Radio Frequency Transmission Management）、移動管理機能（ＭＭ：Mobility Management）などの制御信号を用いてネットワークと端末との間で、それぞれ無線資源の管理や移動性支援および回線呼接続に関するネゴシエーションを行い、ＳＣＨを確立して通信フェーズ（図中“通話中”と記した太線矢印）に移行する。
【００２７】
次に、着信シーケンスを説明する。着信とは、ネットワークからの要求によって、音声通信やデータ伝送を行うために使用するＳＣＨを確立するための呼接続フェーズである。
【００２８】
図３（ｂ）において、待ち受け中の端末ＰＳは、基地局ＣＳから送信される着呼メッセージを受信し、着信を検出する。着信を検出した端末ＰＳは、発信時と同様にリンクチャネル確立要求とリンクチャネル割り当ての二つのメッセージをＬＣＣＨで送受信することによりＬＣＨを確保し、同期バーストにより同期確立を行い、ＬＣＨを確立した後、レイヤ２を確立する。レイヤ２確立後は、ＣＣ、ＲＴ、ＭＭのレイヤ３の制御信号によりネットワークと端末間で、それぞれ無線資源の管理や移動性支援および回線呼接続に関するネゴシエーションを行い、ＳＣＨを確立して通信フェーズ（図中“通話中”と記した太線矢印）に移行する。
【００２９】
図４は、切断シーケンスのタイムランを示す図である。切断とは、端末ＰＳ−基地局ＣＳ間で確立したＳＣＨを解放し、無線チャネルを切断することにより、通信を終了することである。切断には、端末側切断（ＰＳ側切断ともいう。）と基地局側切断（ＣＳ側切断ともいう。）の二つの切断手順がある。切断は、まず、レイヤ３の呼制御信号（ＣＣ）を用いて切断、解放、解放完了メッセージのやり取りにより呼の解放を行う。その後、レイヤ２を解放し、ＲＴの無線チャネル切断と無線チャネル切断完了の二つのメッセージを用いて無線資源の解放、すなわち、レイヤ１の解放を行い、端末ＰＳは、レイヤ１解放後、待ち受け処理に移行する。
【００３０】
ここで、上述の発着信シーケンスの「呼設定」と「呼設定受付け」の二つのメッセージには前述のＵＵＩを付加することができる。例えば、発着信シーケンスの呼設定メッセージにＵＵＩを付加し、そのＵＵＩにショートメッセージやサブアドレスなどの付加データをセットすれば、端末−端末間でショートメッセージやサブアドレスなどの送受信を行うことができる。また、切断シーケンスの「切断」メッセージにも前述のＵＵＩを付加することができる。
【００３１】
以下、説明の都合上、端末−端末間のデータ転送を想定し、発信側端末の「呼設定」メッセージに付加されるＵＵＩを“ＵＵＩの第１パケット”と呼び、着信側端末の「呼設定受付け」メッセージに付加されるＵＵＩを“ＵＵＩの第２パケット”と呼び、且つ、切断時に発信側端末の「切断」メッセージに付加されるＵＵＩを“ＵＵＩの第３パケット”と呼ぶことにする。
【００３２】
なお、パケット（レイヤによっては「フレーム」ともいう。）とは一般に荷札（情報の宛先）を付けた情報の集まりのことで、特にＡＴＭ等のパケット交換網でやり取りされる１交換単位の情報群と解されているが、本明細書ではこのような狭い意味に限定しない。端末−端末間でやり取りされる各種メッセージの付加情報として認められたあらゆる形式の情報群を含む用語として使用する。したがって、上述の「呼設定」、「呼設定受付け」および「切断」メッセージは、端末−端末間でやり取りされる各種メッセージのうちＵＵＩの使用が認められたメッセージの一例にすぎない。
【００３３】
次に、作用を説明する。
図５は、発信側端末で実行されるショートメッセージ送信処理プログラムの概略的なフローチャートを示す図である。このプログラムを開始すると、まず、ステップＳ１１でショートメッセージの作成と送信相手の指定処理を実行する。ショートメッセージの作成処理では、表示部１８ｅにメッセージの編集画面を表示し、キー入力部１８ｆのテンキーを文字入力モードに切り換えて、ユーザによる文字入力を受付ける。
【００３４】
そして、ショートメッセージの作成を完了すると、ステップＳ１２に進み、自己紹介データエリアに自分の顔写真データが登録されているか否かを判定して、否（未登録）を判定した場合は、ステップＳ１３で表示部１８ｅに所要のメッセージ、例えば、「“顔写真データが未登録です。登録する場合は○キーを、登録しない場合は×キーを押してください。”」（但し、○×は任意キーを示す）を表示し、○キーが押された場合はステップＳ１４に進んで自己紹介データエリアに自分の顔写真データを登録する処理を行った後、ステップＳ１５で自端末の登録番号をアドレス帳２０の最終レコード（自己紹介データエリア）の登録番号フィールド２０bから読み出す処理を行い、一方、×キーが押された場合は、ステップＳ１４をパスしてステップＳ１５に進む。
【００３５】
なお、顔写真データの登録／未登録の判定は、アドレス帳２０（図２参照）の最終レコード（ＩＤコード＝“９９９”のレコード）の顔写真データフィールド２０ｄを調べ、その値がＮｕｌｌまたは空（Ｅｍｐｔｙ）であればデータ未登録、そうでなければデータ登録として判断する。また、ステップＳ１２における顔写真データの登録処理は、例えば、外部インターフェース１８ｈを介してパーソナルコンピュータやディジタルカメラなどから自分の顔写真データを取り込んで、アドレス帳２０の最終レコードの顔写真データフィールド２０ｄに登録してもよいし、あるいは、撮像素子付きの携帯電話機の場合には、その撮像素子で撮影した自分の顔写真データをアドレス帳２０の最終レコードの顔写真データフィールド２０ｄに登録してもよい。
【００３６】
このようにして、ショートメッセージの作成、送信相手の指定、自分の顔写真データの登録済みの確認（または未登録の場合は必要に応じて顔写真データの登録作業）および自端末登録番号の読み出し作業を終了すると、以下に詳述するステップＳ１６〜ステップＳ２２で、冒頭で説明した発信シーケンスと切断シーケンスを実行し、同シーケンス中の“特定のメッセージ”（ＵＵＩを付加できるメッセージ）を利用して、ショートメッセージと自端末登録番号の送信、相手側端末からの画像データ要求フラグの確認、同フラグがＯＮの場合に自己紹介データエリアに登録された自分の顔写真データを送信（但し、顔写真データが未登録の場合はその旨を示すメッセージを送信）するという一連の処理を行った後、相手側端末とのリンクチャネルを解放して、待ち受け状態に移行する。
【００３７】
＜ステップＳ１６〜ステップＳ１８＞
ステップＳ１６（発明の要旨に記載の第１ステップに相当）では、上記ステップＳ１１で作成したショートメッセージのデータと、上記ステップＳ１５で読み出した自端末の登録番号とをＵＵＩの第１パケットにセットして送信する。ここに、ＵＵＩの第１パケットとは、既述のとおり、発信側端末の「呼設定」メッセージに付加されるＵＵＩのことである。
【００３８】
次に、ステップＳ１７で相手側端末からのＵＵＩの第２パケットの受信イベント（イベントとは例えば前述のレイヤ３によって提供される特定信号受信通知サービス；以下同様）を待ち、同パケットを受信すると、ステップＳ１８で同パケット中の画像データ要求フラグがＯＮ（画像データの要求）であるか否かを調べ、ＯＮであればステップＳ１９に進み、ＯＮでなければ相手側端末との間のリンクチャネルを解放した後、プログラムを終了する。ここに、ＵＵＩの第２パケットとは、既述のとおり、着信側端末からの「呼設定受付け」メッセージに付加されるＵＵＩのことである。
【００３９】
ステップＳ１９では、自己紹介データエリアに顔写真データが登録されているか否かを調べ、登録されていなければ、データ未登録を示す所定のメッセージまたは所定のデータ（以下、便宜的に“ＥＭＰＴＹ”）をＵＵＩの第３パケットにセットして送信した後、相手側端末との間のリンクチャネルを解放してプログラムを終了し、登録されていれば、ステップＳ２１に進む。ここに、ＵＵＩの第３パケットとは、既述のとおり、切断シーケンスの「切断」メッセージに付加されるＵＵＩのことである。
【００４０】
＜ステップＳ２１およびステップＳ２２＞
ステップＳ２１では、自端末の自己紹介データエリア、すなわち、アドレス帳２０の最終レコードから顔写真データを読み出し、ステップＳ２２（発明の要旨に記載の第４ステップに相当）でその顔写真データをＵＵＩの第３パケットにセットして送信した後、相手側端末との間のリンクチャネルを解放してプログラムを終了する。
【００４１】
このように、発信側端末では、発信シーケンスの「呼設定」メッセージのＵＵＩ（ＵＵＩの第１パケット）にショートメッセージのデータと自端末の登録番号をセットして送信するとともに、発信シーケンスの「呼設定受付け」メッセージのＵＵＩ（ＵＵＩの第２パケット）にセットされた、着信側端末からの画像データ要求フラグがＯＮの場合に、切断シーケンスの「切断」メッセージのＵＵＩ（ＵＵＩの第３パケット）に自分の顔写真データをセットして送信し、リンクチャネルを解放するという一連の処理を実行する。
【００４２】
図６は、着信側端末で実行されるショートメッセージ受信処理プログラムの概略的なフローチャートを示す図である。このプログラムを開始すると、まず、ステップＳ３１でＵＵＩの第１パケット、すなわち、「呼設定」メッセージに付加されたＵＵＩの受信イベントが発生するまで待機し、同ＵＵＩの受信イベントが発生すると、ステップＳ３２（発明の要旨に記載の第２ステップに相当）でＵＵＩの第１パケットにセットされている登録番号（発信側端末の登録番号）が自端末のアドレス帳２０（ＩＤコード＝“００１”〜ＩＤコード＝“９９８”のいずれかのレコード）に登録済みであるか否かを判定する。そして、登録済みでなければ、ステップＳ３３でアドレス帳２０の空きレコード（ＩＤコード＝“００１”〜ＩＤコード＝“９９８”のうちの未使用レコード）をカレントレコードにし、そのカレントレコードに、ＵＵＩの第１パケットにセットされている登録番号（発信側端末の登録番号）を登録してステップＳ３５に進む。
【００４３】
一方、ステップＳ３２で登録番号の登録済みを判定した場合は、その登録済みレコードをカレントレコードにし、ステップＳ３４でカレントレコードの顔写真データフィールド２０ｄに画像データが登録済みであるか否かを判定し、登録済みであれば、画像データの要求を行う必要がないので、以降のステップをパスしてリンクチャネルの解放後、プログラムを終了する。
【００４４】
他方、ステップＳ３４で画像データの未登録を判定した場合は、ステップＳ３５（発明の要旨に記載の第３ステップに相当）で「呼設定受付け」メッセージのＵＵＩ（ＵＵＩの第２パケット）に画像データ要求フラグ（ＯＮ）をセットして送信し、ステップＳ３６で「切断」メッセージのＵＵＩ（ＵＵＩの第３パケット）の受信イベントが発生するまで待機する。
【００４５】
そして、ＵＵＩの第３パケットの受信イベントが発生すると、ステップＳ３７で同パケットに画像データがセットされているか否か、すなわち、“ＥＭＰＴＹ”（上記ステップＳ２０の説明参照）以外のデータがセットされているか否かを調べ、画像データがセットされていない場合は、リンクチャネルの解放後、プログラムを終了し、一方、画像データがセットされている場合は、ステップＳ３８で同パケットから画像データを取り出し、ステップＳ３９（発明の要旨に記載の第５ステップに相当）でその画像データをアドレス帳２０のカレントレコードの顔写真データフィールド２０ｄに登録してリンクチャネルの解放後、プログラムを終了する。
【００４６】
このように、着信側端末では、着信シーケンスの「呼設定」メッセージのＵＵＩ（ＵＵＩの第１パケット）にセットされた登録番号（発信側端末の登録番号）をキーワードにしてアドレス帳２０を検索し、同一の登録番号がアドレス帳２０に登録されていなければ、空きレコードにその登録番号を新規登録する一方、登録されていれば、顔写真データの登録／未登録を判定し、顔写真データが未登録の場合または登録番号を新規登録した場合には、発信シーケンスの「呼設定受付け」メッセージのＵＵＩ（ＵＵＩの第２パケット）に画像データ要求フラグ（ＯＮ）をセットして送信し、この画像データ要求フラグ（ＯＮ）に応答して返送されるＵＵＩ、すなわち、切断シーケンスの「切断」メッセージのＵＵＩ（ＵＵＩの第３パケット）を調べて画像データがセットされている場合に、同ＵＵＩから顔写真データを取り出し、その顔写真データをアドレス帳２０のカレントレコードに登録した後、リンクチャネルを解放するという一連の処理を実行する。
【００４７】
以上のとおりであるから、本実施の形態によれば、一方の端末（発信側端末）から他方の端末（着信側端末）へ、発信側端末の登録番号をセットしたＵＵＩを送信するだけで、他方の端末のアドレス帳２０を検索して、一方の端末の使用者の情報が登録済みであるか否かを調べることができる。そして、登録番号が未登録であれば、他方の端末のアドレス帳２０の空きレコードに登録し、また、顔写真データが未登録であれば、ＵＵＩを利用してその情報（画像データ要求フラグ“ＯＮ”）を他方の端末から一方の端末へと送り返すことができ、一方の端末で画像データをＵＵＩにセットして他方の端末に送信し、この画像データを他方の端末のアドレス帳２０に登録することができる。
【００４８】
したがって、一方の端末からの発呼操作のみで、他方の端末のアドレス帳２０に一方の端末の登録番号とその使用者の顔写真データを送り込んで登録することができ、かかる一連の処理の間、他方の端末の着信操作（オフフック等）をまったく行う必要がないという格別の効果が得られる。
【００４９】
すなわち、図７にその概念図を示すように、まず、発信側端末でメッセージを作成し、宛先を指定して発信シーケンスを開始すると、ＵＵＩの第１パケットに、そのメッセージデータと発信側端末の登録番号（図では便宜的に“０７０−１２３４−５６７８”）をセットして送信する。着信側端末は、このＵＵＩの第１パケットを受信すると、そのＵＵＩにセットされた登録番号（“０７０−１２３４−５６７８”）と同一の登録番号を持つレコード（図２を例にするとＩＤコード＝“００３”のレコード）をアドレス帳２０から見つけ出す。
【００５０】
そして、そのレコードの顔写真データフィールド２０ｄに顔写真データが登録されていなければ、ＵＵＩの第２パケットに、画像データ要求フラグ（ＯＮ）をセットして送信し、発信側端末は、この画像データ要求フラグ（ＯＮ）に応答して、自己紹介データエリアから顔写真データを読み出し、その顔写真データをＵＵＩの第３パケットにセットして送信する。受信側端末はＵＵＩの第３パケットに顔写真データがセットされている場合、そのＵＵＩから顔写真データを取り出し、アドレス帳２０のカレントレコード（図２を例にするとＩＤコード＝“００３”のレコード）の顔写真データフィールド２０ｄに登録する。
【００５１】
以上の処理において、ユーザ操作を必要とするのは、発信側端末におけるメッセージの作成、宛先の指定および発信シーケンスの開始操作のみであり、それ以外の操作は発信側端末および受信側端末の何れも不要であるから、特に、受信側端末の操作を簡易化でき、登録番号や顔写真データを含む自己紹介データの自動送信機能を実現することができる。
【００５２】
なお、上記実施の形態では、顔写真のデータを送信する例を示したが、これに限定されない。顔写真以外の画像データを送信してもよいし、画像データ以外のバイナリデータまたはテキストデータを送信してもよい。また、上記実施の形態では、ショートメッセージの送信時に本発明を適用したが、通常の通話時でも同様に適用できる。さらに、発信側端末と受信側端末も携帯電話機に限らない。上述のＵＵＩをサポートする通信プロトコルに従って相互にデータ伝送を行うことのできる端末であればよく、例えば、ページャや携帯情報端末などの通信端末であってもよい。
【００５３】
＜第２の実施の形態＞
次に、本発明の第２の実施の形態を説明する。本実施の形態は、冒頭で説明した電話会社ごとのメール規格相違の諸問題解消を図るものである。すなわち、相手側端末がサポートするメール規格に関する情報を取得してその情報を自端末の電話帳等に登録できるようにし、以って、あるユーザとの間のメール伝達が突然できなくなったり、あるいは、あるユーザとの間でメール伝達が可能であるにもかかわらず、そのことを知らないばかりに、当該ユーザとの間でせっかくのメール機能を利用できないといった諸問題の解消を図るものである。
【００５４】
まず、本実施の形態は、ショートメッセージ送受信機能（以下、単に「メール機能」という。）を備えた通信端末、例えば、携帯電話機、ページャ、モデム付ＰＤＡ、モバイルパソコン等に適用することができる。また、本実施の形態の通信プロトコルは特に限定しないが、呼設定等の通信フェーズ実行中に後述の「メール規格情報」をセットして相手側端末に送信可能なデータブロック（または当該用途に利用可能なデータブロック）を有するプロトコルであることが望ましい。
【００５５】
この点において、ＣＤＭＡ方式は、端末と基地局間のアクセスチャネル（若しくは上りトラフィックチャネル）の特定情報レコードに端末の製造業者コードや機種コードを含めて送信することができるため、ＣＤＭＡ方式の通信端末同士であれば、その情報レコードを利用することによって本実施の形態の目的を達成することができる。以下、便宜的にＣＤＭＡ方式を例にして説明するが、この方式に限定されないことはもちろんである。要は、呼設定等の通信フェーズ実行中に所定のコンテナ（ＣＤＭＡ方式では特定の情報レコード）に後述の「メール規格情報」をセットして相手側端末に送信できればよい。
【００５６】
前述の実施の形態で説明した携帯電話機１はＰＨＳであり、厳密にはＣＤＭＡ方式と構成が異なるが、音声通話機能とメール機能を有する点、これらの機能に必要な各構成要素を備える点に着目すると、本実施の形態における携帯電話機と同一の構成を有しているとみなすことができる。したがって、以下では適宜に図１を参照しつつ、本実施の形態における携帯電話機の構成を説明することとする。
【００５７】
図８は、本実施の形態における携帯電話機のプログラムＲＯＭ１８ｂの要部メモリマップ図である。この図において、「ＭＡＩＬ＿ＰＲＧ＿Ａ」、「ＭＡＩＬ＿ＰＲＧ＿Ｂ」および「ＭＡＩＬ＿ＰＲＧ＿Ｃ」の名称が付された三つの領域は、携帯電話機のハードウェア資産と有機的に結合して各々異なる規格のメール機能を実現するプログラムブロックである。
【００５８】
これらのプログラムブロックはメール送受信の際に択一的に選択され、制御部１８のＣＰＵ１８ｇにロードされて実行されるようになっており、どのプログラムブロックが選択されるかは、相手側端末がサポートするメール規格によって決まる。例えば、ＭＡＩＬ＿ＰＲＧ＿Ａを“Ａメール”用のプログラム、ＭＡＩＬ＿ＰＲＧ＿Ｂを“Ｂメール”用のプログラム、ＭＡＩＬ＿ＰＲＧ＿Ｃを“Ｃメール”用のプログラムとすると、相手側端末が“Ａメール”をサポートしている場合は、ＭＡＩＬ＿ＰＲＧ＿Ａが選択され、相手側端末が“Ｂメール”をサポートしている場合は、ＭＡＩＬ＿ＰＲＧ＿Ｂが選択され、相手側端末が“Ｃメール”をサポートしている場合は、ＭＡＩＬ＿ＰＲＧ＿Ｃが選択されるようになっている。
【００５９】
なお、プログラムブロックは例示の三つに限らず、現存するすべてのメール規格を網羅するブロック数にしておくことが望ましい。また、新たなメール規格の策定に備えて、プログラムブロックの追加を可能にしておくことも望ましい。この場合、追加のプログラムブロックはコンポーネント部品として、携帯電話機サービス網に接続されたデータベースサーバなどから自由にダウンロードできるようにしておくと、携帯電話機を常に最新のメール規格に対応させて進化させ続けることができるので好ましい。
【００６０】
図９は、本実施の形態における携帯電話機の不揮発性メモリ１８ｄに形成されたアドレス帳２０′の概念図である。このアドレス帳２０′は、前記実施の形態のアドレス帳２０と同様に、“ＩＤ”、“登録番号”、“氏名”および“顔写真データ”といった適宜の名称が与えられた複数のフィールド２０ａ〜２０ｄを有するほか、さらに、本実施の形態特有の要素として、“メール規格”と命名されたフィールド２０ｅ（破線部分参照）を有している。
【００６１】
フィールド２０ｅ（以下「メール規格フィールド」という。）は、メール規格を表す情報（図では便宜的に“Ａ”、“Ｂ”および“Ｃ”）を格納するもので、自己紹介データエリア（ＩＤコード＝“９９９”のレコード）のメール規格フィールド２０ｅには自端末がサポートするすべてのメール規格情報が書き込まれており、アドレス帳（ＩＤコード＝“９９９”からＩＤコード＝“９９８”までの各レコード）のメール規格フィールド２０ｅには登録済みの他端末がサポートするすべてのメール規格情報が書き込まれている。
【００６２】
図１０は、本実施の形態における携帯電話機の発呼処理プログラムの概略的なフローチャートを示す図である。このプログラムを開始すると、まず、ステップＳ４１で当該携帯電話機の通信プロトコルで定められた発呼処理プロセスを実行して相手側端末を呼び出す。次に、ステップＳ４２で自端末の自己紹介データエリアに自端末のメール規格情報が格納されているか否かを判定し、格納されていなければ、ステップＳ４４（発明の要旨に記載の第１ステップに相当）で自端末の登録番号を相手側端末に送信した後、ステップＳ４５で相手側端末との間の音声通信またはデータ通信を実行する一方、自端末の自己紹介データエリアに自端末のメール規格情報が格納されている場合は、ステップＳ４４で自端末の登録番号と自端末のメール規格情報とを相手側端末に送信した後、ステップＳ４５で相手側端末との間の音声通信またはデータ通信を実行する。
【００６３】
したがって、この処理プログラムによれば、相手側端末を呼び出す際に、自端末の登録番号と一緒に、自端末がサポートしているメール規格の情報とを送信することができる。
【００６４】
図１１は、本実施の形態における携帯電話機の着呼処理プログラムの概略的なフローチャートを示す図である。このプログラムを開始すると、まず、ステップＳ５１で当該携帯電話機の通信プロトコルで定められた着呼処理プロセスを実行し、発呼側端末（上記図９の発呼処理を実行した端末）から送信されたデータを取り込む。次に、ステップＳ５２で受信データ中に発呼側端末のメール規格情報が含まれているか否かを判定し、格納されていなければステップＳ５３に進み、格納されていればステップＳ５４に進む。
【００６５】
ステップＳ５３では、発呼側端末の登録番号をアドレス帳に登録するか否かを示す選択画面を携帯電話機の表示部１８ｅに表示してユーザ操作を待ち、登録しない場合は、そのままステップＳ５７に進んで発呼側端末との間の音声通信またはデータ通信を実行する一方、登録する場合はステップＳ５５でアドレス帳２０′の空きレコードに発呼側端末の登録番号を登録した後、ステップＳ５７に進んで発呼側端末との間の音声通信またはデータ通信を実行する。
【００６６】
ステップＳ５４では、発呼側端末の登録番号およびメール規格をアドレス帳に登録するか否かを示す選択画面を携帯電話機の表示部１８ｅに表示してユーザ操作を待ち、登録しない場合は、そのままステップＳ５７に進んで発呼側端末との間の音声通信またはデータ通信を実行する一方、登録する場合はステップＳ５６（発明の要旨に記載の第２ステップに相当）でアドレス帳２０′の空きレコードに発呼側端末の登録番号とメール規格とを登録した後、ステップＳ５７に進んで発呼側端末との間の音声通信またはデータ通信を実行する。
【００６７】
したがって、この処理プログラムによれば、発呼側端末からの受信情報にメール規格の情報が含まれていた場合、当該端末の登録番号と一緒にアドレス帳２０′に登録することができる。
【００６８】
図１２は、本実施の形態における携帯電話機の表示部１８ｅの画面２１を示す図であり、画面２１には、アドレス帳２０′に登録された特定の通話先の情報が表示されている。図において、２１ａは同通話先の名前（またはニックネーム）、２１ｂは同通話先端末の登録番号、２１ｃは同通話先端末のメール規格である。名前２１ａはアドレス帳２０′の氏名フィールド２０ｃの情報に対応し、登録番号２１ｂはアドレス帳２０′の登録番号フィールド２０ｂの情報に対応し、メール規格２１ｃはアドレス帳２０′のメール規格フィールド２０ｅの情報に対応する。このように画面２１には、アドレス帳２０′に登録された相手（図では名前“○○○○”）にメールを送信しようとする際、この相手先端末のメール規格（図では“Ａメール”）が表示されるようになっている。
【００６９】
後述するように、メール規格フィールド２０ｅの相手先端末の情報は、自端末からのメール送信時に、メール規格フィールド２０ｅの自端末の情報との照合がとられるようになっており、自端末のＣＰＵ１８ｇに適切なメールプログラム（相手先端末のメール規格に対応したメールプログラム）がロードされるようになっている。このため、上記相手先（図では名前“○○○○”）にメールを送信する際は、当該相手先端末で支障なく読み取ることのできるメールを作成して送信できるから、規格の異なるメール送信を防止して、メールの不達を確実に回避することができる。
【００７０】
図１３は、本実施の形態における携帯電話機のメール送信処理プログラムの概略的なフローチャートを示す図である。このプログラムを開始すると、まず、ステップＳ６１でユーザ操作によってアドレス帳２０′から任意の送信先を選択する。次に、ステップＳ６２でその送信先情報にメール規格情報が組まれているか否かを判定し、含まれていなければ処理を終了し、含まれている場合はステップＳ６３でそのメール規格は自端末でサポートしている規格であるか否かを判定する。そして、サポート規格でない場合は処理を終了し、サポート規格である場合は、ステップＳ６４で送信先のメール規格に対応したメールプログラム（図８のＭＡＩＬ＿ＰＲＧ＿Ａ、ＭＡＩＬ＿ＰＲＧ＿ＢまたはＭＡＩＬ＿ＰＲＧ＿Ｃのいずれかひとつ）をロードし、ステップＳ６５（発明の要旨に記載の第３ステップに相当）でユーザ操作によるメールの作成を行い、ステップＳ６６で作成メールを送信した後、処理を終了する。
【００７１】
したがって、この処理プログラムによれば、メールを送信する際に、送信先端末がサポートするメール規格の情報をアドレス帳２０′から取り出し、その情報に基づいて適切なメールプログラムを選択して使用することができる。
【００７２】
以上のとおり、本実施の形態によれば、一の端末から二の端末を発呼する際に、一の端末の登録番号と同端末がサポートするメール規格の情報を送信し、二の端末でその情報（登録番号とメール規格の情報）をアドレス帳２０′に登録するとともに、二の端末で一の端末宛てのメールを作成する際は、アドレス帳２０′の登録情報から一の端末がサポートするメール規格の情報を取り出し、この情報に基づいてプログラムＲＯＭ１８ｂから適切なメールプログラム（図８のＭＡＩＬ＿ＰＲＧ＿Ａ、ＭＡＩＬ＿ＰＲＧ＿ＢまたはＭＡＩＬ＿ＰＲＧ＿Ｃのいずれかひとつ）をＣＰＵ１８ｇにロードして実行するので、一の端末に適合した正しい形式のメールを送信することができ、規格の相違に伴うメール不達を確実に防止できるという格別のメリットが得られる。
【００７３】
さらに、一の端末の機種が交換された場合でも一の端末から二の端末を発呼するだけで、二の端末に新たなメール規格情報を伝えることができ、二の端末でアドレス帳２０′の情報更新を行うことにより、常に適正なメール規格情報の管理を行うことができ、機種変更にも即応的に対処できるというメリットも得られる。
【図面の簡単な説明】
【００７４】
【図１】携帯電話機のブロック図である。
【図２】アドレス帳の構造図である。
【図３】発着信シーケンスのタイムランである。
【図４】切断シーケンスのタイムランである。
【図５】発信側端末で実行されるショートメッセージ送信処理プログラムの概略的なフローチャートである。
【図６】着信側端末で実行されるショートメッセージ受信処理プログラムの概略的なフローチャートである。
【図７】発信側端末と着信側端末の間でやり取りされるＵＵＩの送受信概念図である。
【図８】携帯電話機のプログラムＲＯＭ１８ｂの要部メモリマップ図である。
【図９】携帯電話機の不揮発性メモリ１８ｄに形成されたアドレス帳２０′の概念図である。
【図１０】携帯電話機の発呼処理プログラムの概略的なフローチャートを示す図である。
【図１１】携帯電話機の着呼処理プログラムの概略的なフローチャートを示す図である。
【図１２】携帯電話機の表示部１８ｅの画面２１を示す図である。
【図１３】携帯電話機のメール送信処理プログラムの概略的なフローチャートを示す図である。
【符号の説明】
【００７５】
１  携帯電話機（第一の端末、第二の端末、発信側端末、受信側端末）
１８  制御部（第１送信手段、第２送信手段、第３送信手段、データ登録手段、登録番号登録手段、検索手段、送信手段、登録手段、動作態様変更手段）
２０  アドレス帳（データレコード）
２０ｄ  顔写真データフィールド（所定フィールド）
【図１】
2008136252.tif 000003
【図２】
2008136252.tif 000004
【図３】
2008136252.tif 000005
【図４】
2008136252.tif 000006
【図５】
2008136252.tif 000007
【図６】
2008136252.tif 000008
【図７】
2008136252.tif 000009
【図８】
2008136252.tif 000010
【図９】
2008136252.tif 000011
【図１０】
2008136252.tif 000012
【図１１】
2008136252.tif 000013
【図１２】
2008136252.tif 000014
【図１３】
2008136252.tif 000015
【手続補正書】
【提出日】平成20年3月27日(2008.3.27)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
第一の端末から第二の端末へ該第一の端末の機種データを送信する第１ステップと、
該機種データを受信した前記第二の端末で当該機種データをデータレコードに登録する第２ステップと、
前記第二の端末から前記第一の端末へ所定のデータ通信を行う際に前記データレコードを検索して前記第一の端末の機種データを取り出すとともに該機種データに対応したデータ通信動作態様となるように前記第二の端末の動作態様を変化させる第３ステップと、
を含むことを特徴とするデータ登録方法。
【請求項２】
前記所定のデータ通信はメール通信であることを特徴とする請求項１記載のデータ登録方法。
【請求項３】
前記動作態様はプログラム制御方式によるものであって、プログラムの選択によって動作態様の変更を行うものであることを特徴とする請求項１記載のデータ登録方法。
【請求項４】
第一の端末から第二の端末へ該第一の端末の機種データを送信する送信手段と、
該機種データを受信して前記第二の端末のデータレコードに登録する登録手段と、
前記第二の端末から前記第一の端末へ所定のデータ通信を行う際に前記データレコードを検索して前記第一の端末の機種データを取り出すとともに該機種データに対応したデータ通信動作態様となるように前記第二の端末の動作態様を変化させる動作態様変更手段と、
を備えたことを特徴とするデータ登録装置。
【請求項５】
他の端末の機種データを受信する受信手段と、
受信した他の端末の該機種データをデータレコードに登録する登録手段と、
前記他の端末へ所定のデータ通信を行う際に前記データレコードを検索して前記他の端末の機種データを取り出すとともに該機種データに対応したデータ通信動作態様となるように動作態様を変化させる動作態様変更手段と、
この動作態様変更手段により設定された動作態様に基づいて、前記他の端末に対するデータ通信を行うデータ通信手段と、
を備えたことを特徴とする通信端末。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】０００１
【補正方法】変更
【補正の内容】
【０００１】
本発明は、例えば、画像や文字情報の表示が可能な表示装置を備えた携帯型通信端末など（以下、単に「端末」という。）に適用して好ましいデータ登録方法およびデータ登録装置ならびに通信端末に関する。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】０００９
【補正方法】変更
【補正の内容】
【０００９】
そこで、本発明が解決しようとする課題は、相手側端末がサポートするメール規格に関する情報等の相手側端末の機種データを取得してその情報を自端末の電話帳等に登録できるようにしたデータ登録方法およびデータ登録装置を提供し、以って、このデータ登録方法およびデータ登録装置を適用した携帯電話機などの携帯型通信端末の使い勝手向上を図ることにある。
【手続補正４】
【補正対象書類名】明細書
【補正対象項目名】００１０
【補正方法】変更
【補正の内容】
【００１０】
請求項１に係る発明はデータ登録方法であって、第一の端末から第二の端末へ該第一の端末の機種データを送信する第１ステップと、該機種データを受信した前記第二の端末で当該機種データをデータレコードに登録する第２ステップと、前記第二の端末から前記第一の端末へ所定のデータ通信を行う際に前記データレコードを検索して前記第一の端末の機種データを取り出すとともに該機種データに対応したデータ通信動作態様となるように前記第二の端末の動作態様を変化させる第３ステップと、を含むことを特徴とする。
これによれば、第二の端末に第一の端末の機種データを登録し、第二の端末から第一の端末宛てに所定のデータ通信を行う際に、第二の端末の動作態様が第一の端末の機種データに対応した特定のデータ通信動作態様に変更される。
請求項２に係る発明は、請求項１に記載のデータ登録方法において、前記所定のデータ通信はメール通信であることを特徴とする。
これによれば、第二の端末から第一の端末宛てにメール送信する際に、第一の端末の機種データに対応して特定規格のメールが送信される。
請求項３に係る発明は、請求項１に記載のデータ登録方法において、前記動作態様はプログラム制御方式によるものであって、プログラムの選択によって動作態様の変更を行うものであることを特徴とする。
これによれば、プログラムを入れ替えるだけで様々な動作態様に対応できる。
請求項４に係る発明はデータ登録装置であって、第一の端末から第二の端末へ該第一の端末の機種データを送信する送信手段と、該機種データを受信して前記第二の端末のデータレコードに登録する登録手段と、前記第二の端末から前記第一の端末へ所定のデータ通信を行う際に前記データレコードを検索して前記第一の端末の機種データを取り出すとともに該機種データに対応したデータ通信動作態様となるように前記第二の端末の動作態様を変化させる動作態様変更手段と、を備えたことを特徴とする。
これによれば、第二の端末に第一の端末の機種データを登録し、第二の端末から第一の端末宛てに所定のデータ通信を行う際に、第二の端末の動作態様が第一の端末の機種データに対応した特定のデータ通信動作態様に変更される。
請求項５に係る発明は通信端末であって、他の端末の機種データを受信する受信手段と、受信した他の端末の該機種データをデータレコードに登録する登録手段と、前記他の端末へ所定のデータ通信を行う際に前記データレコードを検索して前記他の端末の機種データを取り出すとともに該機種データに対応したデータ通信動作態様となるように動作態様を変化させる動作態様変更手段と、この動作態様変更手段により設定された動作態様に基づいて、前記他の端末に対するデータ通信を行うデータ通信手段と、を備えたことを特徴とする。
これによれば、他の端末の機種データがデータレコードに登録され、前記他の端末宛てに所定のデータ通信を行う際に、動作態様が当該他の端末の機種データに対応した特定のデータ通信動作態様に変更される。
【手続補正５】
【補正対象書類名】明細書
【補正対象項目名】００１１
【補正方法】変更
【補正の内容】
【００１１】
請求項１記載のデータ登録方法および請求項４記載のデータ登録装置によれば、第二の端末に第一の端末の機種データを登録し、第二の端末から第一の端末宛てに所定のデータ通信を行う際に、第二の端末の動作態様が第一の端末の機種データに対応した特定のデータ通信動作態様に変更される。したがって、両端末間の機種の違いに伴うデータ通信の不整合を回避することができる。
また、請求項５記載の通信端末によれば、他の端末の機種データがデータレコードに登録され、前記他の端末宛てに所定のデータ通信を行う際に、動作態様が当該他の端末の機種データに対応した特定のデータ通信動作態様に変更される。したがって、請求項５に係る発明においても、請求項１および４に係る発明と同様の効果を奏する。
【手続補正６】
【補正対象書類名】明細書
【補正対象項目名】００６２
【補正方法】変更
【補正の内容】
【００６２】
図１０は、本実施の形態における携帯電話機の発呼処理プログラムの概略的なフローチャートを示す図である。このプログラムを開始すると、まず、ステップＳ４１で当該携帯電話機の通信プロトコルで定められた発呼処理プロセスを実行して相手側端末を呼び出す。次に、ステップＳ４２で自端末の自己紹介データエリアに自端末のメール規格情報が格納されているか否かを判定し、格納されていなければ、ステップＳ４３で自端末の登録番号を相手側端末に送信した後、ステップＳ４５で相手側端末との間の音声通信またはデータ通信を実行する一方、自端末の自己紹介データエリアに自端末のメール規格情報が格納されている場合は、ステップＳ４４（請求項１に記載の第１ステップに相当）で自端末の登録番号と自端末のメール規格情報とを相手側端末に送信した後、ステップＳ４５で相手側端末との間の音声通信またはデータ通信を実行する。
【手続補正７】
【補正対象書類名】明細書
【補正対象項目名】００６４
【補正方法】変更
【補正の内容】
【００６４】
図１１は、本実施の形態における携帯電話機の着呼処理プログラムの概略的なフローチャートを示す図である。このプログラムを開始すると、まず、ステップＳ５１で当該携帯電話機の通信プロトコルで定められた着呼処理プロセスを実行し、発呼側端末（上記図１０の発呼処理を実行した端末）から送信されたデータを取り込む。次に、ステップＳ５２で受信データ中に発呼側端末のメール規格情報が含まれているか否かを判定し、格納されていなければステップＳ５３に進み、格納されていればステップＳ５４に進む。
【手続補正８】
【補正対象書類名】明細書
【補正対象項目名】００６６
【補正方法】変更
【補正の内容】
【００６６】
ステップＳ５４では、発呼側端末の登録番号およびメール規格をアドレス帳に登録するか否かを示す選択画面を携帯電話機の表示部１８ｅに表示してユーザ操作を待ち、登録しない場合は、そのままステップＳ５７に進んで発呼側端末との間の音声通信またはデータ通信を実行する一方、登録する場合はステップＳ５６（請求項１に記載の第２ステップに相当）でアドレス帳２０′の空きレコードに発呼側端末の登録番号とメール規格とを登録した後、ステップＳ５７に進んで発呼側端末との間の音声通信またはデータ通信を実行する。
【手続補正９】
【補正対象書類名】明細書
【補正対象項目名】００７０
【補正方法】変更
【補正の内容】
【００７０】
図１３は、本実施の形態における携帯電話機のメール送信処理プログラムの概略的なフローチャートを示す図である。このプログラムを開始すると、まず、ステップＳ６１でユーザ操作によってアドレス帳２０′から任意の送信先を選択する。次に、ステップＳ６２でその送信先情報にメール規格情報が組まれているか否かを判定し、含まれていなければ処理を終了し、含まれている場合はステップＳ６３でそのメール規格は自端末でサポートしている規格であるか否かを判定する。そして、サポート規格でない場合は処理を終了し、サポート規格である場合は、ステップＳ６４で送信先のメール規格に対応したメールプログラム（図８のＭＡＩＬ＿ＰＲＧ＿Ａ、ＭＡＩＬ＿ＰＲＧ＿ＢまたはＭＡＩＬ＿ＰＲＧ＿Ｃのいずれかひとつ）をロードし、ステップＳ６５（請求項１に記載の第３ステップに相当）でユーザ操作によるメールの作成を行い、ステップＳ６６で作成メールを送信した後、処理を終了する。