(57)【要約】【課題】リアルタイム性及び、経済性を実現するメールデータの圧縮方法及びこれを適用するウェブ（Ｗｅｂ）メールシステムを提供する。【解決手段】メールを保存しているセンターからインターネットに接続される端末へ送信されるメールデータの圧縮方法であって、前記センターに置かれる辞書に、文字列と該文字列に対応する番号を登録し、前記センターに置かれる辞書に登録された番号をアドレスとして対応する文字列を端末側辞書に保持し、前記センターから送信されるメールデータを送信する際に、前記メールデータの原文に含まれる文字列であって、前記センターに置かれる辞書に登録された文字列を、前記対応する登録番号に置き換えて前記端末に送信し、前記端末で受信されるメールデータに含まれる前記置き換えられた登録番号をアドレスとして前記端末側辞書から文字列を抽出して、前記メールデータの原文を復元する。【選択図】図３
2004274489.tif 000002
【特許請求の範囲】
【請求項１】
メールを保存しているセンターからインターネットに接続される端末へ送信されるメールデータの圧縮方法であって、
前記センターに置かれる辞書に、文字列と該文字列に対応する番号を登録し、
前記センターに置かれる辞書に登録された番号をアドレスとして対応する文字列を端末側辞書に保持し、
前記センターから送信されるメールデータを送信する際に、前記メールデータの原文に含まれる文字列であって、前記センターに置かれる辞書に登録された文字列を、前記対応する登録番号に置き換えて前記端末に送信し、
前記端末で受信されるメールデータに含まれる前記置き換えられた登録番号をアドレスとして前記端末側辞書から文字列を抽出して、前記メールデータの原文を復元することを特徴とするメールデータ圧縮方法。
【請求項２】
請求項１において、
前記文字列に対応する登録番号への置き換えの際に、置き換えを示す制御記号を前記置き換えられた登録番号に付すことを特徴とするメールデータ圧縮方法。
【請求項３】
請求項１において、
前記センターに置かれる辞書への文字列の登録は、該当の端末宛のメールの発生の際に行い、且つ文字列毎に発生の頻度を記録することを特徴とするメールデータ圧縮方法。
【請求項４】
請求項３において、
前記記録される文字列の所定期間中の発生頻度が所定値以上である対応する登録番号を前記センターから前記端末に送り、前記端末側辞書に保持することを特徴とするメールデータ圧縮方法。
【請求項５】
請求項１において、
前記センターは、前記センターに置かれる辞書の登録の更新を記録し、前記端末かメールの読み出し要求があったときに、前記メールの送信に先立って前記更新された辞書の内容を前記端末に送り、前記センターと端末側辞書の内容を同期させることを特徴とするメールデータ圧縮方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、携帯電話など移動端末から利用するメールデータの圧縮方法に関する。
【０００２】
【従来の技術】
近年、移動端末としての携帯電話を使用してメールの送受信を行うことが普及している。かかる携帯電話を使用したメールシステムは次の２つに分類できる。
【０００３】
（１）携帯メール
メール到着時に自動的にセンターから携帯端末にメール全体が送信される方式である。特徴として、メールが到着すると、直ちに配送される即時性が挙げられる。
【０００４】
一方、メール一件あたりの最大容量が比較的小さいこと、端末に多くのメールが保存できないこと、添付ファイルを扱うのが難しいこと、受信時にも課金される通信事業者の運用による場合には、受信者にとって不要なメールにも課金されてしまう。あるいは、一部だけ読めば十分であってもメール全体の転送量に対して課金されてしまうなどの欠点がある。
【０００５】
（２）ウェブ（Ｗｅｂ）メール
分散ハイパーテキストドキュメントであるＷｅｂを用いたメールであり、メール到着時にセンターに蓄積しておき、携帯端末の使用者が着信の有無を確認する方式であり、Ｗｅｂアプリケーションの一つとして実装される例が多い。
【０００６】
特長としては、メールがセンターに蓄積されるため、メール一件あたりの容量及び、保存できる容量が大きいこと、添付ファイルを見るための機能をセンター側で提供できること、発信者あるいは題名などをあらかじめ確認してから必要なものだけを読み出すことができ通信料を節約できること等が挙げられる。一方、配達の即時性は期待できない。
【０００７】
一般的には、個人利用には即時性のある（１）の方式、ビジネス利用には大容量のメールを扱える（２）の方式が適している。
【０００８】
また、従来技術として、これら２方式を採用し、全てのメールを携帯電話機で確認可能とする受信メールの携帯電話対応のＷｅｂ方式によりメールサービスが提案されている（特許文献１参照）。
【０００９】
かかる特許文献１に記載される技術では、ユーザーが設定した選別条件に従い、プロバイダが受信メールを必要なものだけを携帯端末にリアルタイムに転送し、選別外の受信メールは、プロバイダにおいて保存され、ユーザーは、後に保存されている内容を携帯Ｗｅｂ経由で見ることが出来るようにしたものである。
【００１０】
【特許文献１】
特開２００２−８４３０９号公報
【００１１】
【発明が解決しようとする課題】
上記の特許文献１に記載された技術では、予め受信メールに選択基準を設け、基準に合う受信メールのみを即時性を持って閲覧可能にするものである。しかし、先に設定した基準と外れる受信メールにおいても、リアルタイムに閲覧すべきもの、あるいは、全てのメールの種別程度を把握しておきたいという要求に対して対応できるものではない。
【００１２】
従って、本発明の目的は、上記（２）の受信メール方式を基礎として、受信メールに対し、リアルタイム性及び、経済性を実現するメールデータの圧縮方法を提供することにある。
【００１３】
【課題を達成するための手段】
上記の本発明の目的を達成するメールデータの圧縮方法の、第１の態様は、メールを保存しているセンターからインターネットに接続される端末へ送信されるメールデータの圧縮方法であって、前記センターに置かれる辞書に、文字列と該文字列に対応する番号を登録し、前記センターに置かれる辞書に登録された番号をアドレスとして対応する文字列を端末側辞書に保持し、前記センターから送信されるメールデータを送信する際に、前記メールデータの原文に含まれる文字列であって、前記センターに置かれる辞書に登録された文字列を、前記対応する登録番号に置き換えて前記端末に送信し、前記端末で受信されるメールデータに含まれる前記置き換えられた登録番号をアドレスとして前記端末側辞書から文字列を抽出して、前記メールデータの原文を復元することを特徴とする。
【００１４】
上記の本発明の目的を達成するメールデータの圧縮方法の、第２の態様は、第１の態様において、前記文字列に対応する登録番号への置き換えの際に、置き換えを示す制御記号を前記置き換えられた登録番号に付すことを特徴とする。
【００１５】
上記の本発明の目的を達成するメールデータの圧縮方法の、第３の態様は、第１の態様において、前記センターに置かれる辞書への文字列の登録は、該当の端末宛のメールの発生の際に行い、且つ文字列毎に発生の頻度を記録することを特徴とする。
【００１６】
上記の本発明の目的を達成するメールデータの圧縮方法の、第４の態様は、第２の態様において、前記記録される文字列の所定期間中の発生頻度が所定値以上である対応する登録番号を前記センターから前記端末に送り、前記端末側辞書に保持することを特徴とする。
【００１７】
上記の本発明の目的を達成するメールデータの圧縮方法の、第５の態様は、第１の態様において、前記センターは、前記センターに置かれる辞書の登録の更新を記録し、前記端末かメールの読み出し要求があったときに、前記メールの送信に先立って前記更新された辞書の内容を前記端末に送り、前記センターと端末側辞書の内容を同期させることを特徴とする。
【００１８】
本発明の特徴は、以下に図面に従い説明される発明の実施の形態例から更に明らかになる。
【００１９】
【発明の実施の形態】
以下に本発明の実施の形態例を説明するが、それに先立って本発明の理解を容易とするべく、上記（２）ウェブ（Ｗｅｂ）メールの仕組みについて更に説明する。
【００２０】
図１は、上記（２）ウェブ（Ｗｅｂ）メール方式を適用するメールシステムの構成例を示す図である。
【００２１】
図１において、インターネット１に、携帯通信事業者２とメールサービスを提供しているメールサービス事業者３（携帯通信事業者２と共通である場合もある）が接続されている。
【００２２】
携帯通信事業者２と契約をしている利用者の携帯端末４と携帯通信事業者２とは、通常Ｗｅｂアクセス時と同様のＨＴＴＰ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）インターフェースが使用され、携帯端末４に送られるパケット量による課金（データ転送量による従量課金）が適用される。
【００２３】
そのためにメールサービスを提供しているメールサービス事業者３は、データ転送量を減らし、携帯端末２の利用者が支払う通信料が少なくなる様に様々な工夫をしている。
【００２４】
そのための主要な方法は次のようなものである。
【００２５】
（１）不要文字の除去
メールを読んで理解する上で必須ではないと考えられる文字を削除してから携帯端末２に送る方法である。例えば、次の方法がある。
・改行除去
・不要な空白の除去
・引用部除去（＞  で始まる行を削除）
・指定文字列除去（ユーザーがあらかじめ設定した文字列を削除）
・指定行範囲除去（広告行など本文に無関係の行を削除）
（２）文字列の圧縮
次の様に、意味を理解できる範囲でより短い文字列に置き替えてから端末に送る方法である。
・全角→半角変換（全角のひらがな、カタカナ、英文字、数字を半角文字にすることによりこの部分のデータ量を１／２にする）
・繰り返し文字圧縮（−−−−−などは区切り線と考えられるので、１文字で置き替えてしまう）
（３）ページ記述言語のタグの除去
メールセンター３のサーバーより端末に送られてくるメール本文は、表示のために純テキストではなくページ記述言語（事業者により異なるが、ＣＨＴＭＬ，  ＨＤＭＬなどが使用される）で記述されたものである。これにはフォーマットのために多くのタグが含まれているが、必須ではないタグを見つけ出し削除してから送ることによりデータ量を減らす方法である。
【００２６】
上記の従来方法においては、▲１▼圧縮のための加工によりオリジナルの形状（例えば、改行位置などのレイアウト）が失われてしまうこと、場合によっては情報自体が欠けてしまうことがありうるという課題があった。また、▲２▼さらにデータ量を削減したいと言う要求もあった。
【００２７】
従って、本発明は、上記課題▲１▼を解決し、更に上記▲２▼の要求を満たすことを可能とする新規なメールデータ圧縮方法を提供するものである。
【００２８】
以下に本発明の実施の形態例を説明する。
【００２９】
図２は、本発明のメールデータ圧縮方法が適用されるＪａｖａアプレットによるプログラム実行環境を備えた携帯端末４を使用する場合を説明する図である。なお、以下の説明において、図示を携帯端末４として説明するが、本発明の適用はこれに限定されずにＰＤＡ（Ｐｅｒｓｏｎａｌ  Ｄｉｇｉｔａｌ  ａｓｓｉｓｔａｎｔ：個人向携帯型通信機器），ＰＣ（ｐｅｒｓｏｎａｌ  Ｃｏｍｐｕｔｅｒ）等のメール送受信機能を有するものも当然に含まれるものである。
【００３０】
図２に示す様に、携帯端末４は、図１に示したと同様のインターネット接続環境に配置される。そして、携帯端末４は、センター３からＪａｖａアプリケーションプログラム（ここではＪａｖａアプリと呼ぶことにする）をダウンロードして、それを携帯端末上で実行する機能がある。これにより携帯端末４の機能を自由に拡張することができる。
【００３１】
図３は、本発明にしたがうメールデータ圧縮方法の原理を説明する図である。本発明に従うメールサービスを行うセンター３のサーバーにはサーバプログラム３０により次の機能が備えられる。
・契約された利用者の携帯端末４ごとに辞書（対応表）３２を持ち、その中にフレーズ（単語）とその番号の対応を記録する。
・保存メール３１の本文を走査し、辞書３２に記録されているフレーズがあれば後に説明する短い特殊シーケンスに置き替えることにより圧縮してから携帯端末４に送信する。
【００３２】
一方、携帯端末４は次の機能を持ったＪａｖａアプリをセンター３からダウンロードして、実行する。
・携帯端末４内のデータ領域（エリア）にフレーズ（単語）とその番号の辞書（対応表）４０を持つ。
・前記ダウンロードしたＪａｖａアプリにより、センター３のサーバーから送られてきたメール本文の中に特殊シーケンスがあれば、その番号をキーに対応表４０を探し、対応するフレーズに置き替えてメール本文を復元し、携帯端末４の表示部４１に表示する。
【００３３】
以上の様に、携帯端末４にダウンロードされたＪａｖａアプリとセンター３のサーバーが協調することによりデータ転送量の削減を図る。
【００３４】
なお、図３において、センター３には、辞書３２に対応して辞書３２の更新情報の有無を示す更新フラグ３３が登録されている。従って、端末４からセンター３へのＷＥＢ検索、メールアクセス等の際に、センター３へのアクセスの都度、前記更新フラグ３３を参照して、更新された辞書３２のデータを該当の端末に送る。これにより、センター３に辞書３２と、端末４の辞書は適時に同期される。
【００３５】
図４にセンター３のサーバーの動作フローを示す。図４Ａは、各端末側からのメール受信に対する処理であり、図４Ｂは、受信メールの宛先への配信処理のフローである。また、図４Ｃは、辞書更新処理のフローである。
【００３６】
図４Ａにおいて、センター３のサーバーは、メールを受信すると（ステップＳ１）、受信したメールを図示しないサーバーの対応する宛先ユーザーのメールボックスに保存メール３１として格納する（ステップＳ２）。
【００３７】
次いで、図４Ｂにおいて、携帯端末４から読み出し要求があると（ステップＳ３）、該当の携帯端末４用の更新フラグ３３を参照して、辞書更新情報の有無を判断する（ステップＳ４）。辞書更新情報があれば（ステップＳ４、Ｙｅｓ）、端末４に送信する（ステップＳ５）。
【００３８】
次いで、メールボックスに該当の端末４宛の保存メール３１の有無を判断して（ステップＳ６）、保存メール３１がある場合は（ステップＳ６、Ｙｅｓ）、メール原文を取り出す。
【００３９】
次いで、前処理として、原文をひとまとまりのフレーズ（単語）に区切る（分かち書きと言う）（ステップＳ７）。フレーズ（単語）ごとにカウント処理を行う（ステップＳ８）。
【００４０】
このカウント処理を、図５に示すセンター３における辞書３２の構成により説明する。図５において、辞書３２は、文字列ａ、端末４側の辞書のアドレス番号ｂ及びカウンタ値ｃが対応して登録されている。
【００４１】
かかる辞書３２を検索し、登録されたフレーズがあれば、対応のカウンタ値ｃの値を該当週（今週）の欄の数値を歩進する。
【００４２】
図５の例では、“本日”のフレーズは、今週において、１００回の発生頻度であることがわかる。なお、カウンタ値ｃは、実施例として５週前までの状態が保存されている。
【００４３】
図４に戻り、辞書３２を検索して登録済みのフレーズである場合は、例として「＠＋番号」で置き替えて圧縮する（ステップＳ９）。図５の例では、“次回”のフレーズは、“＠１”に置き換えられる。“次回”は、４バイトのデータ量であるのに対し、“＠１”は、２バイトであり、データ量は半分に圧縮されている。
【００４４】
次いで、このように圧縮されたメール（圧縮済メール）をメール受信要求のあった携帯端末４に送信する（ステップＳ１０）。
【００４５】
図４Ｃは、センター３における辞書更新処理のフローである。一定期間ごとに辞書を起動して（ステップＳ１１）、辞書更新処理を行う（ステップＳ１２）。
【００４６】
辞書更新は、一定期間（例えば、一週間単位）ごとにセンター３側において実行される。その内容は、実施例として次のようである。
センター３側の辞書３２に登録されている全て（端末４側に登録されていないものを含む）の文字列ａについて、カウンタ値ｃを評価する（例えば、最近５週間の出現頻度の合計値）。
【００４７】
次いで、評価値の高いものから（例えば、２５６個を）端末４側の辞書に登録する文字列としてピックアップ（選択）する。図５において、選択された２５６種の文字列ａに対し、番号ｂが付されている。
【００４８】
更に、現在登録されている文字列から変更がある場合、次の様な更新情報を作成する。
【００４９】
・削除すべき文字列のアドレス
・登録すべき文字列とそのアドレス
この様な、更新情報がある場合、次回接続時にそれを端末４に送信する様に辞書３２と対応付けて更新フラグ３３を立てることにより明示する。
【００５０】
更に、辞書更新の内容として、センター３側の辞書３２の使用状況をチェックし、一定基準（例えば、辞書３２要領の１０％）以上の空きがなければ次の処理を行い、空き領域を作成する。
【００５１】
センター３側の辞書３２に登録されていて、且つ端末４側に登録されていない文字列についてカウンタ値ｃを評価する。例えば、最近５週間の出現頻度の合計値が小さいもの、今週、先週のカウンタ値が０もしくは非常に小さいもの等を判定する。このような評価により、評価の低いものから順に、必要なだけ削除することにより空き領域を確保することが可能である。図６は、端末４におけるＪａｖａアプリによる動作を示すフローである。既にメール送受信に必要なＪａｖａアプリがセンター３からダウンロードされているとして以下を説明する。
【００５２】
センター３にメールの読み出し要求を送ると（ステップＳ２０）、先に図４Ｂで説明した様に、メールが受信されている場合には、圧縮済メールがセンター３から送られる。
【００５３】
従って、メールの読み出しを要求し（ステップＳ２０）、圧縮済メールがセンター３から送信されたか否かを判断し（ステップＳ２１）、送信されていれば（ステップＳ２１、Ｙｅｓ）、これを受信する（ステップＳ２２）。
【００５４】
次いで、受信した圧縮済メールを走査し、特殊シーケンス（たとえば、＠＋番号）があれば圧縮されたフレーズと判断する。そして、先にセンター３からダウンロードした辞書４０を検索して対応する元のフレーズを復元する（ステップＳ２３）。
【００５５】
このように復元したメールは、端末４の表示部４２に通常のメールと同様にメールの内容を表示することが出来る（ステップＳ２４）。
【００５６】
図７は、センター３からダウンロードした辞書４０の構成を示す図である。センター３側の辞書３２における選択されたフレーズの番号ｂ（図５参照）をアドレスとして、対応するフレーズ（文字列）が保存されている。
【００５７】
次に上記構成のセンター３及び端末４の構成及び処理に基づく、送信メールの実施例を説明する。
【００５８】
図８は、センター３側の処理とこれに対応する辞書３２の状態を示す図である。また、図９は、端末４側の処理とこれに対応する辞書４０の状態を示す図である。更に、図１０は、センター３側の処理と端末４側の処理の流れを示すフローである。
【００５９】
これらに基づいて、実施例動作を説明する。
【００６０】
今、送信すべきメールの原文を「次回もまたよろしくお願いします。」とする。この場合のデータ量は、１６文字×２バイト＝３２バイトである。
【００６１】
図１０において、センター３は、「次回もまたよろしくお願いします。」という３２バイトのメール原文ａを“次回”、“も”、“また”、“よろしく”、“お願い”、“します。”というように複数のフレーズに分かち書きｂに変換する（図８Ａ参照）。
【００６２】
ついで、分かち書きしたフレーズごとに辞書３２を検索する。この例では、図８Ｂに示すように“次回”、“お願い”と“よろしく”の３フレーズが辞書に登録されている。
【００６３】
次いで、辞書に登録されている３フレーズを圧縮記号（例として＠）と辞書における登録番号により構成される記号に圧縮変換ｃされる。
【００６４】
従って、送信文ｄは、「＠１もまた＠５３＠２します。」となる。この場合、データ量は、２０バイトになり、１２バイト分データ圧縮されている。
【００６５】
一方、図１０において、端末４側では、受信文ｆとして送信文ｄと同じ「＠１もまた＠５３＠２します。」が受信される（図９Ａ参照）。従って、受信文において、圧縮記号＠とそれに続く番号を識別して、番号をアドレスとして辞書４０を検索する。
【００６６】
これにより圧縮記号＠に続く番号に対応するアドレスから原文フレーズが導かれる（図９Ｂ参照）。従って、受信文ｅを原文フレーズに置き換え挿入して原文を復元する。これにより復元した原文ｆ「次回もまたよろしくお願いします。」を得ることができる。
【００６７】
【発明の効果】
上記に実施の形態例に従い説明したように、本発明により、リアルタイム性及び、経済性を実現するメールデータの圧縮方法及びこれを適用するウェブ（Ｗｅｂ）メールシステムを提供可能である。
【図面の簡単な説明】
【図１】Ｗｅｂメール型携帯メールサービスの図解
【図２】Ｊａｖａ実行環境を備えた携帯端末４の動作の図解
【図３】本発明の動作原理を示す図
【図４】センター３のサーバーのプログラムの動作フロー
【図５】センター３における辞書３２の構成例を示す図である。
【図６】端末４におけるＪａｖａアプリによる動作を示すフローである。
【図７】センター３からダウンロードした辞書４０の構成を示す図である。
【図８】センター３側の処理とこれに対応する辞書３２の状態を示す図である。
【図９】端末４側の処理とこれに対応する辞書４０の状態を示す図である。
【図１０】センター３側の処理と端末４側の処理の流れを示すフローである。
【符号の説明】
１  インターネット
２  携帯事業者
３  センター
４  端末
３０  サーバープログラム
３１  保存メール
３２  センター側辞書
３３  更新フラグ
４０  端末側辞書
【図１】
2004274489.tif 000003
【図２】
2004274489.tif 000004
【図３】
2004274489.tif 000005
【図４】
2004274489.tif 000006
【図５】
2004274489.tif 000007
【図６】
2004274489.tif 000008
【図７】
2004274489.tif 000009
【図８】
2004274489.tif 000010
【図９】
2004274489.tif 000011
【図１０】
2004274489.tif 000012