(57)【要約】【課題】  電子メールのコンテンツを受信者の契約内容を公開することなく、安全に配信することができる電子メールコンテンツ選択・変換方法および装置を提供する。【解決手段】  メール送信事業者がサービスタイプのカテゴリー別に送信したいパートのセットを用意し、それらを明示的に指定するので、電子メールのコンテンツを受信者の契約内容を公開することなく、安全に配信することができる電子メールコンテンツ選択・変換方法および装置の提供を実現することができる。【選択図】  図１
2005141653.tif 000002
【特許請求の範囲】
【請求項１】
電子メールコンテンツ選択・変換方法において、
メールサービスプロバイダは、加入者に対しては、メール本文のサイズ制限や添付ファイルの形式、個数などの属性をサービスタイプとして定義して提供し、電子メールのコンテンツを配信する事業者に対しては、サービスタイプを公開し、個々のメールサービスプロバイダの加入者にどのサービスタイプが設定されているかという情報を非公開とし、
メールサービスプロバイダの加入者は、複数あるサービスタイプのいずれか一つをサービスタイプとして設定し、
電子メールのコンテンツを配信する事業者は、公開されたサービスタイプ別に所定の送信メールコンテンツ作成方法に従って配信したいメールフォーマットを明確に指定し、受信者の表示能力にそって最適なフォーマットに選択・変換して配信することを特徴とする電子メールコンテンツ選択・変換方法。
【請求項２】
前記メールサービスプロバイダは、受信者が保有するメール表示端末の表示能力に沿って最適なフォーマットに選択・変換することを特徴とする請求項１記載の電子メールコンテンツ選択・変換方法。
【請求項３】
前記メールサービスプロバイダは、前記前記サービスタイプを明確に指定するために、サービスタイプ別送信パート拡張ヘッダを定義し、前記送信メールコンテンツ作成方法にて作成可能にすることを特徴とする請求項１または２記載の電子メールコンテンツ選択・変換方法。
【請求項４】
前記メールサービスプロバイダは、電子メールのコンテンツを配信する事業者に対し、配信可能なインターフェイス、プログラムである専用拡張メール作成ツールを提供し、
電子メールのコンテンツを配信する事業者は、専用拡張メール作成ツールを前記事業者のパソコンにインストールして使用するか、もしくはメールサービスプロバイダが提供するウェブ上に用意されたウェブサイト上から、サービスカテゴリー別に、本文、リッチコンテンツ、添付ファイル等を設定し、ＳＭＴＰサーバへ送信すると共にサービスタイプ別送信パート拡張ヘッダを付与することを特徴とする請求項１から３のいずれか１項記載の電子メールコンテンツ選択・変換方法。
【請求項５】
前記サービスタイプ別送信パート拡張ヘッダは、常にトップレベルがマルチパート／ミクストであり、ネストのレベルが１階層の形式になっており、各サブパートに先頭から０番、１番、…と順にインデックスを付与し、受信者のサービスタイプのカテゴリが決定した場合に、どのインデックス番号のサブパートを選択するかを明示的に記述したものとなっていることを特徴とする請求項３または４記載の電子メールコンテンツ選択・変換方法。
【請求項６】
電子メールコンテンツ選択・変換装置において、
メールを受け付け、サービスタイプ別送信パート拡張ヘッダを解釈するメール受付手段および拡張フォーマットを作成する拡張フォーマット作成手段を有する拡張フォーマット作成部と、
該拡張フォーマット作成部からのメールを格納するメール格納手段および受信者の最適なメールフォーマットを決定し、必要な箇所のみ受信者へ送信するメール取得手段を有するメール選択部と、
前記メール取得手段が受信者の最適なメールフォーマットを決定すべく参照するユーザエージェント管理テーブル、サービスタイプ定義テーブル、ユーザ情報管理テーブル、メールボックスを有する記憶部と、
を備えたことを特徴とする電子メールコンテンツ選択・変換装置。
【請求項７】
前記メールボックスは、受信者ごとのメール格納領域を有し、当該受信者宛のメールをファイルにして前記領域に格納し、前記サービスタイプ定義テーブルはサービスタイプの種類を定義し、それぞれのサービスタイプがどのようなポリシーで構成されているかを記述し、前記ユーザエージェント管理テーブルは、サービスタイプ別に当該サービスタイプを実現可能な受信移動機の機種のリストあるいは実現不可能な受信移動機の機種のリストが記載され、前記ユーザ情報管理テーブルは、契約受信者すべてのレコードの集合であり、フィールドには各受信者の契約に関するさまざまな属性が存在することを特徴とする請求項６記載の電子メールコンテンツ選択・変換装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、電子メールコンテンツ選択・変換方法および装置に関する。
【背景技術】
【０００２】
携帯電話による電子メールの送受信が非常に広く普及している。また、携帯電話加入者が興味を持っている、ある特定の情報について、電子メール形式でメール送信事業者から情報を受信することを携帯電話加入者が了承した場合、メール送信事業者から、電子メール形式で情報が配信され、受信できる情報サービスも普及している。
このように携帯電話端末の改良に伴い、受信できる電子メールのサイズが大きくなり、より多くの添付ファイル形式がサポートされるようになってきているが、その表示能力は携帯電話端末の機種により異なっている。
【０００３】
携帯電話端末における相対的な流通量は、現在のところ、従来の携帯電話端末が受信できる電子メールのサイズは最新の携帯電話端末が受信できる電子メールのサイズに比べて小さくなり、添付ファイルの形式についても従来の携帯電話端末は最新の携帯電話端末に比べてサポートされるものが少ない機種の方が多くなっている。
【０００４】
また、携帯電話でメール送受信可能なサービスを提供するメールサービスプロバイダは、提供するサービスをカテゴリーに分類し、受信できる電子メールのサイズや添付ファイルの形式を定義している。本来、電子メールで情報を配信する事業者は、受信者の受信できる電子メールのサイズや形式を正確に把握する必要があるが、メールサービスプロバイダは、加入者情報の公開が、メールサービスプロバイダ自身の利益にならない場合や、情報流出として受け止められないよう、戦略上、セキュリティ上の理由で非公開としている場合が多い。
【０００５】
また、例え加入者情報が公開されたり、受信者からの直接申告があり、メール配信事業者がこれらの情報を知り得たりしても、加入者が逐次契約変更や携帯電話端末の機種変更を行った場合、変更後の情報をメールサービス事業者が正確に把握するのは困難である。
【０００６】
さらに、メールサービスプロバイダが新しいサービスタイプを定義した場合、受信者からの直接申告があったとしても正確さはますます低くなる傾向にあった。これらの理由から、メールサービスプロバイダは、できるだけ多くの受信者に届けるためには、誰もが受信可能なように表示能力が最低の携帯電話端末の機種やメールサービスプロバイダが定義する最も低いサービスタイプに合わせ、サイズを小さく、形式も一番単純なものを、送付することが多かった。
【０００７】
この結果、受信者にとって配信されたメールの内容は魅力に欠けるものとなる場合があり、メール送信事業者も伝えたい情報をすべて伝えきれない場合が多くあり、またメールサービスプロバイダにとっても、特にメールの流通量や送信データの流通量に応じて対価を得ている場合は、その金額が大きくならなかった。
ここで、「メール送信事業者」とは、携帯メール向けに情報サービスを行っている会社であり、業種は問わない。例えば、通信社や新聞社等が挙げられる。これに対して、「メールサービスプロバイダ」は、広い意味ではＩＳＰであるが、メールサービスを提供している携帯電話会社をいう。
【０００８】
従来から、メールコンテンツの選択的な受信に関しては、メール表示端末に含まれるメール表示ソフト（メーラ）が自らの表示能力に合わせて、選択的にコンテンツを表示させることができた。「自らの表示能力」とは例えば、表示可能な最大サイズまでを表示する機能、HTMLなどのリッチコンテンツの表示機能、音楽・画像・動画などの添付ファイルの表示機能、を指し、それらの機能を有する場合は表示し、機能を有しない場合は非表示としていた。
この場合、メールサービスプロバイダは、非特許文献１としてのRFC2046で規定されるMIMEのmultipart/alternativeコンテントタイプを解釈し透過すればよく、あとはメーラに処理を任せることで実現可能であった。このRFC2046に従えば、メーラはmultipart/alternativeコンテントタイプ内の複数のサブパートを後方に存在するものから順に解析し、メーラが表示可能なもの一つ選択し表示することで実現されていた。
【０００９】
ただし、この方式で実現可能な形式は、プレインテキストとHTMLリッチコンテンツがmultipart/alternativeコンテントタイプ内にサブパートとして存在する場合に、メーラの表示能力によりいずれかを選択して表示するという、非常に単純な場合に限られていた。
【００１０】
一方、インターネットからの通常のメール送信者や、メールサービスプロバイダと正式に有料契約を締結したメール情報配信事業者にとっては受信者であるメールサービスプロバイダの加入者に対して、メール情報配信事業者は、可能な限り最大限リッチで新しいタイプのメールコンテンツを配信することで情報量を多く受信者に提供を行いたいと考えている。
【００１１】
また、メール情報配信事業者は、表現力が小さい端末を保有する加入者や、表現力の小さいサービスタイプに加入する加入者に対しては、その表現力の範囲内で最大限の情報を送信したいと考えている。このときメール情報配信事業者は、サービスタイプ別に複数のサブパートを作成しさまざまなメッセージコンテンツを用意して、それぞれ対応したユーザに配信したいという要望はあったが、メールサービスプロバイダのメール配信システムが、メール送信事業者からのサービスタイプ別の情報を解析することができなかったことと、受信者ごとにメールフォーマットの変換を詳細に行っていなかったため実現することはできなかった
【００１２】
メールサービスプロバイダがサービスタイプを定義しており、かつ受信する端末の機種ごとに表示能力が異なる場合、RFC2046で規定されるMIMEのmultipart/alternativeコンテントタイプによる方法では、メール情報配信事業者側からどのサービスタイプに対してどのコンテンツを送信するかという情報をメールサービスプロバイダ側に明確に伝えることができなかったために、受信者側の表示能力をContent-Typeの形式でのみ自動的に決定しており、送信者側の意図を詳細に反映することができなかった。
【００１３】
また、RFC2046で規定されるMIMEのmultipart/alternativeコンテントタイプによる方法の問題点として、multipart/alternativeコンテントタイプの中の選択は通常複雑なほうから簡単なものへとContent-Typeを解釈し、メーラは解釈可能と判断したContent-Typeを表示しようと試みる。
【００１４】
ところが同じContent-Typeでありながら異なるコンテンツをサービスタイプごとに選択して受信させたいというケースがある。例えば、添付ファイルを表示可能なユーザにはプレーンテキストコンテントタイプの本文に「添付しました」のようなメッセージを、表示不可能なユーザにはプレーンテキストコンテントタイプの本文に参照先となるURLを記述する、などの場合が考えられる。
【００１５】
しかしこのような場合、従来のContent-Typeを見ただけでは、適切に選択することはできなかった。
また、添付ファイルについても同様の問題がある。添付ファイルはサポートするタイプをサービスタイプ別にあらかじめ定義しておき、受信者のサービスタイプにより、表示・非表示を決定していたため、表示可能な形式であってもサービスタイプごとに表示させたい添付ファイルと表示させたくない添付ファイルがある場合、同様の理由で、Content-Typeを見ただけでは判断がつかなかった。また、受信者のサイズ制限に違いがあるような場合、受信者ごとに形式は同じであるがサイズは違う添付ファイルを送信したい場合、適切に選択することはできなかった。
【００１６】
さらに、一部の単純な形式については RFC2046に規定されるMIMEのContent-Typeにmultipart/mixedやmultipart/alternativeを用いて表現することは可能である。ただし、通常メーラやメールサーバにおけるalternativeパートの解釈は、表現可能なものは表示する、あるいは任意の一つを選択する、という点であいまいさが残る。
プレインテキストとHTML形式との単純なmultipart/alternativeコンテントタイプから選択して表示する場合は判別も容易であるが、HTML形式や添付ファイルおよび添付ファイルの形式の組み合わせで、しかも契約者の種別カテゴリーが３つ以上や組み合わせになってくると、メール送信事業者から明示的に指定を受けないとメールサービスプロバイダのメール配信システムは選択対象を決定できなかった。
【００１７】
また、加入者が自らの加入サービスタイプや保有する受信端末の種類を明示的に電子メールのコンテンツを配信する事業者に通知する必要があるが、セキュリティ上公開したくない情報と考える場合通知することができなかった。また、変更したときに追従して通知する必要があり、運用上正確性が保証されていなかった。
これに対して、電子メールの添付ファイルのファイル形式やそのファイル内容を表示する際の画像サイズや最大色数等がどのようなものであっても、受信端末においてその添付ファイルの内容を表示することを目的とする情報処理装置および方法、情報処理システム、並びに媒体が提案されている（例えば、特許文献１参照）。
【００１８】
また、「電子メールを適切なメッセージ形式にして送信すること、また、電子メールのメッセージ形式に適した付加情報を送信することを目的とする電子メールのメッセージ形式に適した付加情報を送信すること」を目的とする電子メール処理装置、および電子メール処理方法も提案されている（例えば、特許文献２参照）。
【特許文献１】特開２００１−３１２４４６号公報
【特許文献２】特開２００２−５７６９６号公報
【非特許文献１】RFC2046: Multipurpose Internet Mail Extensions(MIME) Part Two: Media Types, 5.1.4. Alternative sub type
【発明の開示】
【発明が解決しようとする課題】
【００１９】
ところで、前述した特許文献１、２記載の発明はいずれも予め送信先の受信端末やメーラ、および受信端末やメーラの表示可能形式を登録しておき、送信メールが表示可能か否かを判断し、場合によっては変換して配信するものである。
しかしながら、特許文献１に記載の発明は、添付ファイル（画像ファイル）の表示能力の大小に応じて変換して表示させることが目的であり、通常同時に表示するテキストについては、例えば、添付ファイルを表示する場合と表示しない場合とで異なるものを表示させることはできないという問題がある。
【００２０】
また、特許文献２に記載の発明も同様に、実施例で示している付加情報（広告）について、複数の付加情報（広告）が存在するとき、それらをユーザごとの属性（サービスタイプ）により、適切な広告を選択して配信することができないという問題がある。
【００２１】
そこで、本発明の目的は、電子メールのコンテンツを受信者の契約内容を公開することなく、安全に配信することができる電子メールコンテンツ選択・変換方法および装置を提供することにある。
【課題を解決するための手段】
【００２２】
上記課題を解決するため、請求項１記載の発明は、電子メールコンテンツ選択・変換方法において、メールサービスプロバイダは、加入者に対しては、メール本文のサイズ制限や添付ファイルの形式、個数などの属性をサービスタイプとして定義して提供し、電子メールのコンテンツを配信する事業者に対しては、サービスタイプを公開し、個々のメールサービスプロバイダの加入者にどのサービスタイプが設定されているかという情報を非公開とし、メールサービスプロバイダの加入者は、複数あるサービスタイプのいずれか一つをサービスタイプとして設定し、電子メールのコンテンツを配信する事業者は、公開されたサービスタイプ別に所定の送信メールコンテンツ作成方法に従って配信したいメールフォーマットを明確に指定し、受信者の表示能力にそって最適なフォーマットに選択・変換して配信することを特徴とする。
【００２３】
請求項２記載の発明は、請求項１記載の発明において、前記メールサービスプロバイダは、受信者が保有するメール表示端末の表示能力に沿って最適なフォーマットに選択・変換することを特徴とする。
【００２４】
請求項３記載の発明は、請求項１または２記載の発明において、前記メールサービスプロバイダは、前記サービスタイプを明確に指定するために、サービスタイプ別送信パート拡張ヘッダを定義し、前記送信メールコンテンツ作成方法にて作成可能にすることを特徴とする。
【００２５】
請求項４記載の発明は、請求項１から３のいずれか１項記載の発明において、前記メールサービスプロバイダは、電子メールのコンテンツを配信する事業者に対し、配信可能なインターフェイス、プログラムである専用拡張メール作成ツールを提供し、電子メールのコンテンツを配信する事業者は、専用拡張メール作成ツールを前記事業者のパソコンにインストールして使用するか、もしくはメールサービスプロバイダが提供するウェブ上に用意されたウェブサイト上から、サービスカテゴリー別に、本文、リッチコンテンツ、添付ファイル等を設定し、ＳＭＴＰサーバへ送信すると共にサービスタイプ別送信パート拡張ヘッダを付与することを特徴とする。
【００２６】
請求項５に記載の発明は、請求項３または４記載の発明において、前記サービスタイプ別送信パート拡張ヘッダは、常にトップレベルのコンテントタイプがmultipart/mixed（マルチパート／ミクスト）であり、ネストのレベルが１階層の形式になっており、各サブパートに先頭から０番、１番、…と順にインデックスを付与し、受信者のサービスタイプのカテゴリーが決定した場合に、どのインデックス番号のサブパートを選択するかを明示的に記述したものとなっていることを特徴とする。
【００２７】
請求項６記載の発明は、電子メールコンテンツ選択・変換装置において、メールを受け付け、サービスタイプ別送信パート拡張ヘッダを解釈するメール受付手段および拡張フォーマットを作成する拡張フォーマット作成手段を有する拡張フォーマット作成部と、該拡張フォーマット作成部からのメールを格納するメール格納手段および受信者の最適なメールフォーマットを決定し、必要な箇所のみ受信者へ送信するメール取得手段を有するメール選択部と、前記メール取得手段が受信者の最適なメールフォーマットを決定すべく参照するユーザエージェント管理テーブル、サービスタイプ定義テーブル、ユーザ情報管理テーブル、メールボックスを有する記憶部と、を備えたことを特徴とする。
【００２８】
請求項７記載の発明は、請求項６記載の発明において、前記メールボックスは、受信者ごとのメール格納領域を有し、当該受信者宛のメールをファイルにして前記領域に格納し、前記サービスタイプ定義テーブルはサービスタイプの種類を定義し、それぞれのサービスタイプがどのようなポリシーで構成されているかを記述し、前記ユーザエージェント管理テーブルは、サービスタイプ別に当該サービスタイプを実現可能な受信移動機の機種のリストあるいは実現不可能な受信移動機の機種のリストが記載され、前記ユーザ情報管理テーブルは、契約受信者すべてのレコードの集合であり、フィールドには各受信者の契約に関するさまざまな属性が存在することを特徴とする。
【００２９】
すなわち、本発明の電子メールコンテンツ選択・変換方法および装置による効果は、メールサービスプロバイダにより提供される。メールサービスプロバイダは、メール本文のサイズ制限や受信する添付ファイルの形式、個数などをサービスタイプとして定義する。
メールサービスプロバイダの加入者は、複数あるサービスタイプのいずれか一つをサービスタイプとして設定する。
メールサービスプロバイダは、電子メールのコンテンツを配信する事業者に対して、サービスタイプを公開するが、個々のメールサービスプロバイダの加入者がどのサービスタイプが設定されているかという情報は公開しない。電子メールのコンテンツを配信する事業者が公開されたサービスタイプ別に本発明で述べる送信メールコンテンツ作成方法に従って配信したいメールフォーマットを明確に指定し、本発明で述べる受信者の表示能力にそって最適なフォーマットに選択・変換して配信する。
【００３０】
また、本発明の電子メールコンテンツ選択・変換方法および装置では、受信者が保有するメール表示端末の表示能力にそって最適なフォーマットに選択・変換する。このように本発明では、電子メールのコンテンツの受信者であるメールサービスプロバイダの加入者の契約内容を公開することなく安全に、最適なフォーマットに選択・変換して電子メールを配信する。
サービスタイプを明確に指定するために、サービスタイプ別送信パート拡張ヘッダを定義し、これを本発明で述べる送信メールコンテンツ作成方法にて作成可能にし、また、作成されたサービスタイプ別送信パート拡張ヘッダの解釈を行うことを可能にし、受信者の表示能力にそって最適なフォーマットに選択・変換して配信することが可能になる。
【００３１】
メール送信事業者は、通常のメールソフトからの送信ではこのようなサービスタイプ別送信パート拡張ヘッダを付与して送付することは困難なことから、メールサービスプロバイダがメール送信事業者に対し、このような形式（サービスタイプ別送信パート拡張ヘッダを付与した形式）で配信可能なインターフェイスであり、プログラムである専用拡張メール作成ツールを提供する。メール送信事業者は、専用拡張メール作成ツールを事業者のPCにインストールして使用するか、もしくは、メールサービスプロバイダが提供するWeb上に用意されたWebサイトから、サービスカテゴリー別に、本文、リッチコンテンツ、添付ファイルなどを設定する。設定後、メール送信事業者は、電子メールをSMTPサーバへ送信する。
【００３２】
このとき、以下のサービスタイプ別送信パート拡張ヘッダが電子メールに付与される。これはmultipart/alternative（マルチパート／オルタネーティブ）コンテントタイプを用いるのではなく、常にトップレベルのコンテントタイプがmultipart/mixed（マルチパート／ミクスト）でネストのレベルが1階層の形式になっている。その各サブパートに先頭から0番、1番、2番、…と順にインデックスを付与し、受信者のサービスタイプのカテゴリーが決定した場合に、どのインデックス番号のサブパートを選択するかを明示的に記述したものとなっている。例として「X-Category-0: 0」、「X-Category-1: 1」、「X-Category-2: 2,3,4,5」のサービスタイプ別送信パート拡張ヘッダが付与される場合について述べる。
ここで、「ネスト」とは、マルチパートコンテントタイプの中にさらにマルチパートコンテントタイプが存在する状態をいう。
【００３３】
メールサーバのメール受付手段は、サービスタイプ別送信パート拡張ヘッダを解釈する機能を有する。このときメール受付手段は、サービスタイプ定義テーブルおよびユーザ情報管理テーブルを参照する。ここ（メール受付手段）では受信者の保有する携帯電話の機種や加入するサービスタイプに関わらず、メールサービスプロバイダのメールシステム全体で許可しているサイズや形式に合致しているかどうかのチェックのみを行う。そしてメール格納手段がメールを受け取り、メールボックスの受信者用のメッセージ格納領域へメールを保存する。
【００３４】
一方、メール取得手段は、User Agent管理テーブル、サービスタイプ定義テーブル、ユーザ情報管理テーブルを参照し、受信者の最適なメールフォーマットを決定する。そして、メールボックスに保存されていたメールデータから、サービスタイプ別送信パート拡張ヘッダを解釈し、必要な箇所のみ受信者へ送信する。
以上に述べる、サービスタイプ別送信パート拡張ヘッダの定義、サービスタイプ別送信パート拡張ヘッダの作成手段の提供、サービスタイプ別送信パート拡張ヘッダを解釈する手段の提供、また、受信者の最適なメールフォーマットを作成する手段が
User Agent管理テーブル、サービスタイプ定義テーブル、ユーザ情報管理テーブル、などの受信者の表示能力に関する情報、メールサービスプロバイダが提供するサービスタイプの情報、受信者の加入するサービスタイプの情報、に対して最新の情報を参照して実行されることにより、以下の問題解決が行われる
【００３５】
。
第１に、メールサービスプロバイダの加入者の契約内容を公開することなく安全に、加入者のサービスタイプや保有する携帯電話端末の表現能力に最適なフォーマットに選択・変換してメールコンテンツの配信を行える。
【００３６】
第２に、受信者の保有する携帯電話端末の機種により受け取り可能なフォーマットに違いがある場合、メール送信事業者は意識する必要がなく、最適なフォーマットに選択・変換してメールコンテンツの配信を行える。
【００３７】
第３に、受信者が保有する携帯電話端末の機種を変更したり、加入するサービスタイプを変更した場合に、受信者の受け取り可能なフォーマットに変更が生じた場合、メール送信事業者は意識する必要がなく、最適なフォーマットに選択・変換してメールコンテンツの配信を行える。
【００３８】
第４に、携帯電話端末の機種の仕様上受信可能なタイプと公開しているが、受信できない場合や受信すると故障する場合、幅広く普及している機種の場合は費用面から回収・交換せずにメールサーバ側で特定機種に対して特別な処理を行う必要がある場合、本機能を用いることで対応可能となる。
【発明の効果】
【００３９】
メール送信事業者がサービスタイプのカテゴリー別に送信したいパートのセットを用意し、それらを明示的に指定するので、電子メールのコンテンツを受信者の契約内容を公開することなく、安全に配信することができる電子メールコンテンツ選択・変換方法および装置の提供を実現することができる。
【発明を実施するための最良の形態】
【００４０】
まず、本発明の電子メールコンテンツ選択・変換方法および装置は、電子メールのコンテンツを受信者の契約内容を公開することなく安全に、最適なフォーマットに選択・変換して配信することができるものである。
本発明の効果は、メールサービスプロバイダにより提供される。メールサービスプロバイダは、メール本文のサイズ制限や受信する添付ファイルの形式、個数などをサービスタイプとして定義する。メールサービスプロバイダの加入者は、複数あるサービスタイプのいずれか一つをサービスタイプとして設定する。メールサービスプロバイダは、電子メールのコンテンツを配信する事業者に対して、サービスタイプを公開する。個々のメールサービスプロバイダの加入者がどのサービスタイプが設定されているかという情報は公開しない。電子メールのコンテンツを配信する事業者が公開されたサービスタイプ別に本発明で述べる送信メールコンテンツ作成方法に従って配信したいメールフォーマットを明確に指定し、本発明で述べる受信者の表示能力にそって最適なフォーマットに選択・変換して配信する。
【００４１】
ここで、「受信者の表示能力」とは、表示文字数、記録文字数、表示可能絵文字数、表示可能顔文字数に加え、画像／音楽等の添付ファイルの表示可否、ＨＴＭＬ形式をはじめとしたリッチテキスト形式の表示可否を含む能力をいう。
また、本発明では受信者が保有するメール表示端末の表示能力にそって最適なフォーマットに選択・変換することも行う。
このように本発明の電子メールコンテンツ選択・変換方法および装置は、電子メールのコンテンツの受信者であるメールサービスプロバイダの加入者の契約内容を公開することなく安全に、最適なフォーマットに選択・変換して電子メールを配信する。
【００４２】
次に、本発明の電子メールコンテンツ選択・変換方法および装置の実施の形態について図面を参照して詳細に説明する。
図１は、本発明の電子メールコンテンツ選択・変換方法を適用した装置の第１の実施の形態を示すブロック図である。
【００４３】
図１を参照すると、本発明の装置には、拡張フォーマット作成部２００、記憶部３００、およびメール選択部４００が存在する。これらは同一の装置上にあっても、異なる装置上にあってもなんら変わりはない。本発明で示す機能はメールサーバの中に構成される。
拡張フォーマット作成部２００は、メール受付手段２１０、および、拡張ヘッダ作成手段２２０から構成される。これらの手段２１０、２２０は、メールサービスプロバイダにより管理・運営されているものとする。また、このメールサービスプロバイダのメール送信システムを利用しメールを特定のユーザに送信する事業者を「メール送信事業者」と呼ぶこととする。
【００４４】
メール受付手段２１０は、メール送信事業者から、インターネットおよび専用線１００から、送信する全メールデータ(図６参照)、および、サービスタイプ別送信パート情報(図５参照)、を受け取る（メールサーバの中に存在するＳＭＴＰプロトコルのＤＡＴＡコマンドとともに渡されるメールデータを受信する）機能を有する。
メールデータは、マルチパートのサブパートとなる形式でそれぞれのサービスタイプで送信するデータのすべてである。メールデータは、ＳＭＴＰプロトコルのＤＡＴＡコマンドによって渡されるメールのボディ部分(ヘッダおよび本文)に相当する。また、「サービスタイプ」は、メール本文のサイズ制限や受信する添付ファイルの形式、個数などを定めたものの総称である。
【００４５】
サービスタイプ別送信パート情報は、サービスタイプ別にどのサブパートを送信するかを表す情報であり、メール送信事業者が指定する。あらかじめサービスタイプはメールサービスプロバイダからメール送信事業者に公開されている。
拡張ヘッダ作成手段２２０は、はじめに、メール受付手段２１０より、送信する全メールデータ(図６参照)とサービスタイプ別送信パート情報(図５参照)とを受け取る。そして、拡張ヘッダ作成手段２２０は、これらの情報から、サービスタイプ別送信パート拡張ヘッダ(図７参照)を作成し、このサービスタイプ別送信パート拡張ヘッダをメールヘッダ部に付与し、メール本文部にメールデータから抽出したサブパートを付与し、マルチパート化し、送信するためのメールデータを作成する。
【００４６】
なお、サービスタイプ別送信パート拡張ヘッダに記載する際に、目的のサブパートを特定する重要で唯一の情報は、メール本文部のメールデータの配置する順番であるため、厳密に規定される。
【００４７】
メール選択部４００は、メール格納手段４１０とメール取得手段４２０とから構成される。
記憶部３００は、メールボックス３３０、サービスタイプ定義テーブル３１０、
User Agent管理テーブル３４０、および、ユーザ情報管理テーブル３２０から構成されるメールボックス３３０は、受信者ごとのメール格納領域を持ち、当該受信者宛のメールをファイルにして同領域に保存する。サービスタイプ定義テーブル３１０は、サービスタイプの種類を定義し、それぞれのサービスタイプがどのようなポリシーで構成されているかを記述している。User Agent管理テーブル３４０はサービスタイプ別に、当該サービスタイプを実現可能な受信移動機の機種のリスト、あるいは実現不可能な受信移動機の機種のリストが記載されている。ユーザ情報管理テーブル３２０は、契約受信者すべてのレコードの集合であり、フィールドには各受信者の契約に関するさまざまな属性が存在する。
【００４８】
メール格納手段４１０は、拡張フォーマット作成手段２２０より、メール形式でメールデータを受信し、受信ユーザのメールボックス３３０にメールデータを書き込む。このときにサービスタイプ定義テーブル３１０に従い、ユーザ情報管理テーブル３２０を参照し、適切な形式で格納する。
【００４９】
メール取得手段４２０は、携帯電話網５００からの受信者のメールボックス３３０へのメール取得要求をトリガとし、メールボックス３３０からメールデータを取得する。また、このメール取得要求には、受信者の受信移動機の機種を識別するUser Agent情報が含まれている。メール取得手段４２０は、User Agent情報を認識し、サービスタイプ定義テーブル３１０に従い、User Agent管理テーブル３４０およびユーザ情報管理テーブル３２０を参照し、適切なサービスタイプを決定し、メールボックス３３０に格納されているサービスタイプ別送信パート拡張ヘッダを解析し、拡サービスタイプ別送信パート拡張ヘッダのうち該当するサービスタイプに記載のサブパートのみを選択し、マルチパート化して、携帯電話網５００を通じて移動機端末へ送信する。端末は、受信したメールを表示する。
【００５０】
（第１の実施の形態の動作の説明）
次に、図２、図３、図４のフローチャートを参照して本発明の第１の実施の形態の動作について詳細に説明する。
図２は、図１に示した装置に用いられるメール受付手段２１０の動作を示すフローチャートである。
【００５１】
メール受付手段２１０は、メール送信事業者から、インターネットおよび専用線１００から、送信する全メールデータを受信し（ステップＳ６０１）、サービスタイプ別送信パート情報を受信する（ステップＳ６０２）。
図５にサービスタイプ別送信パート情報の例を示す。
サービスタイプ別送信パート情報は、サービスタイプとそれに対応するサブパートのインデックスの情報である。サービスタイプは、メール本文のサイズ制限や受信する添付ファイルの形式、個数などを定めたものの総称である。サービスタイプ別送信パート情報は、サービスタイプ別にどのサブパートを送信するかという情報であり、メール送信事業者が指定する。あらかじめサービスタイプはメールサービスプロバイダからメール送信事業者に公開されている。
【００５２】
図５では、サービスタイプに「Category0」、「Category1」、および「Category2」、が定義されている。対応するサブパートのインデックスとして、「Category0」にはインデックス「0」が指定され、「Category1」にはインデックス「1」が指定され、「Category2」にはインデックス「2」と「3」とが指定されている。
また、あらかじめメール送信事業者には宛先リストが公開されている。公開されている内容はメールサービスプロバイダのメールシステム内で管理されているアカウント情報でなく、一定の変換を施したものである。公開される情報は、ユーザ情報管理テーブルの公開するアカウントフィールドに記載の宛先である。
【００５３】
ここで、「一定の変換」とは、例えば、「user1」というアカウントに対し「id001」というようにアカウントそのもの以外のものへの変換を指す。アカウントをメール送信事業者に公開しないのが目的である。
図１０ではユーザアカウント「user1」に対しては「id001」というアカウントが対応付けられており、ユーザアカウント「user2」に対しては「id002」というアカウントが対応付けられており、ユーザアカウント「user3」に対しては「id003」というアカウントが対応付けられており、これらのアカウントが公開される。
【００５４】
図６にメールデータの具体例を示す。
メールデータは、マルチパートのサブパートとなる形式でそれぞれのサービスタイプで送信するデータのすべてである。メールデータは、ＳＭＴＰプロトコルのＤＡＴＡコマンドによって渡されるメールのボディ部分(ヘッダおよび本文)に相当する。
図６ではメールデータに４つのサブパートが存在し、それぞれインデックスが０から３まで付与されている。
インデックス０のサブパートは、Content-Typeが「text/plain」のテキストパートであり、サービスタイプ「Category0」用のテキストデータとして用いられる。インデックス１のサブパートは、Content-Typeが「text/html」のテキストパートであり、サービスタイプ「Category1」用のテキストデータとして用いられる。インデックス２のサブパートは、Content-Typeが「text/html」のテキストパートであり、サービスタイプ「Category2」用のテキストデータとして用いられる。インデックス４のサブパートは、Content-Typeが「image/jpeg」の添付ファイルであり、サービスタイプ「Category2」用の添付ファイルデータとして用いられる。
【００５５】
なお、インデックス２のデータは、インデックス３のデータがあるため本文の内容はインデックス１と２と異なっている。
拡張ヘッダ作成手段２２０は、はじめに、メール受付手段２１０より、送信する全メールデータとサービスタイプ別送信パート情報を受け取る（ステップＳ６０２：図２参照）。そして、これらの情報から、サービスタイプ別送信パート拡張ヘッダを作成する（ステップＳ６０３：図２参照）。このサービスタイプ別送信パート拡張ヘッダをメールヘッダ部に付与し、メール本文部にメールデータから抽出したサブパートを付与し、マルチパート化し、送信するためのメールデータを作成する（ステップＳ６０４：図２参照）。
【００５６】
なお、サービスタイプ別送信パート拡張ヘッダを作成する際に、目的のサブパートを特定する重要で唯一の情報は、メール本文部のメールデータの配置する順番であるため、厳密に規定される。
【００５７】
図７にサービスタイプ別送信パート拡張ヘッダを示す。
図７では、「X-Category0」拡張ヘッダにインデックス０のサブパートを示す「0」が設定され、「X-Category1」拡張ヘッダにインデックス１のサブパートを示す「1」が設定され、「X-Category2」拡張ヘッダにインデックス２および３のサブパートを示す「2」と「3」が設定されている。
【００５８】
図８に記憶部３００に含まれる、サービスタイプ定義テーブル３１０の例を示す。
サービスタイプ定義テーブル３１０は、サービスタイプの種類を定義し、それぞれのサービスタイプがどのようなポリシーで構成されているかを記述している。
図８では、サービスタイプのカテゴリーごとにリッチコンテンツの表示可否、添付ファイルの表示可否のフィールドが存在する。サービスタイプのカテゴリーが「Category0」の場合、リッチコンテンツは「表示不可」であり、添付ファイルは「表示不可」である。サービスタイプのカテゴリーが「Category1」の場合、リッチコンテンツは「表示可」であり、添付ファイルは「表示不可」である。サービスタイプのカテゴリーが「Category2」の場合、リッチコンテンツは「表示可」であり、添付ファイルは「表示可」である。
【００５９】
次に図９にUser Agent管理テーブル３４０の例を示す。
User Agent管理テーブル３４０は、サービスタイプ別に、当該サービスタイプを実現可能な受信移動機の機種のリスト、あるいは実現不可能な受信移動機の機種のリストが記載されている。
図９ではサービスタイプのカテゴリーごとに非対応機種のUser Agent属性の値が記述されている。サービスタイプのカテゴリーが「Category2」の場合、「N503i」が設定されており、これらの２種類の機種が非対応であることを表している。
【００６０】
図１０にユーザ情報管理テーブル３２０の例を示す。
ユーザ情報管理テーブル３２０は、契約受信者すべてのレコードの集合であり、フィールドには各受信者の契約に関するさまざまな属性が存在する。ユーザ情報管理テーブルには多くのフィールドが存在するが図１０では一部のみ表示している。
図１０ではユーザアカウントと加入サービスタイプを記述している。
ユーザアカウントが「user1」のユーザの加入サービスタイプは「Category0」となっており、ユーザアカウントが「user2」のユーザの加入サービスタイプは「Category1」となっており、ユーザアカウントが「user3」のユーザの加入サービスタイプは「Category2」となっている。
【００６１】
図３は、図１に示した装置に用いられるメール格納手段４１０の動作を示すフローチャートである。
メール格納手段４１０は、拡張フォーマット作成手段２２０より、メール形式でメールデータを受信する（ステップＳ６１１）。
また、ユーザ情報管理テーブル３２０を参照し、宛先の加入サービスタイプを確認する（ステップＳ６１２）。
次に、サービスタイプ定義テーブル３１０を参照し、サービスタイプの内容を確認する（ステップＳ６１３）。
その後、受信ユーザのメールボックス３３０にメールデータを適切な形式で格納する（ステップＳ６１４）。
なお、受信ユーザを判断する場合は、メール送信事業者は公開されたアカウントで受信者を指定してくるので、メール格納手段４１０は公開されたアカウントをメールサービスプロバイダ内部で使用しているアカウントに変換を行い、宛先のメールボックスを特定する。
【００６２】
ここで、第１の格納例として、メールボックス格納時にサブパートを選択する場合を説明する。
同報で「user1」、「user2」、および「user3」にこのメールデータ送信する場合、メールボックス３３０に格納する形式について説明する。
「user1」は、サービスタイプが「Category0」であるので、インデックス「0」のサブパートを格納し、「user2」は、サービスタイプが「Category1」であるので、インデックス「1」のサブパートを格納し、「user3」はサービスタイプが「Category2」であるので、インデックス「2」およびインデックス「3」のサブパートを格納する。
第２の格納例として、後述するメール取得手段４２０にサブパートの選択をさせる場合には、拡張フォーマット作成手段２２０より、受信したメールデータをそのまますべてメールボックス３３０に格納する。以降はこの第２の格納例を実施した場合の動作を説明する。
【００６３】
図４は、図１に示した装置に用いられるメール取得手段４２０の動作を示すフローチャートである。
メール取得手段４２０は、携帯電話網５００からの受信者のメールボックス３３０へのメール取得要求をトリガとし、メールボックス３３０からメールデータを取得する。また、このメール取得要求には、受信者の受信移動機の機種を識別するUser Agent情報が含まれている（ステップＳ６２１）。
メール取得手段４２０は、ユーザ情報管理テーブル３２０を参照して取得するユーザのサービスタイプを確認し（ステップＳ６２２）、サービスタイプ定義テーブル３１０を参照してサービスタイプの内容を確認し（ステップＳ６２３）、適切なサービスタイプを決定する。さらに、メール取得手段４２０は、ステップＳ６２１のメール取得要求に含まれるUser Agent情報をUser Agent管理テーブル３４０内から検索し（ステップＳ６２４）、メールボックス３３０に格納されてサービスタイプ別送信パート拡張ヘッダを解析し、各サービスタイプ別送信パート拡張ヘッドのうち該当するサービスタイプに記載のサブパートのみを選択し、マルチパート化して、携帯電話網５００を通じて移動機端末へ送信する。端末は受信したメールを表示する（ステップＳ６２５）。
【００６４】
（実施の形態の効果の説明）
第１の効果は、メールサービスプロバイダの加入者の契約内容を公開することなく安全に、加入者のサービスタイプや保有する携帯電話端末の表現能力に最適なフォーマットに選択・変換してメールコンテンツの配信を行えることにある。
【００６５】
第２の効果は、受信者の保有する携帯電話端末の機種により受け取り可能なフォーマットに違いがある場合、メール送信事業者は意識する必要がなく、最適なフォーマットに選択・変換してメールコンテンツの配信を行えることにある。
【００６６】
第３の効果は、受信者が保有する携帯電話端末の機種を変更したり、加入するサービスタイプを変更したりする場合に、受信者の受け取り可能なフォーマットに変更が生じると、メール送信事業者は意識する必要がなく、最適なフォーマットに選択・変換してメールコンテンツの配信を行えることにある。
【００６７】
第４の効果は、携帯電話端末の機種の仕様上受信可能なタイプと公開しているが、受信できない場合や受信すると故障する場合、幅広く普及している機種の場合は費用面から回収・交換せずにメールサーバ側で特定機種に対して特別な処理を行う必要がある場合、本機能を用いることで対応可能となることである。
【００６８】
（本発明の第２の実施の形態）
第１の実施の形態では電子メールをメールボックス３３０に格納する前にメール格納手段４１０はメールコンテンツの選択を行わず、すべてのメールデータを格納し、メール取得手段４２０で選択を行っていたが、本発明はこれに限定されるものではなく、メール格納手段４１０がユーザ情報管理テーブル３２０を参照し、選択してメールボックス３３０に格納する形態も可能である。
メールコンテンツの入力時と受信者のメールの取得時との間に、サービスタイプを変更した受信者に対して、新しい契約に沿ってサービスを提供したいと考える場合は、メール格納手段４１０で選択するのではなく、すべての形式を保存し、メール取得手段４２０の方で選択して受信させる形態を取ることができる。
【００６９】
一方、メールボックス格納容量を抑えたいというポリシーの場合や、あくまでメールコンテンツの入力時のサービスタイプによりサービスを決定するというポリシーの場合は、メール格納手段４１０はメールコンテンツの選択を行う。これらの動作は、メールサービスプロバイダのサービス提供のポリシーにより柔軟に決定することが可能な形態となっている。
【００７０】
また、前述の実施の形態で述べたサービスタイプのカテゴリーは３つの例であり、例えば添付ファイルの形式を詳細に定義するなど３つ以上に拡張することが可能である。その場合はカテゴリーを増やしていくことになるが、いくら増やしても制限を受けることはなく、この発明によるシステム全体も同様に動作する。
【００７１】
また、第１の実施の形態では、インターネットおよび専用線からの入力の形態であったが、本発明はこれに限定されるものではなく、入力が携帯電話からの携帯電話網５００経由での入力であっても何ら問題はない。
【００７２】
ところで、本発明は、テキストやリッチテキスト（ＨＴＭＬなど）や添付ファイルについて、コンテンツタイプや添付ファイル形式等が同じであっても、サービスタイプごとに表示させたいコンテンツを選択することが可能となっている。
つまり、前述した特許文献１、２に記載の発明は、受信端末あるいは受信メーラが表示可能であるか否かを基準に、対象メールデータを表示させるか否かを判断しているのに対し、本発明では、メール送信事業者がサービスタイプのカテゴリー別に送信したいパートのセットを用意し、それらを明示的に指定することが可能となっている点で、本発明と特許文献１、２に記載の発明と相違する。
【００７３】
このため、前述した二つの特許文献１、２に記載の発明では実現することができなかった、テキスト形式であっても添付ファイルが表示される場合と表示されない場合とで表示できるテキストを異なるものにすることや、サービスタイプ別に異なる広告を送信すること等が可能となっている。
【００７４】
また、本発明では、メール送信事業者は、各ユーザのサービスタイプを意識せず、メールサービスプロバイダがサポートしているサービスタイプさえ知っていればよい点において、前述した二つの特許文献１、２に記載の発明と相違する。
さらに、本発明のようなサービスタイプごとの指定を行うには、一般のメーラの持つ機能では不可能であり、そのための拡張フォーマット作成手段を有する点で、本発明と前述した二つの特許文献１、２に記載の発明と相違する。
【図面の簡単な説明】
【００７５】
【図１】本発明の電子メールコンテンツ選択・変換方法を適用した装置の第１の実施の形態を示すブロック図である。
【図２】図１に示した装置に用いられるメール受付手段２１０の動作を示すフローチャートである。
【図３】図１に示した装置に用いられるメール格納手段４１０の動作を示すフローチャートである。
【図４】図１に示した装置に用いられるメール取得手段４２０の動作を示すフローチャートである。
【図５】サービスタイプ別送信パート情報の例を示す図である。
【図６】メールデータの具体例を示す図である。
【図７】サービスタイプ別送信パート拡張ヘッダを示す図である。
【図８】記憶部３００に含まれる、サービスタイプ定義テーブル３１０の例を示す図である。
【図９】User Agent管理テーブル３４０の例を示す図である。
【図１０】ユーザ情報管理テーブル３２０の例を示す図である。
【符号の説明】
【００７６】
１００    インターネット／専用線
２００    拡張フォーマット作成部
２１０    メール受付手段
２２０    拡張フォーマット作成手段
３００    記憶部
３１０    サービスタイプ定義テーブル
３２０    ユーザ情報管理テーブル
３３０    メールボックス
３４０    User Agent管理テーブル
４００    メール選択部
４１０    メール格納手段
４２０    メール取得手段
５００    携帯電話網
【図１】
2005141653.tif 000003
【図２】
2005141653.tif 000004
【図３】
2005141653.tif 000005
【図４】
2005141653.tif 000006
【図５】
2005141653.tif 000007
【図６】
2005141653.tif 000008
【図７】
2005141653.tif 000009
【図８】
2005141653.tif 000010
【図９】
2005141653.tif 000011
【図１０】
2005141653.tif 000012