携帯電話網における電子メールの受信拒否方法及び携帯端末
【課題】携帯電話網における電子メールの受信拒否方法及び携帯端末に関し、受信者が拒否する画像付きｈｔｍｌメールに対して、ユーザ情報転送プレーン（Ｕプレーン）でのデータ転送を行うことなく、送信を停止することを可能にする。
【解決手段】携帯端末１から画像付きｈｔｍｌメールを送信する際に、該メールの宛先アドレスと、画像付きｈｔｍｌメールであることを示すフラグとを、呼制御信号プレーンのプロトコルメッセージ上に設定して送信する。ネットワークのゲートウェイ８内のメールサーバでは、呼制御信号プレーン上の宛先アドレスとフラグを抽出し、該宛先アドレスが受信拒否の宛先アドレスとして登録されたアドレスと一致するか否かを判定する。前記宛先アドレスが、登録されたアドレスと一致する場合に、該メールの着側携帯端末への送信を停止し、発側携帯端末１へ受信拒否による接続不可の応答メッセージを返却する。
【解決手段】携帯端末１から画像付きｈｔｍｌメールを送信する際に、該メールの宛先アドレスと、画像付きｈｔｍｌメールであることを示すフラグとを、呼制御信号プレーンのプロトコルメッセージ上に設定して送信する。ネットワークのゲートウェイ８内のメールサーバでは、呼制御信号プレーン上の宛先アドレスとフラグを抽出し、該宛先アドレスが受信拒否の宛先アドレスとして登録されたアドレスと一致するか否かを判定する。前記宛先アドレスが、登録されたアドレスと一致する場合に、該メールの着側携帯端末への送信を停止し、発側携帯端末１へ受信拒否による接続不可の応答メッセージを返却する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、携帯電話網における電子メールの受信拒否方法及び携帯端末に関する。
【背景技術】
【０００２】
発側加入者Ａの携帯端末１で作成されて送信される電子メールは、送信宛先のアドレス等を含むヘッダ情報、メール本文及び画像等の添付ファイル等のデータにより構成される。３ＧＰＰ（Third Generation Partnership Project）の携帯電話網における電子メールの転送シーケンスを図５に示す。発側加入者Ａの携帯端末１で電子メールが作成され発信されると、呼制御信号プレーン（Ｃプレーン）により、発側携帯端末１とメールサーバ６との間の接続設定が実施される。
【０００３】
発側携帯端末１とメールサーバ６との間には、無線基地局（ＢＴＳ）２、無線ネットワーク制御装置（ＲＮＣ）３、パケット交換機のサービス制御ゲートウェイ（ＳＧＳＮ）４及びサーバ側ゲートウェイ（ＧＧＳＮ）５が存在する。発側携帯端末１の発信により、サービス制御ゲートウェイ（ＳＧＳＮ）４によりユーザ認証が行われる。
【０００４】
そして、アクセスポイントネーム（ＡＰＮ）を含む発信接続要求が発側携帯端末１から発せられると、サービス制御ゲートウェイ（ＳＧＳＮ）４は、接続先のサーバ側ゲートウェイ（ＧＧＳＮ）５のアドレス解決を行い、サーバ側ゲートウェイ（ＧＧＳＮ）５へのトンネル設定を行う。
【０００５】
以上の呼制御信号プレーン（Ｃプレーン）での送受信シーケンスにより、発側携帯端末１とメールサーバ６との間で通信パスが設定されると、ユーザ情報転送プレーン（Ｕプレーン）により、発側携帯端末１からインタネット網のゲートウェイ内のメールサーバ６へ電子メールのデータ（例．ｍｅｎｂｅｒ＿Ｂ＠ｘｘｘｘ．ｎｅ．ｊｐ こんにちは「★」）が転送される。
【０００６】
メールサーバ６には、携帯電話番号とメールアドレスとがデータベースに格納されて管理され、メールサーバ６に届いたメールデータの宛先アドレスが携帯電話事業社内の携帯電話端末ものであるかを照合する。該当する宛先アドレスであれば、該宛先アドレスを携帯電話端末の電話番号に変換し、その電話番号に該当する中継パケット交換機を選択し、着信処理を実施する。
【０００７】
着信者の電話番号を含む着信信号は、メールサーバ６からサーバ側ゲートウェイ（ＧＧＳＮ）５に送信され、サーバ側ゲートウェイ（ＧＧＳＮ）５は、呼制御信号プレーン（Ｃプレーン）により着信接続の設定を行う。まず、サーバ側ゲートウェイ（ＧＧＳＮ）５は、携帯電話番号や端末識別番号等のユーザ情報を管理するデータベースＨＬＲ（home location register）に問い合わせ、位置登録エリアの情報を取得し、該位置登録エリアのサービス制御ゲートウェイ（ＳＧＳＮ）４に着信信号を送信する。
【０００８】
サービス制御ゲートウェイ（ＳＧＳＮ）４は、位置登録エリア内の無線基地局（ＢＴＳ）２から着側加入者Ｂの携帯端末７に対して一斉呼び出しを行い、応答を受信するとユーザ認証を行い、その後、着信接続要求を受けるとサーバ側ゲートウェイ（ＧＧＳＮ）５との間にトンネルを設定する。
【０００９】
以上の呼制御信号プレーン（Ｃプレーン）での送受信シーケンスにより、着側携帯端末７とメールサーバ６との間で通信パスが設定された後、ユーザ情報転送プレーン（Ｕプレーン）によりメールサーバ６から着側携帯端末７へ電子メールのデータ（例．ｍｅｎｂｅｒ＿Ｂ＠ｘｘｘｘ．ｎｅ．ｊｐ こんにちは「★」）が送信される。
【００１０】
電子メールとして、デコメール（登録商標）等のような、文字に着色したり、文字以外の静止画像やアニメーション画像で飾ったりした画像付きｈｔｍｌ形式メールを送信した場合でも、データサイズの大きい画像データを含めて、メールの全データがユーザ情報転送プレーン（Ｕプレーン）でゲートウェイ内のメールサーバ６に転送された後、メールサーバ６において宛先アドレスが抽出される。
【００１１】
電子メールの受信拒否の方法には以下の方法（ａ）及び（ｂ）が知られている。
（ａ）受信側加入者がゲートウェイ内のメールサーバ（メールセンター）に、受信拒否対象のメールの発信者アドレスやドメイン名を登録しておき、メールサーバ（メールセンター）で、メール毎に拒否対象であるか否かを、登録された発信者アドレスやドメイン名を基に判定して拒否する方法。
（ｂ）大量のデータのメールを受信しないようにするために、メールサーバ（メールセンター）において、画像データが添付されたメールの送信を拒否する、或いは一定サイズ以上の画像データが添付されたメールの送信を拒否する方法。
【００１２】
また、通信料金が発生することなく迷惑メール等の受信拒否を可能にし、電子メールの受信可否を受信側の端末装置で選択することができるようにしたメール受信拒否機能について、例えば下記の特許文献１等に開示されている。
【先行技術文献】
【特許文献】
【００１３】
【特許文献１】特開２００６−０８５２２７号公報
【発明の概要】
【発明が解決しようとする課題】
【００１４】
（課題１）デコメール（登録商標）等のような画像付きｈｔｍｌ形式メールは、画像データをメールに添付した送信データであるためデータサイズが大きい。そのため、受信者がパケット定額制に加入していない場合は、画像付きｈｔｍｌ形式メールを受信する度に、テキストデータのみの電子メールに比べて高額のパケット料金が受信者側に掛かってしまうことになる。本発明の課題の１つは、画像付きｈｔｍｌ形式メールの受信を望まない加入者に対して、テキストデータのみの電子メールは受信するが、画像付きｈｔｍｌ形式メールの受信拒否を可能することである。
【００１５】
なお、前述の（ａ）の方法は、悪意の送信者からの迷惑メールを拒否するための方法である。これに対して、画像付きｈｔｍｌ形式メールの受信による過剰な課金を回避するために、画像付きｈｔｍｌ形式メールの受信だけを拒否する場合、画像付きｈｔｍｌ形式メールの送信者に悪意はなく、該送信者からのメール全ての受信を拒否する（ａ）の方法では、上記の課題１は解決されない。
【００１６】
また、添付画像データを一切受信しない、或いは一定サイズ以上の添付画像データを受信しないよう設定を行う上述の（ｂ）の方法は、大量サイズデータの受信による過剰な課金を防ぐことを目的に各携帯電話事業者が提供している。しかし、画像付きｈｔｍｌ形式メールは、ｈｔｍｌ形式のテキストと画像データとで成り立っており、例えば「私は〔ＯＫ（画像データ）〕です。」等のようなテキストと画像データとの組み合わせの場合、画像データのみを削除すると、「私は〔 〕です。」と表示されることとなり、電子メールとして文意が成り立たないものとなってしまう。
【００１７】
また、画像付きｈｔｍｌ形式メールの送信者は、画像データが削除されて受信者に送信されたことが通知されず、該送信者は、画像付きｈｔｍｌ形式のメールが正常に受信されたものと判断してしまう。しかし、受信者は不完全なメールを受信することになり、無効なメールがネットワーク上に配信されることになる。
【００１８】
（課題２）画像付きｈｔｍｌ形式のメールに限らず、受信者側が特定条件のメールの受信拒否の設定をメールサーバ６に対して行った場合、従来、以下のようにメールの受信拒否が行われる。まず、発側加入者Ａの携帯端末１は、呼制御信号プレーン（Ｃプレーン）による接続経路の確認後、ユーザ情報転送プレーン（Ｕプレーン）でメールの全データをメールサーバ６へ転送する。
【００１９】
メールサーバ６は、ユーザ情報転送プレーン（Ｕプレーン）でメールの全データを受信した後でなければ、受信側のメールアドレスを抽出することができない。そのため、受信拒否対象のメールであるにも拘わらず、発側加入者Ａの携帯端末１からメールサーバ６までのユーザ情報転送プレーン（Ｕプレーン）によるデータ送信が発生する。その結果、発側加入者Ａへの無駄な課金や、ネットワークへの無効な負荷が発生することになる。受信者が拒否するメールに対しては、ユーザ情報転送プレーン（Ｕプレーン）でのデータ転送を行うことなく、送信停止することが本発明の課題２である。
【００２０】
従来のメール受信拒否機能は、上述の（ａ）や（ｂ）の方法によるものであるが、それぞれユーザ情報転送プレーン（Ｕプレーン）でメールの全データをメールサーバ６へ送信し、メールサーバ６内で受信側のメールアドレスを抽出した後に、受信拒否のメールであるか否かを判断するため、上述の課題２は解決されない。
【課題を解決するための手段】
【００２１】
上記課題を解決する第１の形態である電子メールの受信拒否方法は、携帯端末から電子メールを送信する際に、該電子メールの宛先アドレスを呼制御信号プレーンのプロトコルメッセージ上に設定して送信する第１のステップと、ネットワーク内のメールサーバにおいて、前記呼制御信号プレーンのプロトコルメッセージ上に設定された前記宛先アドレスを抽出し、該宛先アドレスが、受信拒否の宛先アドレスとして登録されたアドレスと一致するか否かを判定する第２のステップと、前記宛先アドレスが、受信拒否の宛先アドレスとして登録されたアドレスと一致する場合に、該電子メールの着側携帯端末への送信を停止し、発側携帯端末へ受信拒否による接続不可の応答メッセージを返却する第３のステップと、を含むものである。
【００２２】
また、上記課題を解決する第２の形態である携帯端末は、電子メールのメール作成部とメール送信部とを有する携帯端末において、前記メール作成部におけるヘッダ編集機能と、前記メール送信部における送信電文作成機能とを連携させ、前記ヘッダ編集機能で設定された電子メールの宛先アドレスを、呼制御信号プレーン接続の送信電文に追加する呼制御信号プレーン送信電文追加手段と、前記電子メールの宛先アドレスが追加された呼制御信号プレーン接続の送信電文を送信する送受信制御手段と、を備えたものである。
【発明の効果】
【００２３】
電子メールの受信を拒否する加入者のアドレス宛の電子メールを、ユーザ情報転送プレーン（Ｕプレーン）でのメールデータの転送を行うことなく、呼制御信号プレーン（Ｃプレーン）の接続制御データにより判断し、該受信拒否の加入者宛の電子メールの送信を停止し、発側携帯端末へ受信拒否を通知することができる。これにより、相手先に受信されることのない電子メールをネットワークに送信する無駄が省かれ、ネットワーク輻輳を防ぐことができ、また、無用な課金発生を防ぐことができる。
【図面の簡単な説明】
【００２４】
【図１】画像付きｈｔｍｌ形式のメール受信拒否の設定のシーケンスを示す図である。
【図２】携帯端末で呼制御信号プレーンへメールアドレスを設定する具体例を示す図である。
【図３】画像付きｈｔｍｌ形式メール送信時のメール受信拒否問い合わせのシーケンスを示す図である。
【図４】複数同時送信の画像付きｈｔｍｌ形式メールの受信拒否問い合わせのシーケンスを示す図である。
【図５】携帯電話網における電子メールの転送シーケンスを示す図である。
【発明を実施するための形態】
【００２５】
（受信拒否の設定について）
図１に画像付きｈｔｍｌ形式のメール受信拒否の設定のシーケンスを示す。画像付きｈｔｍｌ形式メールの受信を拒否する加入者Ｂは、自身の携帯端末７から予めインタネット網ゲートウェイ（ＧＷ）内のメールサーバ(メールセンター)に対し、画像付きｈｔｍｌ形式メールの受信拒否の登録を行う。
【００２６】
この画像付きｈｔｍｌ形式メールの受信拒否の登録のシーケンスは、加入者Ｂの携帯端末７からの発信により、サービス制御ゲートウェイ（ＳＧＳＮ）４によりユーザ認証が行われる。そして、アクセスポイントネーム（ＡＰＮ）を含むＳＭプロトコルのＡｃｔｉｖａｔｅ ＰＤＰ ｃｏｎｔｅｘｔ Ｒｅｑｕｅｓｔメッセージにより、サービス制御ゲートウェイ（ＳＧＳＮ）４に送出する。
【００２７】
サービス制御ゲートウェイ（ＳＧＳＮ）４は、ＧＴＰプロトコルのＣｒｅａｔｅ ＰＤＰ Ｃｏｎｔｅｘｔ Ｒｅｑｕｅｓｔメッセージにより画像付きｈｔｍｌ形式メールの受信拒否の旨の情報を、接続先のサーバ側ゲートウェイ（ＧＧＳＮ）５に送出する。サーバ側ゲートウェイ（ＧＧＳＮ）５は、インタネット網ゲートウェイ（ＧＷ）８内のメールサーバ（メールセンター）に、接続情報を通知する。
【００２８】
以上の呼制御信号プレーン（Ｃプレーン）での送受信シーケンスにより、携帯端末７とメールサーバ６との間で通信パスが設定されると、ユーザ情報転送プレーン（Ｕプレーン）により、携帯端末７とインタネット網のゲートウェイ内のメールサーバ６との間で受信拒否の設定を含む加入者Ｂのメール設定に関する情報の送受信が可能となる。
【００２９】
この登録機能は、各携帯電話事業者が提供する各種メールのメニュー項目の設定機能を利用することができ、単にメニュー項目の追加だけで実現することができる。メールサーバ（メールセンター）は、画像付きｈｔｍｌ形式メールの受信拒否者一覧のデータベースを新設し、画像付きｈｔｍｌ形式メールの受信を拒否する加入者のメールアドレスを、画像付きｈｔｍｌ形式メールの受信拒否者一覧のデータベースに登録する。
【００３０】
（携帯端末で呼制御信号プレーンへのメールアドレスの設定について）
図２に携帯端末で呼制御信号プレーン（Ｃプレーン）へメールアドレスを設定する具体例を示す。携帯端末には、メール作成部２−１、メール送信部２−２、メモリ２−３を備える。メール作成部２−１には、メール編集機能として、ヘッダ編集、本文編集、画像付きｈｔｍｌ形式メールの画像添付機能等が備えられている。
【００３１】
また、メール送信部２−２には、プロトコル制御機能、送信電文生成機能、送受信制御機能が備えられている。そこで、画像付きｈｔｍｌ形式メールを送信する場合、メール作成部２−１におけるヘッダ編集機能と、メール送信部２−２における送信電文生成機能とを連携させ、ヘッダ編集機能で設定された宛先メールアドレスを、呼制御信号プレーン（Ｃプレーン）接続の送信電文に追加する。
【００３２】
具体的には、発側加入者Ａの携帯端末１からサービス制御ゲートウェイ（ＳＧＳＮ）４に向けてのＳＭプロトコルのＡｃｔｉｖａｔｅ ＰＤＰ ｃｏｎｔｅｘｔ Ｒｅｑｕｅｓｔメッセージ上の携帯電話事業者個別オプションとして、宛先メールアドレス及び画像付きｈｔｍｌ形式メールであることを示すフラグをＯＮに設定して送信する。
【００３３】
メモリ２−３上には、宛先メールアドレス（例．ｍｅｎｂｅｒ＿Ｂ＠ｘｘｘｘ．ｎｅ。ｊｐ）を含むヘッダ、画像付きｈｔｍｌ形式メールのテキスト本文（例．こんにちは「 」）、及び画像付きｈｔｍｌ形式メールの画像（例．「★」）が生成され、それらは、ユーザ情報転送プレーン（Ｕプレーン）により送信される。
【００３４】
一方、ＳＭプロトコルのＡｃｔｉｖａｔｅ ＰＤＰ ｃｏｎｔｅｘｔ Ｒｅｑｕｅｓｔメッセージの電文は、呼制御信号プレーン（Ｃプレーン）で送信される。従って、Ａｃｔｉｖａｔｅ ＰＤＰ ｃｏｎｔｅｘｔ Ｒｅｑｕｅｓｔメッセージの携帯電話事業者個別オプションとして設定された宛先メールアドレス（例．ｍｅｎｂｅｒ＿Ｂ＠ｘｘｘｘ．ｎｅ。ｊｐ）及び画像付きｈｔｍｌ形式メールであることを示すフラグは、呼制御信号プレーン（Ｃプレーン）で送信される。
【００３５】
（画像付きｈｔｍｌ形式のメール受信拒否の問い合わせについて）
図３に画像付きｈｔｍｌ形式メール送信時のメール受信拒否問い合わせのシーケンスを示す。発側携帯端末１から画像付きｈｔｍｌ形式メールが送信された場合、発信処理、ユーザ認証処理の後、ＳＭプロトコルのＡｃｔｉｖａｔｅ ＰＤＰ Ｃｏｎｔｅｘｔ Ｒｅｑｕｅｓｔメッセージ上の携帯電話事業者個別パラメータに、宛先メールアドレス及び画像付きｈｔｍｌ形式メールであることを示すフラグを設定して、サービス制御ゲートウェイ（ＳＧＳＮ）４へ送信する。
【００３６】
サービス制御ゲートウェイ（ＳＧＳＮ）４では、インタネット網ゲートウェイ（ＧＷ）８内のメールサーバ宛であることを確認後、ＧＴＰプロトコルのＣｒｅａｔｅ ＰＤＰ Ｃｏｎｔｅｘｔ Ｒｅｑｕｅｓｔメッセージに携帯電話事業者個別パラメータを引き継ぎ、サーバ側ゲートウェイ（ＧＧＳＮ）５へ送信する。
【００３７】
サーバ側ゲートウェイ（ＧＧＳＮ）５は、ゲートウェイ（ＧＷ）８内のメールサーバへ接続通知を実施する。その際に、携帯電話事業者個別パラメータを引き継ぐ。ゲートウェイ（ＧＷ）８内のメールサーバは、該パラメータを使用し、画像付きｈｔｍｌ形式メールの受信拒否者アドレス一覧のデータベースに、当該宛先メールアドレスが存在するかを検索し、判定する。
【００３８】
画像付きｈｔｍｌ形式メールの受信拒否アドレス一覧に、当該宛先メールアドレスが存在した場合は、サーバ側ゲートウェイ（ＧＧＳＮ）５へ画像付きｈｔｍｌ形式メールの受信拒否による接続不可の応答を返却する。サーバ側ゲートウェイ（ＧＧＳＮ）５は、サービス制御ゲートウェイ（ＳＧＳＮ）４へ、画像付きｈｔｍｌ形式メールの受信拒否による接続不可の応答を返却し、サービス制御ゲートウェイ（ＳＧＳＮ）４は、発側端末１へ対し、接続拒否（リジェクト）の応答を返却する。その際のエラーコード（ｃａｕｓｅ）は、画像付きｈｔｍｌ形式メールの受信拒否である。発側端末１は、接続拒否（リジェクト）を受信すると、画面に画像付きｈｔｍｌ形式メールの受信拒否の応答メッセージを表示する。
【００３９】
（複数同時送信の画像付きｈｔｍｌ形式メールの受信拒否問い合わせについて）
図４に複数同時送信の画像付きｈｔｍｌ形式メールの受信拒否問い合わせのシーケンスを示す。発側携帯端末１から画像付きｈｔｍｌ形式メールが複数のメールアドレス宛先へ同時に送信された場合、画像付きｈｔｍｌ形式メールであることを示すフラグと、宛先の全てのメールアドレスとを、ＳＭプロトコルのＡｃｔｉｖａｔｅ ＰＤＰ Ｃｏｎｔｅｘｔ Ｒｅｑｕｅｓｔメッセージ上の携帯電話事業者個別パラメータに設定する。
【００４０】
サービス制御ゲートウェイ（ＳＧＳＮ）４で、インタネット網ゲートウェイ（ＧＷ）８内のメールサーバ宛のデータであることを確認した後、ＧＴＰプロトコルのＣｒｅａｔｅ ＰＤＰ Ｃｏｎｔｅｘｔ Ｒｅｑｕｅｓｔメッセージに携帯電話事業者個別パラメータを引き継ぎ、サーバ側ゲートウェイ（ＧＧＳＮ）５へ送信する。
【００４１】
サーバ側ゲートウェイ（ＧＧＳＮ）５は、ゲートウェイ（ＧＷ）８内のメールサーバへ接続通知を実施する。その際に、携帯電話事業者個別パラメータを引き継ぐ。ゲートウェイ（ＧＷ）８内のメールサーバは、該パラメータを使用し、画像付きｈｔｍｌ形式メールの受信拒否アドレス一覧のデータベースに、全ての宛先メールアドレスのうち１つでも一致するものが存在するか否かを検索し、判定する。
【００４２】
画像付きｈｔｍｌ形式メールの受信拒否アドレス一覧に、宛先メールアドレスが１つでも存在する場合は、サーバ側ゲートウェイ（ＧＧＳＮ）５へ、画像付きｈｔｍｌ形式メール受信拒否による接続不可の応答を返却する。サーバ側ゲートウェイ（ＧＧＳＮ）５は、サービス制御ゲートウェイ（ＳＧＳＮ）４へ、画像付きｈｔｍｌ形式メールの受信拒否による接続不可の応答を返却し、サービス制御ゲートウェイ（ＳＧＳＮ）４は、発側端末１に対し、接続不可（リジェクト）の応答を返却する。
【００４３】
その際のエラーコード（ｃａｕｓｅ）は、画像付きｈｔｍｌ形式メールの受信拒否である。発側の携帯端末１は接続不可（リジェクト）の応答を受信すると、画面に画像付きｈｔｍｌ形式メールの受信拒否の応答メッセージを表示する。
【００４４】
以上、この携帯電話網における電子メールの受信拒否方法によれば、画像付きｈｔｍｌ形式メールの受信拒否を希望する加入者に対して画像付きｈｔｍｌ形式メールを送信した場合、ユーザ情報転送プレーン（Ｕプレーン）で画像データを含むメールデータを転送することなく、呼制御信号プレーン（Ｃプレーン）の接続制御データのみで、拒否対象の電子メールか否かを判断し、発側携帯端末への受信拒否の旨を通知し、該電子メールの送信を停止することができる。これにより、相手先に受信されることのないメールをネットワークへ送信する無駄を省き、ネットワーク輻輳を防ぐことができる。
【００４５】
画像付きｈｔｍｌ形式メールの受信を拒否したい加入者は、送信者が誰であれ、画像付きｈｔｍｌ形式メールを選択的に受信拒否することができ、テキストのみの電子メール等を受信許可することができるようになる。従来の画像付きｈｔｍｌ形式メールのテキスト部のみの受信や、送信者のアドレスによる受信拒否では得られなかった拒否サービスを享受することができる。
【符号の説明】
【００４６】
１ 発側携帯端末
２ 無線基地局（ＢＴＳ）
３ 無線ネットワーク制御装置（ＲＮＣ）
４ サービス制御ゲートウェイ（ＳＧＳＮ）
５ サーバ側ゲートウェイ（ＧＧＳＮ）
６ メールサーバ６
７ 着側携帯端末
８ インタネット網ゲートウェイ（ＧＷ）
【技術分野】
【０００１】
本発明は、携帯電話網における電子メールの受信拒否方法及び携帯端末に関する。
【背景技術】
【０００２】
発側加入者Ａの携帯端末１で作成されて送信される電子メールは、送信宛先のアドレス等を含むヘッダ情報、メール本文及び画像等の添付ファイル等のデータにより構成される。３ＧＰＰ（Third Generation Partnership Project）の携帯電話網における電子メールの転送シーケンスを図５に示す。発側加入者Ａの携帯端末１で電子メールが作成され発信されると、呼制御信号プレーン（Ｃプレーン）により、発側携帯端末１とメールサーバ６との間の接続設定が実施される。
【０００３】
発側携帯端末１とメールサーバ６との間には、無線基地局（ＢＴＳ）２、無線ネットワーク制御装置（ＲＮＣ）３、パケット交換機のサービス制御ゲートウェイ（ＳＧＳＮ）４及びサーバ側ゲートウェイ（ＧＧＳＮ）５が存在する。発側携帯端末１の発信により、サービス制御ゲートウェイ（ＳＧＳＮ）４によりユーザ認証が行われる。
【０００４】
そして、アクセスポイントネーム（ＡＰＮ）を含む発信接続要求が発側携帯端末１から発せられると、サービス制御ゲートウェイ（ＳＧＳＮ）４は、接続先のサーバ側ゲートウェイ（ＧＧＳＮ）５のアドレス解決を行い、サーバ側ゲートウェイ（ＧＧＳＮ）５へのトンネル設定を行う。
【０００５】
以上の呼制御信号プレーン（Ｃプレーン）での送受信シーケンスにより、発側携帯端末１とメールサーバ６との間で通信パスが設定されると、ユーザ情報転送プレーン（Ｕプレーン）により、発側携帯端末１からインタネット網のゲートウェイ内のメールサーバ６へ電子メールのデータ（例．ｍｅｎｂｅｒ＿Ｂ＠ｘｘｘｘ．ｎｅ．ｊｐ こんにちは「★」）が転送される。
【０００６】
メールサーバ６には、携帯電話番号とメールアドレスとがデータベースに格納されて管理され、メールサーバ６に届いたメールデータの宛先アドレスが携帯電話事業社内の携帯電話端末ものであるかを照合する。該当する宛先アドレスであれば、該宛先アドレスを携帯電話端末の電話番号に変換し、その電話番号に該当する中継パケット交換機を選択し、着信処理を実施する。
【０００７】
着信者の電話番号を含む着信信号は、メールサーバ６からサーバ側ゲートウェイ（ＧＧＳＮ）５に送信され、サーバ側ゲートウェイ（ＧＧＳＮ）５は、呼制御信号プレーン（Ｃプレーン）により着信接続の設定を行う。まず、サーバ側ゲートウェイ（ＧＧＳＮ）５は、携帯電話番号や端末識別番号等のユーザ情報を管理するデータベースＨＬＲ（home location register）に問い合わせ、位置登録エリアの情報を取得し、該位置登録エリアのサービス制御ゲートウェイ（ＳＧＳＮ）４に着信信号を送信する。
【０００８】
サービス制御ゲートウェイ（ＳＧＳＮ）４は、位置登録エリア内の無線基地局（ＢＴＳ）２から着側加入者Ｂの携帯端末７に対して一斉呼び出しを行い、応答を受信するとユーザ認証を行い、その後、着信接続要求を受けるとサーバ側ゲートウェイ（ＧＧＳＮ）５との間にトンネルを設定する。
【０００９】
以上の呼制御信号プレーン（Ｃプレーン）での送受信シーケンスにより、着側携帯端末７とメールサーバ６との間で通信パスが設定された後、ユーザ情報転送プレーン（Ｕプレーン）によりメールサーバ６から着側携帯端末７へ電子メールのデータ（例．ｍｅｎｂｅｒ＿Ｂ＠ｘｘｘｘ．ｎｅ．ｊｐ こんにちは「★」）が送信される。
【００１０】
電子メールとして、デコメール（登録商標）等のような、文字に着色したり、文字以外の静止画像やアニメーション画像で飾ったりした画像付きｈｔｍｌ形式メールを送信した場合でも、データサイズの大きい画像データを含めて、メールの全データがユーザ情報転送プレーン（Ｕプレーン）でゲートウェイ内のメールサーバ６に転送された後、メールサーバ６において宛先アドレスが抽出される。
【００１１】
電子メールの受信拒否の方法には以下の方法（ａ）及び（ｂ）が知られている。
（ａ）受信側加入者がゲートウェイ内のメールサーバ（メールセンター）に、受信拒否対象のメールの発信者アドレスやドメイン名を登録しておき、メールサーバ（メールセンター）で、メール毎に拒否対象であるか否かを、登録された発信者アドレスやドメイン名を基に判定して拒否する方法。
（ｂ）大量のデータのメールを受信しないようにするために、メールサーバ（メールセンター）において、画像データが添付されたメールの送信を拒否する、或いは一定サイズ以上の画像データが添付されたメールの送信を拒否する方法。
【００１２】
また、通信料金が発生することなく迷惑メール等の受信拒否を可能にし、電子メールの受信可否を受信側の端末装置で選択することができるようにしたメール受信拒否機能について、例えば下記の特許文献１等に開示されている。
【先行技術文献】
【特許文献】
【００１３】
【特許文献１】特開２００６−０８５２２７号公報
【発明の概要】
【発明が解決しようとする課題】
【００１４】
（課題１）デコメール（登録商標）等のような画像付きｈｔｍｌ形式メールは、画像データをメールに添付した送信データであるためデータサイズが大きい。そのため、受信者がパケット定額制に加入していない場合は、画像付きｈｔｍｌ形式メールを受信する度に、テキストデータのみの電子メールに比べて高額のパケット料金が受信者側に掛かってしまうことになる。本発明の課題の１つは、画像付きｈｔｍｌ形式メールの受信を望まない加入者に対して、テキストデータのみの電子メールは受信するが、画像付きｈｔｍｌ形式メールの受信拒否を可能することである。
【００１５】
なお、前述の（ａ）の方法は、悪意の送信者からの迷惑メールを拒否するための方法である。これに対して、画像付きｈｔｍｌ形式メールの受信による過剰な課金を回避するために、画像付きｈｔｍｌ形式メールの受信だけを拒否する場合、画像付きｈｔｍｌ形式メールの送信者に悪意はなく、該送信者からのメール全ての受信を拒否する（ａ）の方法では、上記の課題１は解決されない。
【００１６】
また、添付画像データを一切受信しない、或いは一定サイズ以上の添付画像データを受信しないよう設定を行う上述の（ｂ）の方法は、大量サイズデータの受信による過剰な課金を防ぐことを目的に各携帯電話事業者が提供している。しかし、画像付きｈｔｍｌ形式メールは、ｈｔｍｌ形式のテキストと画像データとで成り立っており、例えば「私は〔ＯＫ（画像データ）〕です。」等のようなテキストと画像データとの組み合わせの場合、画像データのみを削除すると、「私は〔 〕です。」と表示されることとなり、電子メールとして文意が成り立たないものとなってしまう。
【００１７】
また、画像付きｈｔｍｌ形式メールの送信者は、画像データが削除されて受信者に送信されたことが通知されず、該送信者は、画像付きｈｔｍｌ形式のメールが正常に受信されたものと判断してしまう。しかし、受信者は不完全なメールを受信することになり、無効なメールがネットワーク上に配信されることになる。
【００１８】
（課題２）画像付きｈｔｍｌ形式のメールに限らず、受信者側が特定条件のメールの受信拒否の設定をメールサーバ６に対して行った場合、従来、以下のようにメールの受信拒否が行われる。まず、発側加入者Ａの携帯端末１は、呼制御信号プレーン（Ｃプレーン）による接続経路の確認後、ユーザ情報転送プレーン（Ｕプレーン）でメールの全データをメールサーバ６へ転送する。
【００１９】
メールサーバ６は、ユーザ情報転送プレーン（Ｕプレーン）でメールの全データを受信した後でなければ、受信側のメールアドレスを抽出することができない。そのため、受信拒否対象のメールであるにも拘わらず、発側加入者Ａの携帯端末１からメールサーバ６までのユーザ情報転送プレーン（Ｕプレーン）によるデータ送信が発生する。その結果、発側加入者Ａへの無駄な課金や、ネットワークへの無効な負荷が発生することになる。受信者が拒否するメールに対しては、ユーザ情報転送プレーン（Ｕプレーン）でのデータ転送を行うことなく、送信停止することが本発明の課題２である。
【００２０】
従来のメール受信拒否機能は、上述の（ａ）や（ｂ）の方法によるものであるが、それぞれユーザ情報転送プレーン（Ｕプレーン）でメールの全データをメールサーバ６へ送信し、メールサーバ６内で受信側のメールアドレスを抽出した後に、受信拒否のメールであるか否かを判断するため、上述の課題２は解決されない。
【課題を解決するための手段】
【００２１】
上記課題を解決する第１の形態である電子メールの受信拒否方法は、携帯端末から電子メールを送信する際に、該電子メールの宛先アドレスを呼制御信号プレーンのプロトコルメッセージ上に設定して送信する第１のステップと、ネットワーク内のメールサーバにおいて、前記呼制御信号プレーンのプロトコルメッセージ上に設定された前記宛先アドレスを抽出し、該宛先アドレスが、受信拒否の宛先アドレスとして登録されたアドレスと一致するか否かを判定する第２のステップと、前記宛先アドレスが、受信拒否の宛先アドレスとして登録されたアドレスと一致する場合に、該電子メールの着側携帯端末への送信を停止し、発側携帯端末へ受信拒否による接続不可の応答メッセージを返却する第３のステップと、を含むものである。
【００２２】
また、上記課題を解決する第２の形態である携帯端末は、電子メールのメール作成部とメール送信部とを有する携帯端末において、前記メール作成部におけるヘッダ編集機能と、前記メール送信部における送信電文作成機能とを連携させ、前記ヘッダ編集機能で設定された電子メールの宛先アドレスを、呼制御信号プレーン接続の送信電文に追加する呼制御信号プレーン送信電文追加手段と、前記電子メールの宛先アドレスが追加された呼制御信号プレーン接続の送信電文を送信する送受信制御手段と、を備えたものである。
【発明の効果】
【００２３】
電子メールの受信を拒否する加入者のアドレス宛の電子メールを、ユーザ情報転送プレーン（Ｕプレーン）でのメールデータの転送を行うことなく、呼制御信号プレーン（Ｃプレーン）の接続制御データにより判断し、該受信拒否の加入者宛の電子メールの送信を停止し、発側携帯端末へ受信拒否を通知することができる。これにより、相手先に受信されることのない電子メールをネットワークに送信する無駄が省かれ、ネットワーク輻輳を防ぐことができ、また、無用な課金発生を防ぐことができる。
【図面の簡単な説明】
【００２４】
【図１】画像付きｈｔｍｌ形式のメール受信拒否の設定のシーケンスを示す図である。
【図２】携帯端末で呼制御信号プレーンへメールアドレスを設定する具体例を示す図である。
【図３】画像付きｈｔｍｌ形式メール送信時のメール受信拒否問い合わせのシーケンスを示す図である。
【図４】複数同時送信の画像付きｈｔｍｌ形式メールの受信拒否問い合わせのシーケンスを示す図である。
【図５】携帯電話網における電子メールの転送シーケンスを示す図である。
【発明を実施するための形態】
【００２５】
（受信拒否の設定について）
図１に画像付きｈｔｍｌ形式のメール受信拒否の設定のシーケンスを示す。画像付きｈｔｍｌ形式メールの受信を拒否する加入者Ｂは、自身の携帯端末７から予めインタネット網ゲートウェイ（ＧＷ）内のメールサーバ(メールセンター)に対し、画像付きｈｔｍｌ形式メールの受信拒否の登録を行う。
【００２６】
この画像付きｈｔｍｌ形式メールの受信拒否の登録のシーケンスは、加入者Ｂの携帯端末７からの発信により、サービス制御ゲートウェイ（ＳＧＳＮ）４によりユーザ認証が行われる。そして、アクセスポイントネーム（ＡＰＮ）を含むＳＭプロトコルのＡｃｔｉｖａｔｅ ＰＤＰ ｃｏｎｔｅｘｔ Ｒｅｑｕｅｓｔメッセージにより、サービス制御ゲートウェイ（ＳＧＳＮ）４に送出する。
【００２７】
サービス制御ゲートウェイ（ＳＧＳＮ）４は、ＧＴＰプロトコルのＣｒｅａｔｅ ＰＤＰ Ｃｏｎｔｅｘｔ Ｒｅｑｕｅｓｔメッセージにより画像付きｈｔｍｌ形式メールの受信拒否の旨の情報を、接続先のサーバ側ゲートウェイ（ＧＧＳＮ）５に送出する。サーバ側ゲートウェイ（ＧＧＳＮ）５は、インタネット網ゲートウェイ（ＧＷ）８内のメールサーバ（メールセンター）に、接続情報を通知する。
【００２８】
以上の呼制御信号プレーン（Ｃプレーン）での送受信シーケンスにより、携帯端末７とメールサーバ６との間で通信パスが設定されると、ユーザ情報転送プレーン（Ｕプレーン）により、携帯端末７とインタネット網のゲートウェイ内のメールサーバ６との間で受信拒否の設定を含む加入者Ｂのメール設定に関する情報の送受信が可能となる。
【００２９】
この登録機能は、各携帯電話事業者が提供する各種メールのメニュー項目の設定機能を利用することができ、単にメニュー項目の追加だけで実現することができる。メールサーバ（メールセンター）は、画像付きｈｔｍｌ形式メールの受信拒否者一覧のデータベースを新設し、画像付きｈｔｍｌ形式メールの受信を拒否する加入者のメールアドレスを、画像付きｈｔｍｌ形式メールの受信拒否者一覧のデータベースに登録する。
【００３０】
（携帯端末で呼制御信号プレーンへのメールアドレスの設定について）
図２に携帯端末で呼制御信号プレーン（Ｃプレーン）へメールアドレスを設定する具体例を示す。携帯端末には、メール作成部２−１、メール送信部２−２、メモリ２−３を備える。メール作成部２−１には、メール編集機能として、ヘッダ編集、本文編集、画像付きｈｔｍｌ形式メールの画像添付機能等が備えられている。
【００３１】
また、メール送信部２−２には、プロトコル制御機能、送信電文生成機能、送受信制御機能が備えられている。そこで、画像付きｈｔｍｌ形式メールを送信する場合、メール作成部２−１におけるヘッダ編集機能と、メール送信部２−２における送信電文生成機能とを連携させ、ヘッダ編集機能で設定された宛先メールアドレスを、呼制御信号プレーン（Ｃプレーン）接続の送信電文に追加する。
【００３２】
具体的には、発側加入者Ａの携帯端末１からサービス制御ゲートウェイ（ＳＧＳＮ）４に向けてのＳＭプロトコルのＡｃｔｉｖａｔｅ ＰＤＰ ｃｏｎｔｅｘｔ Ｒｅｑｕｅｓｔメッセージ上の携帯電話事業者個別オプションとして、宛先メールアドレス及び画像付きｈｔｍｌ形式メールであることを示すフラグをＯＮに設定して送信する。
【００３３】
メモリ２−３上には、宛先メールアドレス（例．ｍｅｎｂｅｒ＿Ｂ＠ｘｘｘｘ．ｎｅ。ｊｐ）を含むヘッダ、画像付きｈｔｍｌ形式メールのテキスト本文（例．こんにちは「 」）、及び画像付きｈｔｍｌ形式メールの画像（例．「★」）が生成され、それらは、ユーザ情報転送プレーン（Ｕプレーン）により送信される。
【００３４】
一方、ＳＭプロトコルのＡｃｔｉｖａｔｅ ＰＤＰ ｃｏｎｔｅｘｔ Ｒｅｑｕｅｓｔメッセージの電文は、呼制御信号プレーン（Ｃプレーン）で送信される。従って、Ａｃｔｉｖａｔｅ ＰＤＰ ｃｏｎｔｅｘｔ Ｒｅｑｕｅｓｔメッセージの携帯電話事業者個別オプションとして設定された宛先メールアドレス（例．ｍｅｎｂｅｒ＿Ｂ＠ｘｘｘｘ．ｎｅ。ｊｐ）及び画像付きｈｔｍｌ形式メールであることを示すフラグは、呼制御信号プレーン（Ｃプレーン）で送信される。
【００３５】
（画像付きｈｔｍｌ形式のメール受信拒否の問い合わせについて）
図３に画像付きｈｔｍｌ形式メール送信時のメール受信拒否問い合わせのシーケンスを示す。発側携帯端末１から画像付きｈｔｍｌ形式メールが送信された場合、発信処理、ユーザ認証処理の後、ＳＭプロトコルのＡｃｔｉｖａｔｅ ＰＤＰ Ｃｏｎｔｅｘｔ Ｒｅｑｕｅｓｔメッセージ上の携帯電話事業者個別パラメータに、宛先メールアドレス及び画像付きｈｔｍｌ形式メールであることを示すフラグを設定して、サービス制御ゲートウェイ（ＳＧＳＮ）４へ送信する。
【００３６】
サービス制御ゲートウェイ（ＳＧＳＮ）４では、インタネット網ゲートウェイ（ＧＷ）８内のメールサーバ宛であることを確認後、ＧＴＰプロトコルのＣｒｅａｔｅ ＰＤＰ Ｃｏｎｔｅｘｔ Ｒｅｑｕｅｓｔメッセージに携帯電話事業者個別パラメータを引き継ぎ、サーバ側ゲートウェイ（ＧＧＳＮ）５へ送信する。
【００３７】
サーバ側ゲートウェイ（ＧＧＳＮ）５は、ゲートウェイ（ＧＷ）８内のメールサーバへ接続通知を実施する。その際に、携帯電話事業者個別パラメータを引き継ぐ。ゲートウェイ（ＧＷ）８内のメールサーバは、該パラメータを使用し、画像付きｈｔｍｌ形式メールの受信拒否者アドレス一覧のデータベースに、当該宛先メールアドレスが存在するかを検索し、判定する。
【００３８】
画像付きｈｔｍｌ形式メールの受信拒否アドレス一覧に、当該宛先メールアドレスが存在した場合は、サーバ側ゲートウェイ（ＧＧＳＮ）５へ画像付きｈｔｍｌ形式メールの受信拒否による接続不可の応答を返却する。サーバ側ゲートウェイ（ＧＧＳＮ）５は、サービス制御ゲートウェイ（ＳＧＳＮ）４へ、画像付きｈｔｍｌ形式メールの受信拒否による接続不可の応答を返却し、サービス制御ゲートウェイ（ＳＧＳＮ）４は、発側端末１へ対し、接続拒否（リジェクト）の応答を返却する。その際のエラーコード（ｃａｕｓｅ）は、画像付きｈｔｍｌ形式メールの受信拒否である。発側端末１は、接続拒否（リジェクト）を受信すると、画面に画像付きｈｔｍｌ形式メールの受信拒否の応答メッセージを表示する。
【００３９】
（複数同時送信の画像付きｈｔｍｌ形式メールの受信拒否問い合わせについて）
図４に複数同時送信の画像付きｈｔｍｌ形式メールの受信拒否問い合わせのシーケンスを示す。発側携帯端末１から画像付きｈｔｍｌ形式メールが複数のメールアドレス宛先へ同時に送信された場合、画像付きｈｔｍｌ形式メールであることを示すフラグと、宛先の全てのメールアドレスとを、ＳＭプロトコルのＡｃｔｉｖａｔｅ ＰＤＰ Ｃｏｎｔｅｘｔ Ｒｅｑｕｅｓｔメッセージ上の携帯電話事業者個別パラメータに設定する。
【００４０】
サービス制御ゲートウェイ（ＳＧＳＮ）４で、インタネット網ゲートウェイ（ＧＷ）８内のメールサーバ宛のデータであることを確認した後、ＧＴＰプロトコルのＣｒｅａｔｅ ＰＤＰ Ｃｏｎｔｅｘｔ Ｒｅｑｕｅｓｔメッセージに携帯電話事業者個別パラメータを引き継ぎ、サーバ側ゲートウェイ（ＧＧＳＮ）５へ送信する。
【００４１】
サーバ側ゲートウェイ（ＧＧＳＮ）５は、ゲートウェイ（ＧＷ）８内のメールサーバへ接続通知を実施する。その際に、携帯電話事業者個別パラメータを引き継ぐ。ゲートウェイ（ＧＷ）８内のメールサーバは、該パラメータを使用し、画像付きｈｔｍｌ形式メールの受信拒否アドレス一覧のデータベースに、全ての宛先メールアドレスのうち１つでも一致するものが存在するか否かを検索し、判定する。
【００４２】
画像付きｈｔｍｌ形式メールの受信拒否アドレス一覧に、宛先メールアドレスが１つでも存在する場合は、サーバ側ゲートウェイ（ＧＧＳＮ）５へ、画像付きｈｔｍｌ形式メール受信拒否による接続不可の応答を返却する。サーバ側ゲートウェイ（ＧＧＳＮ）５は、サービス制御ゲートウェイ（ＳＧＳＮ）４へ、画像付きｈｔｍｌ形式メールの受信拒否による接続不可の応答を返却し、サービス制御ゲートウェイ（ＳＧＳＮ）４は、発側端末１に対し、接続不可（リジェクト）の応答を返却する。
【００４３】
その際のエラーコード（ｃａｕｓｅ）は、画像付きｈｔｍｌ形式メールの受信拒否である。発側の携帯端末１は接続不可（リジェクト）の応答を受信すると、画面に画像付きｈｔｍｌ形式メールの受信拒否の応答メッセージを表示する。
【００４４】
以上、この携帯電話網における電子メールの受信拒否方法によれば、画像付きｈｔｍｌ形式メールの受信拒否を希望する加入者に対して画像付きｈｔｍｌ形式メールを送信した場合、ユーザ情報転送プレーン（Ｕプレーン）で画像データを含むメールデータを転送することなく、呼制御信号プレーン（Ｃプレーン）の接続制御データのみで、拒否対象の電子メールか否かを判断し、発側携帯端末への受信拒否の旨を通知し、該電子メールの送信を停止することができる。これにより、相手先に受信されることのないメールをネットワークへ送信する無駄を省き、ネットワーク輻輳を防ぐことができる。
【００４５】
画像付きｈｔｍｌ形式メールの受信を拒否したい加入者は、送信者が誰であれ、画像付きｈｔｍｌ形式メールを選択的に受信拒否することができ、テキストのみの電子メール等を受信許可することができるようになる。従来の画像付きｈｔｍｌ形式メールのテキスト部のみの受信や、送信者のアドレスによる受信拒否では得られなかった拒否サービスを享受することができる。
【符号の説明】
【００４６】
１ 発側携帯端末
２ 無線基地局（ＢＴＳ）
３ 無線ネットワーク制御装置（ＲＮＣ）
４ サービス制御ゲートウェイ（ＳＧＳＮ）
５ サーバ側ゲートウェイ（ＧＧＳＮ）
６ メールサーバ６
７ 着側携帯端末
８ インタネット網ゲートウェイ（ＧＷ）
【特許請求の範囲】
【請求項１】
携帯電話網における電子メールの受信拒否方法において、
携帯端末から電子メールを送信する際に、該電子メールの宛先アドレスを呼制御信号プレーンのプロトコルメッセージ上に設定して送信する第１のステップと、
ネットワーク内のメールサーバにおいて、前記呼制御信号プレーンのプロトコルメッセージ上に設定された前記宛先アドレスを抽出し、該宛先アドレスが、受信拒否の宛先アドレスとして登録されたアドレスと一致するか否かを判定する第２のステップと、
前記宛先アドレスが、受信拒否の宛先アドレスとして登録されたアドレスと一致する場合に、該電子メールの着側携帯端末への送信を停止し、発側携帯端末へ受信拒否による接続不可の応答メッセージを返却する第３のステップと、
を含む携帯電話網における電子メールの受信拒否方法。
【請求項２】
前記第１のステップにおいて、電子メールの宛先アドレスとともに、該電子メールが画像付きｈｔｍｌ形式メールであることを示すフラグを、前記呼制御信号プレーンのプロトコルメッセージ上に設定して送信し、
前記第２のステップにおいて、前記宛先アドレスが、画像付きｈｔｍｌ形式メールの受信拒否の宛先アドレスとして登録されたアドレスと一致するか否かを判定することを特徴とする請求項１に記載の電子メールの受信拒否方法。
【請求項３】
電子メールのメール作成部とメール送信部とを有する携帯端末において、
前記メール作成部におけるヘッダ編集機能と、前記メール送信部における送信電文作成機能とを連携させ、前記ヘッダ編集機能で設定された電子メールの宛先アドレスを、呼制御信号プレーン接続の送信電文に追加する呼制御信号プレーン送信電文追加手段と、
前記電子メールの宛先アドレスが追加された呼制御信号プレーン接続の送信電文を送信する送受信制御手段と、
を備えたことを特徴とする携帯端末。
【請求項４】
前記呼制御信号プレーン送信電文追加手段は、前記電子メールの宛先アドレスとともに、前記電子メールが画像付きｈｔｍｌ形式メールであることを示すフラグを、前記呼制御信号プレーン接続の送信電文に追加することを特徴とする請求項３に記載の携帯端末。
【請求項１】
携帯電話網における電子メールの受信拒否方法において、
携帯端末から電子メールを送信する際に、該電子メールの宛先アドレスを呼制御信号プレーンのプロトコルメッセージ上に設定して送信する第１のステップと、
ネットワーク内のメールサーバにおいて、前記呼制御信号プレーンのプロトコルメッセージ上に設定された前記宛先アドレスを抽出し、該宛先アドレスが、受信拒否の宛先アドレスとして登録されたアドレスと一致するか否かを判定する第２のステップと、
前記宛先アドレスが、受信拒否の宛先アドレスとして登録されたアドレスと一致する場合に、該電子メールの着側携帯端末への送信を停止し、発側携帯端末へ受信拒否による接続不可の応答メッセージを返却する第３のステップと、
を含む携帯電話網における電子メールの受信拒否方法。
【請求項２】
前記第１のステップにおいて、電子メールの宛先アドレスとともに、該電子メールが画像付きｈｔｍｌ形式メールであることを示すフラグを、前記呼制御信号プレーンのプロトコルメッセージ上に設定して送信し、
前記第２のステップにおいて、前記宛先アドレスが、画像付きｈｔｍｌ形式メールの受信拒否の宛先アドレスとして登録されたアドレスと一致するか否かを判定することを特徴とする請求項１に記載の電子メールの受信拒否方法。
【請求項３】
電子メールのメール作成部とメール送信部とを有する携帯端末において、
前記メール作成部におけるヘッダ編集機能と、前記メール送信部における送信電文作成機能とを連携させ、前記ヘッダ編集機能で設定された電子メールの宛先アドレスを、呼制御信号プレーン接続の送信電文に追加する呼制御信号プレーン送信電文追加手段と、
前記電子メールの宛先アドレスが追加された呼制御信号プレーン接続の送信電文を送信する送受信制御手段と、
を備えたことを特徴とする携帯端末。
【請求項４】
前記呼制御信号プレーン送信電文追加手段は、前記電子メールの宛先アドレスとともに、前記電子メールが画像付きｈｔｍｌ形式メールであることを示すフラグを、前記呼制御信号プレーン接続の送信電文に追加することを特徴とする請求項３に記載の携帯端末。
【図１】
【図２】
【図３】
【図４】
【図５】
【図２】
【図３】
【図４】
【図５】
【公開番号】特開２０１０−２３９２４１（Ｐ２０１０−２３９２４１Ａ）
【公開日】平成２２年１０月２１日（２０１０．１０．２１）
【国際特許分類】
【出願番号】特願２００９−８２６９２（Ｐ２００９−８２６９２）
【出願日】平成２１年３月３０日（２００９．３．３０）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
【公開日】平成２２年１０月２１日（２０１０．１０．２１）
【国際特許分類】
【出願日】平成２１年３月３０日（２００９．３．３０）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
[ Back to top ]