(57)【要約】  第１通信プロトコルを使用する第１ユーザ装置；第１通信プロトコルとは異なる第２通信プロトコルを使用する第２ユーザ装置；および第１ユーザ装置および第２ユーザ装置と作動的に連絡しているサーバであって、第１通信プロトコルを第２通信プロトコルに変換するプロセッサを含むサーバを備えた、通信ネットワークシステム。【選択図】  図１
2008529325.tif 000002
【特許請求の範囲】
【請求項１】
第１ヘッダが付加されたデータの送信に第１通信プロトコルを使用する第１ユーザ装置；
データの送信に前記第１通信プロトコルとは異なる第２通信プロトコルを使用する第２ユーザ装置；および
前記第１ユーザ装置および前記第２ユーザ装置と作動的に連絡しているサーバであって、第１ヘッダおよび第１通信プロトコルと互換可能なデータ内容の少なくとも一部を使用して、第２通信プロトコルと互換可能な第２ヘッダを作成するプロセッサを含むサーバ
を備えた、通信ネットワークシステム。
【請求項２】
前記第１通信プロトコルは、ＨＴＴＰ、ＴＣＰ／ＩＰ、ＳＭＳ、ＭＭＳ、ＩＭＳ、ＷＡＰ、ＧＳＭ、ＣＤＭＡ、ｉＤＥＮ、ＷＣＤＭＡ、３Ｇまたは４Ｇから成る群から選択される、請求項１に記載の通信ネットワークシステム。
【請求項３】
前記第２通信プロトコルは、ＨＴＴＰ、ＴＣＰ／ＩＰ、ＳＭＳ、ＭＭＳ、ＩＭＳ、ＷＡＰ、ＧＳＭ、ＣＤＭＡ、ｉＤＥＮ、ＷＣＤＭＡ、３Ｇまたは４Ｇから成る群から選択される、請求項１に記載の通信ネットワークシステム。
【請求項４】
ユーザ装置にインストールされたソフトウェアアプリケーションを起動させることのできるデータの送信に第１通信プロトコルを使用する第１ユーザ装置；
データの受信に第２通信プロトコルを使用する第２ユーザ装置；および
前記第１ユーザ装置および前記第２ユーザ装置と作動的に連絡しているサーバであって、第１通信プロトコルによる少なくともデータヘッダを第２通信プロトコルによるデータヘッダに変換することによって第１通信プロトコルを第２通信プロトコルに変換するプロセッサを含むサーバ
を備えた、通信ネットワークシステム。
【請求項５】
データはＳＭＳメッセージ内に包含される、請求項４に記載の通信ネットワークシステム。
【請求項６】
さらに複数の通信プロトコルを含み、そこから前記第１通信プロトコルおよび前記第２通信プロトコルが選択される、請求項１または４に記載の通信ネットワークシステム。
【請求項７】
前記サーバは複数の通信プロトコルのいずれか１つを、他の複数の通信プロトコルのいずれかに変換する、請求項６に記載の通信ネットワークシステム。
【請求項８】
第１ユーザ装置から第２ユーザ装置にデータを送信するステップであって、前記第１ユーザ装置が前記第２ユーザ装置の第２通信プロトコルとは異なる第１通信プロトコルを使用して成るステップ；
前記第２ユーザ装置の前記第２通信プロトコルを決定するステップ；および
第１通信プロトコルのヘッダおよびデータの少なくとも一部の内容を第２通信プロトコルのヘッダと交換することによって、前記第１通信プロトコルから前記第２ユーザ装置の前記決定された第２通信プロトコルに前記データを変換するステップ
を含む、データを変換する方法。
【請求項９】
前記第１通信プロトコルは、ＨＴＴＰ、ＴＣＰ／ＩＰ、ＳＭＳ、ＭＭＳ、ＩＭＳ、ＷＡＰ、ＧＳＭ、ＣＤＭＡ、ｉＤＥＮ、ＷＣＤＭＡ、３Ｇまたは４Ｇを含む群から選択される、請求項８に記載の方法。
【請求項１０】
前記第２通信プロトコルは、ＨＴＴＰ、ＴＣＰ／ＩＰ、ＳＭＳ、ＭＭＳ、ＩＭＳ、ＷＡＰ、ＧＳＭ、ＣＤＭＡ、ｉＤＥＮ、ＷＣＤＭＡ、３Ｇまたは４Ｇを含む群から選択される、請求項８に記載の方法。
【請求項１１】
通信ネットワークシステムのユーザを識別するステップ；
前記通信ネットワークシステムの少なくとも１人のユーザから構成されるが全ユーザには満たないユーザグループを作成するステップ；
少なくとも１つのアイコンを前記グループに割り当てるステップ；および
前記少なくとも１つのアイコンを前記ユーザグループに提供するステップ
を含む、アイコニック言語の少なくとも１つのアイコンを通信ネットワークシステムのユーザに提供する方法。
【請求項１２】
少なくとも１つのアイコニック言語メッセージを送信するステップ；
少なくとも１つのアイコニック言語メッセージをデータベースに格納するステップ；
前記少なくとも１つのアイコニック言語メッセージを分析するステップ；および
前記分析に基づいて統計を編集するステップ
を含む、アイコニック言語通信ネットワークシステムの統計を編集する方法。
【請求項１３】
前記分析ステップは、前記アイコニック言語メッセージ内で少なくとも１つのアイコンの文脈を決定するステップを含む、請求項１２に記載の方法。
【請求項１４】
前記分析ステップは、前記アイコニック言語メッセージ内の少なくとも１つのアイコンの使用頻度を決定することを含む、請求項１２に記載の方法。
【請求項１５】
少なくとも１つのメッセージ要素から構成されるメッセージを作成するステップ；
少なくとも１つのメッセージ要素を通信ネットワークシステムによって使用されている容認できるフォーマットで配置するステップ；
前記通信ネットワークシステムによって使用されている少なくとも１つのより効率的なフォーマットの適用可能性について少なくとも１つのメッセージ要素を分析するステップ；および
可能な場合、前記容認できるフォーマットを前記少なくとも１つのより効率的なフォーマットで置換するステップ
を含む、通信ネットワークシステムのメッセージサイズを最適化する方法。
【請求項１６】
前記通信ネットワークシステムによって使用されている前記容認できるフォーマットは、アイコン−１６またはテキスト−１６である、請求項１５に記載の方法。
【請求項１７】
前記少なくとも１つのより効率的なフォーマットは、１文字または１アイコン当たり１６ビット未満であるが、１ビットより大きい、請求項１５に記載の方法。
【請求項１８】
ログファイルを分析してユーザ装置の最も最近のポーリング時間を決定するステップ；
最も最近のポーリング時間と現在の時間との間の時間差を推定するステップ；および
前記推定に基づいてソフトウェアアプリケーションの動作状態を分類するステップ
を含む、ユーザ装置にインストールされたソフトウェアアプリケーションクライアントの動作状態を決定するための方法。
【請求項１９】
前記時間差は予め定められた量より大きい場合、動作状態は閉じていると分類される、請求項１８に記載の方法。
【請求項２０】
前記時間差が予め定められた量より小さい場合、動作状態は開いていると分類される、請求項１８に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願
本願は、Ｙｏａｖ  Ｌｏｒｃｈによって発明された２００５年１月１８日出願の米国特許仮出願第６０／６４４０２１号の米国特許法第１１９条（ｅ）項に基づく特典を主張し、かつ２００５年１月１６日出願の「Ｍｅｔｈｏｄ  ａｎｄ  Ｓｙｓｔｅｍ  ｆｏｒ  Ｉｃｏｎｉｃ  Ｌａｎｇｕａｇｅ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ」、と称するイスラエル出願第１６６３２２号からの優先権をも主張し、それらの開示内容を参照によって本書に援用する。本願はまた、ＰＣＴのイスラエル受理官庁に本願と同時に出願した「Ｉｃｏｎｉｃ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ」と称する出願（代理人整理番号５２４／０４９８３）、およびイスラエル特許庁に本書と同時に出願した「Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ  Ｎｅｔｗｏｒｋ  Ｓｙｓｔｅｍ  ａｎｄ  Ｍｅｔｈｏｄｓ  ｆｏｒ  Ｕｓｉｎｇ  Ｓａｍｅ」と称する出願（代理人整理番号５２４／０５０７７）にも関連し、それらの開示内容を参照によって本書に援用する。
【０００２】
技術分野
本発明は通信の分野に関し、さらに詳しくは、通信ネットワークシステムおよびそれを使用するための方法に関する。
【背景技術】
【０００３】
発明の背景
過去数年間に、技術の進歩は、かつてなかった通信能力を人々にもたらした。例えば、セルラ通信ネットワーク、インターネット、および他の通信メディアの出現は、１人の人から他の人へ情報を伝達する迅速かつ便利な手段を生み出す。
【０００４】
しかし、通信能力の向上をもたらす複数の競合技術が存在し、多くの場合、各技術はその技術を実行するための複数の競合フォーマットおよび／またはプロトコルを有する。その結果、これらのシステム、装置、フォーマット、プロトコル、および／またはネットワークの相互運用性は重大な関心事である。
【０００５】
加えて、これらの技術の中には、入力能力が限定された装置を利用するものがあり、それは次にこれらの装置を介する通信の効率を低減する。電子メッセージングは、効率の低下がユーザにとって負担となり得る１つの領域である。ある種の電子メッセージング、例えばＳＭＳは、略実時間で動作する。典型的なメッセージは複数のテキスト文字を含む。しかし、これらのメッセージはしばしば、通常１２個のキーしか持たないセルラ電話機等の、入力能力が限定された装置を使用して送信される。複数のキーストロークを入力して各テキスト文字を生成すると、メッセージへの応答の遅延を導くことがある。これは次に、ユーザが能力の限定された入力装置で文字を入力するため、受信者をインスタントメッセージの受信時に長く待たせるかもしれない。略実時間通信環境では、そのような遅延は容認できないかもしれない。さらに、これらの新しい通信技術はいずれも、言語障壁を越える通信には特に有用でない。
【０００６】
米国特許出願第２００２／０１４０７３２号は、アイコニック言語通信ツールのための方法、システム、および記憶媒体を開示しており、その開示内容を参照によって本書に援用する。該システムは、ユーザのアイコン選択を受け取るためのアイコニック言語通信テンプレートを生成し、アイコニック言語通信テンプレートを提示し、かつアイコニック言語通信テンプレートからユーザのアイコン選択を受け取るためのホストシステムを含む。ネットワークおよびデータベースはホストシステムと交信する。
【０００７】
米国公開特許出願第２００２／０１８４３０９号は、ユーザが電子メッセージのために入力するように要求される入力の量を低減するためのシステムおよび方法を記載しており、その開示内容を参照によって本書に援用する。ユーザーが、電子メッセージングセッションに携わる彼らの能力を変更したとき、例えば彼らがオフラインに移行したときに、他のユーザにコマンドを送信することができる。このコマンドは、書き言葉には通常発生しない文字シーケンスの形を取ることができ、それはネットワーク装置によって解釈され、オフラインに移行したユーザに関連付けられるアイコンのディスプレイを変化させる。
【発明の開示】
【０００８】
本発明の一部の例示的実施形態の態様は、サービス、装置の種類、フォーマット、および／または通信ネットワーク等の複数のプロトコルで相互運用可能に使用することのできる通信ネットワークシステムを提供することに関する。本発明の一部の例示的実施形態では、第１プロトコルのデータの送信機は、データを第２プロトコルで受信機によって受信させる。本発明の例示的実施形態では、第１プロトコルで送信されたデータは、第１ヘッダおよびデータの内容の少なくとも一部分を使用することによって、通信ネットワークシステムによって第２プロトコルに変換される。任意選択的に、第１ヘッダおよびデータの少なくとも一部分は、第２プロトコルと互換可能なデータのための第２ヘッダを構成するために使用される。本発明の一部の例示的実施形態では、通信ネットワークシステムはアイコニック言語を送信するために使用される。本発明の一部の例示的実施形態では、通信ネットワークシステムは、受信者のユーザ装置上のソフトウェアアプリケーションを起動させることのできるデータおよび／またはメッセージを送信するために使用される。任意選択的に、メッセージの送信は、少なくとも何らかのＳＭＳメッセージを用いて行なわれる。
【０００９】
本発明の一部の例示的実施形態の態様は、少なくとも１グループのアイコニック言語アイコンを、そのグループのアイコニック言語アイコンに関連付けられる少なくとも１つのユーザグループに提供する、通信ネットワークシステムを提供することに関する。本発明の一部の例示的実施形態では、単一のアイコンが２グループ以上のアイコニック言語アイコンに関連付けられ、それにより２つ以上のユーザグループにそれを同時に提供することが可能になる。本発明の一部の例示的実施形態では、１グループのアイコニック言語アイコンが２つ以上のユーザグループに関連付けられ、それにより該グループのアイコニック言語アイコンを２つ以上のユーザグループに同時に提供することが可能になる。任意選択的に、１グループのユーザが２グループ以上のアイコニック言語アイコンに関連付けられ、それにより該グループのユーザに２グループ以上のアイコニック言語アイコンが提供される。本発明の一部の例示的実施形態では、データはサーバから少なくとも１グループのユーザに提供される。任意選択的に、データはユーザから少なくとも１グループのユーザに提供される。任意選択的に、データを提供するユーザは、少なくとも１つのユーザグループのメンバである。
【００１０】
本発明の一部の例示的実施形態の態様は、少なくとも部分的にアイコニック言語でありシステム内で送信されたメッセージの統計分析を実行する、通信ネットワークシステムを提供することに関する。本発明の一部の例示的実施形態では、メッセージが分析されて、アイコン使用の頻度および／または文脈が評価される。任意選択的に、メッセージに対する分析が行なわれて、特定のアイコンが他のアイコンと共にどれだけ多く、かつ／またはどのような関係で使用されているかが決定される。本発明の一部の例示的実施形態では、統計分析は、周期的にではなく、継続的に実行される。任意選択的に分析は、使用されるフォントサイズ、使用されるフォント、使用される色、および／または使用されるグラフィックス等の、ユーザのメッセージ関連の嗜好について行なわれる。本発明の一部の例示的実施形態では、統計分析は、どの個別アイコン、アイコングループ、および／または他の嗜好をデフォルトによってユーザに提示し、かつ／またはユーザによる使用のために選択可能とするかを決定するために使用される。任意選択的に、統計分析は、どのメッセージ内容がすでに入力されたかに基づいて、これらから入力されるメッセージを予測するために使用される。
【００１１】
本発明の一部の例示的実施形態の態様は、メッセージの内容に基づいてメッセージサイズを最適化する通信ネットワークシステムを提供することに関する。任意選択的に、メッセージはアプリケーションデータから構成される。任意選択的に、メッセージはＳＭＳを介して送信される。本発明の一部の例示的実施形態では、内容項目は、全体的なメッセージサイズを最適化するために、それらの最小所要サイズに縮小される。任意選択的に、通信ネットワークシステムはメッセージ内容を分析し、受信機に送信する前にメッセージサイズを自動的に最適化する。
【００１２】
本発明の一部の例示的実施形態の態様は、ユーザ装置にインストールされたソフトウェアアプリケーションクライアントが動作中であるか否かを、通信ネットワークシステムが決定するための方法に関する。本発明の例示的実施形態では、動作中のソフトウェアアプリケーションクライアントは一般的に、ユーザ装置上で開いているクライアントであるとみなされ、非動作中のソフトウェアアプリケーションクライアントは、ユーザ装置上で閉じているクライアントであるとみなされる。任意選択的に、ソフトウェアアプリケーションクライアントは、ユーザ装置がサーバを能動的にポーリングしている場合に、開いているとみなされる。任意選択的に、ソフトウェアアプリケーションクライアントは、ユーザ装置が予め定められた期間内にサーバをポーリングした場合に、開いているとみなされる。任意選択的に、ソフトウェアアプリケーションクライアントは、ユーザ装置が少なくとも予め定められた期間、サーバにポーリングしなかった場合、閉じているとみなされる。本発明の一部の例示的実施形態では、ソフトウェアアプリケーションクライアントは、クライアントが開いているかあるいは閉じているという信号をサーバに送信する。
【００１３】
したがって、本発明の例示的実施形態では、第１ヘッダが付加されたデータの送信に第１通信プロトコルを使用する第１ユーザ装置と、データの送信に前記第１通信プロトコルとは異なる第２通信プロトコルを使用する第２ユーザ装置と、前記第１ユーザ装置および前記第２ユーザ装置と作動的に連絡しているサーバであって、第１ヘッダおよび第１通信プロトコルと互換可能なデータ内容の少なくとも一部を使用して、第２通信プロトコルと互換可能な第２ヘッダを作成するプロセッサを含むサーバとを備えた、通信ネットワークシステムを提供する。本発明の一部の例示的実施形態では、システムはさらに複数の通信プロトコルを含み、そこから前記第１通信プロトコルおよび前記第２通信プロトコルが選択される。任意選択的に、第１通信プロトコルは、ＨＴＴＰ、ＴＣＰ／ＩＰ、ＳＭＳ、ＭＭＳ、ＩＭＳ、ＷＡＰ、ＧＳＭ、ＣＤＭＡ、ｉＤＥＮ、ＷＣＤＭＡ、３Ｇまたは４Ｇから成る群から選択される。任意選択的に、第２通信プロトコルは、ＨＴＴＰ、ＴＣＰ／ＩＰ、ＳＭＳ、ＭＭＳ、ＩＭＳ、ＷＡＰ、ＧＳＭ、ＣＤＭＡ、ｉＤＥＮ、ＷＣＤＭＡ、３Ｇまたは４Ｇから成る群から選択される。
【００１４】
したがって、本発明の例示的実施形態では、ユーザ装置にインストールされたソフトウェアアプリケーションを起動させることのできるデータの送信に第１通信プロトコルを使用する第１ユーザ装置と、データの受信に第２通信プロトコルを使用する第２ユーザ装置と、第１ユーザ装置および第２ユーザ装置と作動的に連絡しているサーバであって、第１通信プロトコルによる少なくともデータヘッダを第２通信プロトコルによるデータヘッダに変換することによって第１通信プロトコルを第２通信プロトコルに変換するプロセッサを含むサーバとを備えた、通信ネットワークシステムを提供する。任意選択的に、データはＳＭＳメッセージ内に包含される。本発明の一部の例示的実施形態では、システムはさらに複数の通信プロトコルを含み、そこから第１通信プロトコルおよび第２通信プロトコルが選択される。任意選択的に、サーバは複数の通信プロトコルのいずれか１つを、他の複数の通信プロトコルのいずれかに変換する。
【００１５】
したがって、本発明の例示的実施形態では、第１ユーザ装置から第２ユーザ装置にデータを送信するステップであって、第１ユーザ装置が第２ユーザ装置の第２通信プロトコルとは異なる第１通信プロトコルを使用して成るステップと、第２ユーザ装置の第２通信プロトコルを決定するステップと、第１通信プロトコルのヘッダおよびデータの少なくとも一部の内容を第２通信プロトコルのヘッダと交換することによって、第１通信プロトコルから第２ユーザ装置の決定された第２通信プロトコルにデータを変換するステップとを含む、データを変換する方法を提供する。任意選択的に、第１通信プロトコルは、ＨＴＴＰ、ＴＣＰ／ＩＰ、ＳＭＳ、ＭＭＳ、ＩＭＳ、ＷＡＰ、ＧＳＭ、ＣＤＭＡ、ｉＤＥＮ、ＷＣＤＭＡ、３Ｇまたは４Ｇを含む群から選択される。任意選択的に、第２通信プロトコルは、ＨＴＴＰ、ＴＣＰ／ＩＰ、ＳＭＳ、ＭＭＳ、ＩＭＳ、ＷＡＰ、ＧＳＭ、ＣＤＭＡ、ｉＤＥＮ、ＷＣＤＭＡ、３Ｇまたは４Ｇを含む群から選択される。
【００１６】
したがって、本発明の例示的実施形態では、通信ネットワークシステムのユーザを識別するステップと、通信ネットワークシステムの少なくとも１人のユーザから構成されるが全ユーザには満たないユーザグループを作成するステップと、少なくとも１つのアイコンをグループに割り当てるステップと、少なくとも１つのアイコンをユーザグループに提供するステップとを含む、アイコニック言語の少なくとも１つのアイコンを通信ネットワークシステムのユーザに提供する方法を提供する。
【００１７】
したがって、本発明の例示的実施形態では、少なくとも１つのアイコニック言語メッセージを送信するステップと、少なくとも１つのアイコニック言語メッセージをデータベースに格納するステップと、少なくとも１つのアイコニック言語メッセージを分析するステップと、分析に基づいて統計を編集するステップとを含む、アイコニック言語通信ネットワークシステムの統計を編集する方法を提供する。任意選択的に、分析ステップは、アイコニック言語メッセージ内で少なくとも１つのアイコンの文脈を決定するステップを含む。任意選択的に、分析ステップは、アイコニック言語メッセージ内の少なくとも１つのアイコンの使用頻度を決定することを含む。
【００１８】
したがって、本発明の例示的実施形態では、少なくとも１つのメッセージ要素から構成されるメッセージを作成するステップと、少なくとも１つのメッセージ要素を通信ネットワークシステムによって使用されている容認できるフォーマットで配置するステップと、通信ネットワークシステムによって使用されている少なくとも１つのより効率的なフォーマットの適用可能性について少なくとも１つのメッセージ要素を分析するステップと、可能な場合、前記容認できるフォーマットを前記少なくとも１つのより効率的なフォーマットで置換するステップとを含む、通信ネットワークシステムのメッセージサイズを最適化する方法を提供する。任意選択的に、通信ネットワークシステムによって使用されている容認できるフォーマットは、アイコン−１６またはテキスト−１６である。任意選択的に、少なくとも１つのより効率的なフォーマットは、１文字または１アイコン当たり１６ビット未満であるが、１ビットより大きい。
【００１９】
したがって、本発明の例示的実施形態では、ログファイルを分析してユーザ装置の最も最近のポーリング時間を決定するステップと、最も最近のポーリング時間と現在の時間との間の時間差を推定するステップと、推定に基づいてソフトウェアアプリケーションの動作状態を分類するステップとを含む、ユーザ装置にインストールされたソフトウェアアプリケーションクライアントの動作状態を決定するための方法を提供する。任意選択的に、時間差は予め定められた量より大きい場合、動作状態は閉じていると分類される。任意選択的に、時間差が予め定められた量より小さい場合、動作状態は開いていると分類される。
【００２０】
図面の簡単な記述
本発明の例示的な非限定的実施形態は、以下の説明において、本明細書に添付される図面を参照しながら記載される。図中、２つ以上の図に現れる同一および類似の構造、要素またはその部分は、一般に、それらが現れる図において同じまたは類似の参照番号で標識されている。図において示される構成要素および特徴の寸法は、主に便宜上および提示の明確さのために選択されており、必ずしも一定の縮小比で示していない。
図１は、本発明の例示的実施形態に係る、通信ネットワークシステムの構成要素を表わすブロック図である。
図２は、本発明の例示的実施形態に係る、通信ネットワークシステムのサーバ装置を表わすブロック図である。
図３は、本発明の例示的実施形態に係る、変換プロセスを表わすフローチャートである。
図４は、本発明の例示的実施形態に係る、ＭＩＤＰ２および幾らかのＢＲＥＷプロトコルの場合のデータ送信方法を表わすフローチャートである。
図５は、本発明の例示的実施形態に係る、ＭＩＤＰ１および幾らかのＢＲＥＷプロトコルの場合のデータ送信方法を表わすフローチャートである。
図６は、本発明の例示的実施形態に係る、メッセージサイズ最適化方法を表わすフローチャートである。
図７は、本発明の例示的実施形態に係る、メッセージの符号化方法を表わすフローチャートである。
図８は、本発明の例示的実施形態に係る、通信ネットワークシステムの使用方法を表わすフローチャートである。
【発明を実施するための最良の形態】
【００２１】
例示的通信ネットワークシステム
本発明の例示的実施形態では、任意選択的に既存の通信ネットワークと融合させることのできる通信ネットワークシステム１００（図１に示す）を提供する。任意選択的に、通信ネットワークシステム１００は独立型システムである。本発明の一部の例示的実施形態では、通信ネットワークシステム１００は、通信ネットワークの効率、簡便性、および／または有用性の向上を可能にする、種々のタスクを実行することができる。例えば、本発明の一部の例示的実施形態では、通信ネットワークシステム１００は、情報を受信側の第２ユーザ装置で使用可能にするために、情報を送信側の第１ユーザ装置の第１プロトコルおよび／またはフォーマットから第２プロトコルおよび／またはフォーマットに変換する（図３に示す）。本発明の一部の例示的実施形態では、プロトコルはＨＴＴＰ、ＴＣＰ／ＩＰ、ＳＭＳ、ＭＭＳ、ＩＭＳ、ＷＡＰ、ＧＳＭ、ＣＤＭＡ、ｉＤＥＮ、ＷＣＤＭＡ、３Ｇおよび／または４Ｇを含む。任意選択的に、本書に記載する通り、より多くのプロトコルを含む。
【００２２】
図１を参照すると、本発明の例示的実施形態に係る通信ネットワークシステム１００の構成要素を表わすブロック図が示されている。本発明の一部の例示的実施形態では、通信ネットワークシステム１００は少なくとも１つのサーバ１０２を備える。サーバ１０２については、図２に関連してさらに詳しく述べるが、本発明の一部の例示的実施形態では、サーバ１０２は、通信ネットワークの効率、簡便性、および／または有用性を高めることに関連する少なくとも幾らかのタスクを実行することを理解されたい。サーバ１０２は、本発明の一部の例示的実施形態に係るサービスプロバイダ１０４と作動的に連絡している。サービスプロバイダ１０４は任意選択的に、通信および／またはデータ送信サービスをユーザ装置１０６に提供するいずれかのエンティティである。ユーザ装置１０６は任意選択的に、通信ネットワークでデータの受信および／または送信が可能である、セルラ電話機、パーソナルデータアシスタント、および／またはコンピュータ等のいずれかの装置である。例えば携帯電話会社のＯｒａｎｇｅ（登録商標）（フランスおよびイスラエル、ＧＳＭプロトコル）またはＶｅｒｉｚｏｎ（登録商標）（米国、ＣＤＭＡプロトコル）は、サービスプロバイダとみなされる。ケーブルおよびインターネットサービスのプロバイダであるＣｏｍｃａｓｔ（登録商標）（米国）もまた、サービスプロバイダとみなされる。本発明の一部の例示的実施形態では、個々のサーバは特定のサービスプロバイダに関連付けられる。任意選択的に、個々のサーバは複数のサービスプロバイダに関連付けられる。加えて、サーバは任意選択的にサービスプロバイダ１０４によって分類されず、例えばサーバは、本発明の一部の例示的実施形態では、地理によって分類される。任意選択的に、複数のサーバが単一のサービスプロバイダ１０４に関連付けられる。
【００２３】
簡単に、通信ネットワークシステム１００の例示的使用について説明する。より詳細な説明は、図８に関連して下述する。本発明の例示的実施形態では、ユーザ装置１０６は、データを第２ユーザ装置１０６’に送信するように動作する。本発明の一部の例示的実施形態では、これは、ユーザ装置１０６がデータをユーザ装置１０６に関連付けられるサービスプロバイダ１０４に送信することによって達成される。この段階で、サービスプロバイダ１０４は任意選択的に、サーバ１０２がデータに操作を実行して第２ユーザ装置１０６’でのその有用性を確認するように、伝送されたデータをサーバ１０２に送信する。例えば、第２ユーザ装置１０６’が関連付けられる第２サービスプロバイダ１０４’が、第１サービスプロバイダ１０４とは異なる通信プロトコルを使用する場合、サーバ１０２はデータを、第２サービスプロバイダ１０４’と互換可能なプロトコルに変換する。任意選択的に、サービスプロバイダ１０４から送信されたデータは最初に第２サービスプロバイダ１０４’に送られ、データに対して操作を実行してそれを第２ユーザ装置１０６’に使用可能にするために、サービスプロバイダ１０４’に関連付けられた第２サーバ１０２’に送られる。本発明の例示的実施形態では、第２サービスプロバイダ１０４’は、使用可能なデータを配信のために第２ユーザ装置１０６’に転送する。本発明の一部の例示的実施形態では、第２サービスプロバイダ１０４’は、受信者によるその後の検索のために、使用可能なデータを格納する。
【００２４】
本発明の一部の例示的実施形態では、第１ユーザ装置１０６および第２ユーザ装置１０６’は同一サービスプロバイダを使用し、かつ／または、そうでなくても作動的に互換可能であり、したがって、変換は必要でない場合があることに注目されたい。本発明の一部の例示的実施形態では、たとえ第１ユーザ装置１０６および第２ユーザ装置１０６’が同一サービスプロバイダを使用していても、例えば、第１ユーザ装置１０６がＭＩＤＰ２を使用し、第２ユーザ装置１０６’がＭＩＤＰ１（ＭＩＤＰは下で説明する）を使用している場合には、変換が必要である。しかし、サーバ１０２は依然として、任意選択的にデータに対し、第２ユーザ装置の技術的能力の検出、アップローディングおよび／またはアップグレーディング、ユーザ装置、データ最適化、統計分析、課金、メッセージアーカイビング、データ符号化および類似物をはじめとする操作を実行することができる。本発明の一部の例示的実施形態では、サーバ１０２、１０２’は、それらの間の直接の通信を可能にするために、作動的に接続される。
【００２５】
本発明の一部の例示的実施形態では、サーバの機能は複数のサーバの間に分散される。サーバ１０２、またはサーバ１０２によって代表されるサーバのクラスタは、全ての場所の全てのユーザにサービスを提供するように集中化することができ、あるいは分散アーキテクチャを使用して様々な地理的位置に配置することができることに注目されたい。分散サーバを使用する本発明の一部の例示的実施形態では、各地理的位置サーバは、同一領域の他のユーザと通信するユーザを取り扱う。本発明の一部の例示的実施形態では、地理的位置の外にいるユーザとの通信は、１つの地理的位置サーバが別の地理的位置サーバと連絡することによって行なわれる。本発明の例示的実施形態では、ユーザは、識別子、例えば彼らの電話番号のプレフィックスを使用することによって、異なるサーバに割り当てられる。
【００２６】
本発明の例示的実施形態では、通信ネットワークシステム１００は、ＳＭＳを介して送信できるデータを送信するために使用される。任意選択的に、データはアイコニック言語に関係する。任意選択的に、データはゲーミング（ｇａｍｉｎｇ）および／または娯楽に関連する。任意選択的に、データは撮像および／またはグラフィックスに関係する。任意選択的に、データは事実上テキストである。任意選択的に、データはオーディオおよび／または音楽関係である。
【００２７】
本発明の例示的実施形態では、通信ネットワークシステム１００での通信は、その構成要素のいずれかから始まる。例えば、通信は任意選択的にユーザ、サービスプロバイダ、および／またはサーバから始まる。
【００２８】
例示的サーバ
図２を参照すると、本発明の例示的実施形態に係る、サーバ１０２の例示的機能アーキテクチャを表わすブロック図が示されている。本発明の一部の例示的実施形態では、サーバ１０２は、少なくとも１つのデータプロセッサ２０４および／またはデータ格納用の少なくとも１つのデータベース２０６を備えたコンピュータである。サーバ１０２はまた一般的に、通信ネットワークシステム１００の他の要素との通信を可能にするために、通信２０２の機能を備える。任意選択的に、サーバ１０２は、他のサーバ、サービスプロバイダ、データベース、管理システムおよび／またはユーザ装置と通信する。
【００２９】
上述の通り、サーバ１０２は一般的に、データ格納用の少なくとも１つのデータベース２０６を備える。任意選択的に、追加データの格納のために、追加的データベース２０８がサーバ１０２に設けられる。本発明の一部の例示的実施形態では、データはアイコニック言語のアイコンを含む。本発明の一部の例示的実施形態では、データはユーザ情報を含む。本発明の一部の例示的実施形態では、データは通信ネットワークシステム１００で送信かつ／または受信されるメッセージを含む。本発明の一部の例示的実施形態では、データは、通信ネットワークシステム１００および／または関連装置、例えばサーバおよび／またはクライアントソフトウェアの動作に関連するいずれかの情報である。
【００３０】
本発明の一部の例示的実施形態では、サーバ１０２は、アイコニック言語に関係するデータの集中的格納および保守のためのデータベースを含む。アイコニック言語に関係するデータは任意選択的に、言語カテゴリ、言語アイコン、アイコン識別、グラフィック画像、アイコン名および類似物を含む。このデータベースは任意選択的に、アイコニック言語の様々なバージョンおよびカスタマイゼーションを含む。任意選択的に、データベースは階層型および／または関係型である。本発明の一部の例示的実施形態では、アイコニック言語データベースは、言語アイコンに直接または間接的に関連付けられる言語カテゴリ記号を含む。任意選択的に、アイコニック言語データベースは、言語カテゴリ記号に従属しかつ言語アイコンに関連付けられる言語サブカテゴリ記号を含む。代替的に、アイコニック言語データベースはアイコンをカテゴリに関連付けない。本発明の一部の例示的実施形態では、各言語アイコンは、それに割り当てられた一意の識別番号を有する。任意選択的に、この識別はデータベース２０６に格納される。データプロセッサ２０４は、データベースに格納されかつ言語アイコンに関係するデータ（例えば各々のアイコン名、ＩＤ、ユーザグループ、ヘルプファイル、様々な言語バージョン等）を処理かつ管理することができる。
【００３１】
本発明の一部の例示的実施形態では、アイコニック言語データベースは定期的に更新される。任意選択的に、アイコニック言語データベースの更新は完全または部分的更新である。任意選択的に、部分的更新はアイコンのカテゴリの追加または除去を含む。任意選択的に、部分的更新は少なくとも１つのアイコンの追加または除去を含むが、アイコンが割り当てられたカテゴリまたはサブカテゴリ全体の追加または除去は含まない。本発明の例示的実施形態では、更新はユーザ装置１０６からの要求に応答して開始される。追加的に、または代替的に、更新はサーバ１０２またはサービスプロバイダ１０４から送信されたデータに応答して開始される。
【００３２】
本発明の例示的実施形態では、アイコニック言語データベースは、少なくとも１つの特殊言語カテゴリ（以下「システムカテゴリ」）、およびこのカテゴリに関連付けられる少なくとも１つのグラフィック画像（以下「システムアイコン」）を含む。システムカテゴリに含まれるシステムアイコンは、例えば言語アイコン、商標、ロゴ、または他の商業的グラフィック画像である。本発明の一部の例示的実施形態では、これらのシステムアイコンは、装置を介してメッセージを作成中にはユーザは利用できないが、サーバ１０２および／または第三者サーバ、例えば第２サーバ１０２’によって発信されるメッセージに含まれる。任意選択的に、これらのシステムアイコンはユーザによって受信され、読み出される。
【００３３】
アイコニック言語データベースまたは異なるデータベースは、他の非アイコニック言語アイコン、例えば様々な制御機能を示すように意図されたものを任意選択的に含む。例えば送信アイコンは、その日常的な言語的使用とは別の制御機能とみなすことができ、送信アイコンは、語「送信」を実際に伝達するのではなく、データを送信するために使用される。制御機能アイコンの別の例として、ヘルプアイコンを挙げることができる。それは必ずしも語「ヘルプ（助ける）」を伝達するように意図されたものではなく、むしろ何かについてユーザに指示するために、ヘルプテキストおよび／またはアプリケーションを呼び出すように意図されている。
【００３４】
上記データベースは、アイコニック言語アイコン、システムアイコン、制御機能アイコン、および／または他のアイコンの多数の変形を任意選択的に含む。例示的実施形態は、様々なディスプレイサイズに使用される様々なサイズのアイコン、および／または様々なディスプレイサイズに適合する、かつ／もしくはユーザの嗜好に適合する様々なフォント／サイズ／色のテキスト要素、および／または様々な言語に関連するアイコンを含む。さらに、本発明の一部の例示的実施形態では、言語カテゴリ記号、言語サブカテゴリ記号、および／または言語アイコンは、アイコン（または記号）をユーザに説明する関連名を有する。アイコン名は任意選択的に、アイコンとは別個に格納されるので、装置毎に異なる言語で表わすことができる。
【００３５】
本発明の一部の例示的実施形態では、アイコン言語データベースおよびサーバ１０２は、言語アイコンをユーザ装置に提供するために使用される。任意選択的に、言語アイコンの提供は、メモリおよび／または格納空間等の、ユーザ装置の技術的能力に依存する。しかし、ユーザ装置が、典型的なパッケージに含まれるより多くのアイコンを格納するためのメモリを有する場合、追加アイコンは任意選択的に、サーバ１０２からユーザにアップロードされ、またはユーザによってダウンロードされる。本発明の一部の例示的実施形態では、ユーザ装置のニーズによっては、データはサーバ１０２とユーザ装置との間で交換されない。本発明の例示的実施形態では、自動機構が使用され、アイコンまたはアイコンのカテゴリ全体がサーバから取り出される。そのような方法は任意選択的に、ユーザ装置に仮想／動的データベースを構築するために使用され、かつ追加的に、ストレージメモリが非常に限定されているユーザ装置は、より効率的に使用される。これらの方法は任意選択的に、ユーザ装置に充分なストレージメモリがある場合から、ストレージメモリが全く無く、通信ネットワークシステム１００で作業する場合まで、全ての範囲をサポートするように一般化される。
【００３６】
本発明の一部の例示的実施形態では、ユーザ情報データベースがサーバ１０２に設けられる。情報は任意選択的に、ユーザ装置情報、個人データ、加入情報（下述）、グループメンバシップ（下述）、課金情報、サービスプロバイダ、ユーザの連絡先リスト、トークン、およびユーザに関する他の有用な情報を含む。本発明の例示的実施形態では、ユーザ情報データベースはまた、ユーザグループに関するデータをも含み、グループは複数の個人ユーザ（メンバ）から構成される。任意選択的に、ユーザは同時に２つ以上のグループのメンバになることができる。本発明の一部の例示的実施形態では、ユーザグループに関するデータは、グループ名、グループのユーザメンバシップ、グループに加入するための規則、各グループに関連付けられるアイコンおよび／またはアイコンカテゴリなどを含む。
【００３７】
サーバ１０２は任意選択的に、ユーザが新しいグループを形成しかつ／またはグループのメンバリストを制御することを可能にするインタフェースを含む。例えば、ユーザは任意選択的に、他者にグループへの加入を勧める招待状を送信し、加入申請を承認かつ／または拒絶し、メンバを除名し、グループ全体に対し管理者権限を有し、そのような権限を他者に付与することなどが許される。ユーザグループは、例として、証券会社、ニューヨーク市の住人、またはスポーツファンから構成することができる。
【００３８】
本発明の特定の実施形態では、アイコニック言語アイコンの名前は、特定のユーザグループ用に調整し、かつ／またはグループによってセルフカスタマイズすることができる。ユーザグループはまた、任意選択的に、例えばアイコニック言語アイコンの専用セットのサブスクリプションによってグループメンバだけが利用できる、アイコニック言語アイコンの専用セットを持つこともできる。これらの専用言語アイコンは、サブスクリプションのみによるユーザグループ専用の特殊カテゴリのみならず、一般的に利用可能な言語カテゴリにも含めることができる。異なるユーザグループは任意選択的に異なるセットの専用アイコンを持ち、したがって任意選択的に、異なるセットの専用アイコンをサブスクライブする。本発明の一部の例示的実施形態では、ユーザグループは任意選択的に、グループの内部のニーズおよび嗜好に従って、アイコニック言語アイコンの外観および／または意味をパーソナライズし、アイコニック言語アイコン、カテゴリ、およびサブカテゴリを追加かつ／または削除する。本発明の一部の例示的実施形態では、特定のグループのメンバだけが専用言語アイコンをダウンロードすることを許可される。ユーザグループに特殊アイコンを使用する場合、サーバ１０２は任意選択的に、ユーザの電話番号および／または他の識別手段を使用することによって、ユーザグループのメンバユーザへのそれらの割当てを管理する。本発明の例示的実施形態では、ユーザグループは少なくとも１人のメンバを有し、任意選択的に通信ネットワークシステム１００の全ユーザは含まない。
【００３９】
本発明の例示的実施形態では、送信されるデータのサイズは、（送信されるデータサイズに関して）より効率的な名前を各グループに相関させるテーブルにユーザグループ名をインデックス化することによって、低減することができることに注目されたい。例えばユーザ情報データベースは、ユーザがグループ「ａｂｃｄｅｆ」および「ａｂｃｄｅｇ」に所属することを示し、相関テーブルでグループ「ａｂｃｄｅｆ」は１とインデックス化される一方、グループ「ａｂｃｄｅｇ」は２とインデックス化される。本発明の例示的実施形態では、グループ「ａｂｃｄｅｆ」に割り当てられたアイコンは、各アイコンがそれに割り当てられる前のグループの完全な名前を反復しなければならない代わりに、整数１がプレフィックスとして付けられる。本発明の一部の例示的実施形態では、相関テーブルはユーザ装置１０６にも存在する。これは、本発明の一部の例示的実施形態では、かなりのメッセージ空間を節約する。本発明の例示的実施形態では、サーバ１０２はグループ内の様々な種類のプロセス、例えば新しいメンバ、新しいアイコン、アイコン名、「共用」アイコンの調整されたグラフィック画像等に関する対話型「民主的」決定または中央化された決定をサポートする。
【００４０】
本発明の例示的実施形態では、サーバ１０２には、サーバ１０２を介して送信されたメッセージの一部または全部を格納するためのメッセージデータベースが設けられる。任意選択的に、それは、アイコン使用の頻度および／または文脈を評価することを含め、様々な目的のためにメッセージを分析する。任意選択的に、メッセージに対して分析が行なわれて、特定のアイコンが他のアイコンと共にどれだけ多く、かつ／またはどのような関係で使用されているかが決定される。
【００４１】
例示的変換プロセス
図３を参照すると、本発明の例示的実施形態に係る、変換のための例示的プロセス３００が示されている。変換は任意選択的に、ユーザが第１通信プロトコルに従って、例えば１つのネットワークおよび／またはサービスフォーマットから異なる第２通信プロトコルを使用する受信機へ、データを送信する場合に（３０２）必要である。本発明の一部の実施形態では、サーバ１０２は、受信者の技術的詳細（例えばネットワーク、サービスフォーマット等）の決定（３０４）に基づいて、セルラ電話機ネットワーク、広帯域ネットワーク、ＰＯＴＳネットワーク、インターネットネットワーク、他のデータ通信ネットワークの間で、かつ／または様々なサービス（例えばＳＭＳ、ＭＭＳ、インスタントメッセージング、ＩＭＳおよびその他のようなメッセージングサービス、移動体広告、移動体コンテンツサービス等）の間で互換可能となるようにデータを変換する。本発明の例示的実施形態では、サーバ１０２は任意選択的に、ＣＤＭＡセルラ電話機ネットワークおよびＧＳＭセルラ電話機ネットワーク間等の、異なる型のネットワーク間の変換を行なう（３０６）。本発明の例示的実施形態では、変換は、無線通信業界のためのＪａｖａ（登録商標）技術仕様をサポートするＪａｖａ（登録商標）２  Ｐｌａｔｆｏｒｍ，Ｍｉｃｒｏ  Ｅｄｉｔｉｏｎ（「Ｊ２ＭＥ」）ワイヤレスツールキットを、第１ユーザ装置１０６および第２ユーザ装置１０６’等のユーザ装置で実現することによって促進される（例えばｈｔｔｐ：／／ｊａｖａ．ｓｕｎ．ｃｏｍ／ｐｒｏｄｕｃｔｓ／ｊ２ｍｅｗｔｏｏｌｋｉｔ／を参照されたい）。Ｊ２ＭＥワイヤレスツールキットは、携帯電話機、主流パーソナルデジタルアシスタント、および他の小型移動装置で実行するように設計されたワイヤレスアプリケーションを開発するためのツールボックスである。ツールキットは、エミュレーション環境、性能最適化、および同調機能を含む。本発明の例示的実施形態では、メッセージ本体の形のデータは同一であるが、メッセージヘッダは様々なネットワークの間で異なる。例えば、ＧＳＭ  Ｊ２ＭＥネットワークのＪ２ＭＥポート番号は任意選択的に、ＣＤＭＡ  ＢＲＥＷに基づくネットワークのクラスＩＤとは異なる。
【００４２】
Ｊ２ＭＥツールキットはまた、ショートメッセージサービス（ＳＭＳ）のような無線通信資源へのプラットフォーム独立アクセスを提供するワイヤレスメッセージングＡＰＩ（ＷＭＡ）を含むこともできる。本発明の一部の例示的実施形態では、サーバ１０２は、受信したメッセージからの特定のサービス送信プロトコルに準拠するメッセージへの変換を促進する。例えば、ＳＭＳサービスに準拠するために、サーバ１０２はメッセージをＳＭＳペイロードに変換する（３０８）。本発明の例示的実施形態では、ＳＭＳ通信のメッセージ送信は任意選択的に、クライアント−クライアントおよびクライアント−サーバ動作モードに対し異なる実現を有する。
【００４３】
クライアント−クライアントモードでは、メッセージは、宛先電話番号、およびユーザ装置のサーバ１０２指定ポート番号（デフォルトまたは他の「周知の」ポート番号とは一般的に異なる。ＣＤＭＡ  ＢＲＥＷでは、それは「クラスＩＤ」と呼ばれる）、およびメッセージとしてかつ／またはＳＭＳデータペイロードとして特徴付けることのできるデータをはじめ、（例えばＧＳＭ、ＣＤＭＡ等で使用される）標準ＳＭＳヘッダを含む。本発明の一部の実施形態では、ポート番号／クラスＩＤは一般的ＳＭＳペイロードの内容である。例えば、ＧＳＭ非Ｊ２ＭＥユーザ装置は、ＳＭＳデータ内容の一部としてポート番号を示すことができる。任意選択的に、メッセージはアイコニック言語で表わされる。任意選択的に、メッセージは、例えば下述するように符号化される。
【００４４】
クライアント−サーバモードでは、メッセージはサーバアドレスを中間宛先として標準ＳＭＳヘッダ（例えばＧＳＭ、ＣＤＭＡ等で使用されるような）を含む一方、ＳＭＳペイロード（データ内容）は、データ送信ソフトウェアによってメッセージに付加される別のメッセージヘッダ（最終宛先ＵＲＩを含む）を含む。中間宛先に着信すると、サーバはＳＭＳペイロードから最終宛先ＵＲＩを取り出し、それをＳＭＳ宛先とする一方、任意選択的にサーバに着信したＳＭＳから抽出された送信者ＵＲＩを、受信側クライアントが送信者を識別することができるように、ＳＭＳペイロードの一部として挿入する。
【００４５】
最終宛先ＵＲＩは様々なフォーマットを取ることができる。
ａ．別の電話機宛ての場合：ｔｅｌ：／／［電話番号］、例えばｔｅｌ：／／＋９７２５４４５５０１３５
ｂ．電子メール宛ての場合：ｅｍａｉｌ：／／［電子メールアドレス］、例えばｅｍａｉｌ：／／ａｂｃ＠ａｏｌ．ｃｏｍ
ｃ．直接ＩＰ宛ての場合：ｕｄｐ：／／［ＩＰアドレス］：［ポート］、例えばｕｄｐ：／／１２７．０．０．１：８００９
ｄ．インスタントメッセージングユーザ等宛ての場合
【００４６】
本発明の例示的実施形態では、中間宛先として働くサーバ１０２は標準ＳＭＳヘッダを認識し、メッセージの残部をペイロードとして取り扱い、それを配信のために最終宛先装置に転送する（３１０）。任意選択的に、メッセージをどこに配信するかを決定するために、ヘッダはサーバ１０２によって分析される。ＳＭＳフォーマットメッセージを受信すると、受信側のユーザ装置はＳＭＳヘッダを抽出し、メッセージの残部を受信ユーザに表示するためのメッセージ読出しアプリケーションに転送する。任意選択的に、ＳＭＳフォーマットメッセージは、受信装置に表示される前に復号される（符号化／復号については下述する）。任意選択的に、表示されるメッセージはアイコニック言語で表わされる。本発明の一部の例示的実施形態では、サーバは、ユーザ装置によって発信されたメッセージと同様にメッセージを生成する。この能力は任意選択的に、例えば広告、パーソナライズされたコンテンツサービス、更新アラート等、システムに由来する様々な種類のメッセージを送信するために使用される。
【００４７】
データをユーザ装置に送信するための例示的方法
本発明の一部の例示的実施形態では、通信ネットワークシステム１００は、装置の有用性および／または通信ネットワークシステム１００に対する運用性を高めるために、ソフトウェアおよび／またはアイコン等のデータを装置にアップロードする。本発明の一部の例示的実施形態では、通信ネットワークシステム１００は、データをユーザ装置１０６、１０６’に「プッシュ」および／または「プル」動作モードで送信することができる。任意選択的に、「プッシュ」および／または「プル」モードは、装置の特定の技術的能力に基づいて選択される。任意選択的に、どのデータがユーザ装置に送信されるかは、装置の特定の技術的能力および／またはインストールされたソフトウェア状態および／または、２つ以上の選択肢がサポートされる場合、ビジネス上の考慮点に基づいて決定される。例えばサービスプロバイダはＳＭＳ課金モデルよりＷＡＰ／ＨＴＴＰの課金モデルを好むので（ＷＡＰ／ＨＴＴＰ対ＳＭＳについては、図４および５に関連して以下でさらに詳述する）、サービスプロバイダは、全てのユーザ装置に対して、ＭＩＤＰ２「プッシュ」方法ではなく、ＭＩＤＰ１「プル」方法を使用することを好むかもしれない。本発明の例示的実施形態では、ソフトウェアは、ユーザによる使用開始の前に、ユーザ装置に予めロードされる。本発明の一部の例示的実施形態では、ソフトウェアはユーザ装置によってダウンロードされ、かつ／またはユーザ装置にアップロードされる。任意選択的に、ソフトウェアは、無線（「ＯＴＡ」）技術を使用して、ユーザ装置によってダウンロードされ、かつ／またはユーザ装置によってアップロードされる。
【００４８】
ＧＳＭ移動情報装置プロファイル（「ＭＩＤＰ」）は、ハンドへルドユーザ装置用のＪ２ＭＥ実現である（詳細説明はｈｔｔｐ：／／ｗｗｗ．ｊｃｐ．ｏｒｇで見ることができる）。現在利用可能なユーザ装置の中には、（仕様ＪＳＲ−３７）をサポートするものがある一方、新世代のユーザ装置は、ＭＩＤＰ２バージョン（仕様ＪＳＲ−１１８以上）をサポートする。バージョン間の主な相違点は、本発明の一部の実施形態に関する限り、ＭＩＤＰ２が、特定のポートで受信されるＳＭＳメッセージの場合等の、ソフトウェアアプリケーションをデータのデフォルトハンドラとして登録することができるのに対して、ＭＩＤＰ１はそれができないことである。したがって、ＭＩＤＰ２装置では、メッセージを「プッシュ」モードで送信し、かつ装置のＯＳにそれらを自動的に処理のための適切なソフトウェアアプリケーションに転送させることができるのに対して、ＭＩＤＰ１装置では、適切なソフトウェアアプリケーションが、装置のデフォルトメッセージングソフトウェアではなくメッセージを処理することを確実にするために、該ソフトウェアアプリケーションが「プル」モードで働くことが要求される。本発明の例示的実施形態では、処理のための適切なソフトウェアアプリケーションへのメッセージの転送は、ソフトウェアアプリケーションがユーザ装置でメッセージに操作を実行することができるように、それを自動的に起動させることも含む。将来の世代のＭＩＤＰ、ＪＳＲ、または同様のアプリケーションは、特定のソフトウェアアプリケーションを特定の型のデータのデフォルトハンドラとして加えるようにこの能力を持つことになりそうであり、かつ本書に記載する方法および装置はこれらの新しい装置およびアプリケーション（例えばＭＭＳ、ＩＭＳ）に適用されることに注目されたい。
【００４９】
本発明の例示的実施形態では、クライアント−サーバ動作モードでユーザ装置にデータを転送する場合、ユーザ装置のサポートのレベルに応じて（例えばＧＳＭ  Ｊ２ＭＥではＭＩＤＰ１、ＭＩＤＰ２、およびＷＭＡ、ならびＣＤＭＡではＢＲＥＷ）、様々なシナリオが存在する。本発明の例示的実施形態では、ＷＭＡは、送信者ユーザ装置がソフトウェアアプリケーションからＳＭＳを発行することを可能にする。本発明の例示的実施形態では、ＭＩＤＰ２は、受信者ユーザが適切なソフトウェアアプリケーションを使用してメッセージを自動的に開くことを可能にする。例えば、送信者がアイコニック言語のメッセージを受信者に送信する場合、受信後、ＭＩＤＰ２を持つ受信者は、メッセージを表示するように設計されたソフトウェアアプリケーションによって、アイコニック言語メッセージを自動的に開かせる。本発明の例示的実施形態では、ほとんどのＢＲＥＷユーザ装置は、アイコニック言語メッセージを適切なソフトウェアにより自動的に開くことができるが、全てのＢＲＥＷユーザ装置ができるわけではなく、またＭＩＤＰ１ユーザ装置はできない。様々なシナリオについて、さらに詳しく下述する。
【００５０】
ＳＭＳによりクライアントを起動させることのできるＭＩＤＰ２またはＢＲＥＷを使用する本発明の例示的実施形態では、ソフトウェアの起動ならびにデータの送信および／または受信は、ＳＭＳメッセージを使用して達成される。図４を参照すると、本発明の例示的実施形態に係る、ＭＩＤＰ２／ＢＲＥＷ（ＳＭＳクライアントの起動が可能な）装置にデータを送信する方法を表わすフローチャート４００が示されている。本発明の例示的実施形態では、データがサーバ１０２に配置され（４０２）、受信者の装置に送信するために利用可能な状態にある。サーバ１０２は、クライアントの動作状態を、つまり受信者の装置のソフトウェアクライアントが開いていそうであるか、それとも閉じていそうであるかを決定する（４０４）。本発明の一部の例示的実施形態では、ソフトウェアアプリケーションクライアントは、クライアントが開いているか、または閉じているかを知らせる信号をサーバに送信する。任意選択的に、この信号はデータベースに格納され、信号を送信したユーザ装置にインデックス化される。ソフトウェアクライアントが閉じていそうであると決定された場合（４０４）、本発明の例示的実施形態に従って、受信者装置がクライアントを自動的に開く（４０６）か、それとも受信者が、ＳＭＳを表示するためのソフトウェアアプリケーションクライアントを開くように受信者装置によって要求される（４０８）。ひとたびソフトウェアクライアントが自動的に開く（４０６）か、受信者がクライアントを開く（４１０）と、あるいはソフトウェアクライアントが開いて始動していた場合、サーバ１０２に配置された（４０２）データは、受信者の装置にプッシュされる（４１２）。本発明の例示的実施形態では、ソフトウェアクライアントは受信者に、データがアクセスできる状態であること（４１６）を知らせる（４１４）。
【００５１】
ＭＩＤＰ１またはＢＲＥＷ（自動的なソフトウェアクライアントの起動ができない）を使用する本発明の例示的実施形態では、ソフトウェアクライアントの起動は、ＨＴＴＰおよび／またはＴＣＰ／ＩＰおよび／またはＷＡＰフォーマットを使用して行なわれる。図５を参照すると、本発明の例示的実施形態に係る、ＭＩＤＰ１またはＢＲＥＷ（自動的なソフトウェアクライアントの起動ができない）を使用して受信者にデータを送信するための方法を表わすフローチャート５００が示されている。任意選択的に、サーバはまた、サーバ１０２および通信ネットワークシステム１００との通信中にユーザ装置を識別するために、起動中に一意のトークンを生成する。本発明の一部の例示的実施形態では、このトークンは、ユーザ装置を識別するために、通信ネットワークシステム１００とのその後の全ての交信に使用される。任意選択的に、トークンは無作為に生成される英数字番号である。ひとたびデータが、受信者への送信のためにサーバ１０２に配置される（５０２）と、ＳＭＳによってクライアントソフトウェアを起動することのできないＭＩＤＰ１またはＢＲＥＷの環境でのデータの送信は任意選択的に、ＨＴＴＰおよび／またはＴＣＰ／ＩＰおよび／またはＷＡＰフォーマットを使用して行なわれる。この動作環境でのメッセージの受信は、本発明の例示的実施形態に従って、ＳＭＳアラートとＨＴＴＰ／ＷＡＰおよび／またはＴＣＰ／ＩＰポーリング要求との組合せを使用する。本発明の例示的実施形態では、受信者の装置でソフトウェアクライアントが開いているかどうかが決定される（５０４）。任意選択的に、ソフトウェアアプリケーションクライアントは、ユーザ装置がサーバを能動的にポーリングしている場合、開いているとみなされる。ポーリングについては下述する。任意選択的に、ソフトウェアアプリケーションクライアントは、ユーザ装置が予め定められた期間内にサーバをポーリングした場合、開いているとみなされる。任意選択的に、ユーザ装置が少なくとも予め定められた期間にわたってサーバにポーリングしなかった場合、ソフトウェアアプリケーションクライアントは閉じているとみなされる。任意選択的に、予め定められた期間は最高で５分である。任意選択的に、予め定められた期間は５分超である。任意選択的に、予め定められた期間は、サーバローディングおよび／またはカスタマサービス等の様々な考慮事項に応じて、異なる時間に設定される。クライアントが受信者の装置で閉じており、かつ／またはクライアントの状態に関する他の情報が無い場合、サーバはアラートＳＭＳを発生し（５０６）、ユーザは受信者の装置のクライアントを手動で開く（５０８）。本発明の例示的実施形態では、ひとたびクライアントが開くと、アラートＳＭＳに従ったか、それともユーザの自発性によるかに関係なく、クライアントは本発明の例示的実施形態に従って以下の動作を実行する。
−ポーリング（５１０）し、サーバ１０２または１０２’に格納され待機しているＳＭＳメッセージを検索（「Ｇｅｔ」コマンドによる）する。これはまた、サーバ１０２または１０２’にクライアントがオンであることをも通知する。サーバは任意選択的に、一意の識別トークンを使用してクライアントのアイデンティティを検証する。
−メッセージの初期検索の後に、オプショナル漸進的ポーリングシーケンスが開始され（５１４）、ポーリングシーケンスが停止するまで、ポーリング相互の時間間隔が徐々に増加する。例えば、１回目のポーリングは、サーバに格納されたメッセージを検索してから３０秒後であり、２回目のポーリングは１回目のポーリングから３０秒後であり、３回目のポーリングは１分後（つまり開始から２分後）であり、４回目のポーリングは２分後（つまり開始から４分後）であり、５回目のポーリングは４回目のポーリングから４分後（開始から８分後）に発生する。これらの時間間隔およびポーリングの回数は単なる例である。本発明の例示的実施形態では、各ポーリングの少なくとも時間を示すログがデータベースに作成される。本発明の例示的実施形態では、このログはソフトウェアアプリケーションクライアントの動作状態を、それが開いているか、それとも閉じているか、決定するために使用される。例えば、最後のポーリング以降にクライアントとの通信が無いこと、または予め定められた期間を超えることがログで示されると、任意選択的にクライアントは閉じているとみなされる。
【００５２】
本発明の例示的実施形態では、ポーリング（５１０）、（５１４）の後、データにアクセスすることができる（５１６）ことが受信者に通知される（５１２）。本発明の例示的実施形態では、待機しているＳＭＳメッセージに対するポーリングは、ユーザがメッセージを送信することに応答して発生する。任意選択的に、上述したポーリングシーケンスは、ユーザがメッセージを送信することに応答して、あるいは本発明の一部の例示的実施形態では、クライアントが非活動期間後に「覚醒した」場合に開始される。
【００５３】
本発明の一部の例示的実施形態では、サーバ１０２および／または１０２’はクライアントによって行なわれたポーリングの時間を記録する。サーバ１０２および／または１０２’は任意選択的に、サーバがユーザ向けのＳＭＳメッセージを受け取るたびに、最後のポーリングから経過した時間をチェックする。経過時間が予め定められた間隔より大きい場合には、サーバは任意選択的に、アラートＳＭＳを発生してユーザに送信する。本発明の一部の例示的実施形態では、サーバはユーザを待っているメッセージを分析し、まだユーザに検索されず、予め定められた期間より長く待機しているメッセージがあることを表わすアラートを発生する。任意選択的に、サーバは、待機しているＳＭＳメッセージについてアラートが生成されたことを通知する。本発明の一部の例示的実施形態では、サーバはメッセージを格納し、各メッセージに一意の識別番号を割り当てることに注目されたい。任意選択的に、検索されたメッセージは、ユーザの入力ボックスおよび／またはサーバから削除される。任意選択的に、格納されたメッセージは、統計の収集のために分析される。データベース待ち行列を節約するために、本発明の一部の例示的実施形態では、サーバは、次のスキャンを待っておりアラートＳＭＳがまだ生成されていないＳＭＳメッセージのための専用待ち行列を使用する。
【００５４】
メッセージフォーマットおよび最適化
本発明の例示的実施形態における様々な型のメッセージのフォーマットについて下述する。全てのＺＭＳメッセージの第１内容フィールドは、本発明の例示的実施形態では、ＴＬＶ規則（下述）の例外であり、それはプロトコルバージョンであり、その長さは６ビットであることに注意されたい。任意選択的に、その値が０である場合、それはエスケープ文字であるとみなされ、プロトコルが絶対に６３バージョンを超える必要がある場合、次の１２ビットがプロトコルバージョンと受け取られることを意味する。本発明の例示的実施形態では、プロトコルバージョンはＵＲＬセーフベース６４の単一文字として符号化される（またはエスケープを使用する場合、零の後に２つのＵＲＬセーフベース６４文字が続く）。
【００５５】
次に、様々なメッセージの型について、各フィールド型の名前を＜＞括弧内に入れて説明する。各フィールド型は、下述するＴＬＶスキームで異なる値の「Ｔ」を有する。
【００５６】
本発明の例示的実施形態では、起動メッセージは、次のフォーマット：プロトコルバージョン＜起動識別子＞＜セキュリティトークン＞＜装置型＞＜電話番号＞＜オペレータ＞＜ソフトウェアクライアントバージョン番号＞＜言語＞＜ニックネーム＞を用いて構成される。ここで、
１．＜起動識別子＞は値を持たない型であり、それはメッセージが起動メッセージであり、したがってその長さは常に０であることを示すだけであり、長さフィールドは０を含む。
２．＜セキュリティトークン＞は、ユーザ装置のアイデンティティを識別しかつ検証するために使用される、上述したトークンである。
３．＜装置型＞は任意選択的に、使用されるユーザ装置の型を識別する文字列を含む。本発明の例示的実施形態では、それはインストールファイルの一部であり、そういうものとしてそれはダウンロード中にクライアントの一部として供給される。
４．＜電話番号＞は受信者の電話番号である。本発明の例示的実施形態では、フォーマットは完全な国際番号を有する。
５．＜ソフトウェアクライアントバージョン番号＞は任意選択的に、ダウンロードプロセス中にクライアントの一部として提供されるユニコード文字列である。
６．＜言語＞は任意選択的に、ユーザによって設定可能なユニコード文字列である。
７．＜ニックネーム＞は任意選択的に、ユーザおよび／または通信ネットワークシステムによって選択されるユニコード文字列である。
【００５７】
本発明の例示的実施形態では、起動メッセージは任意選択的に、ユーザ名の変更、特殊アイコンパッケージのインストール、ＳＩＭカードの異なるユーザ装置への転送等の様々な事象の発生時に、サーバを更新するために再送信される。起動メッセージはまた、任意選択的に、外部ダウンロードサーバが使用され、そこで新しいユーザに関するレポートの生成にかなりの遅延がある場合に、インスタントサービスを可能にするために使用される。本発明の例示的実施形態では、このメッセージに対する応答は新しいセキュリティトークンであり、それはその後のメッセージに含まれる（本書に記載した通り）。この登録メッセージが最初に送信されるとき、セキュリティトークンは任意選択的に空白フィールドである（長さ０）。
【００５８】
本発明の例示的実施形態では、送出メッセージは次の通りである：プロトコルバージョン＜セキュリティトークン＞＜宛先電話番号＞＜送信者電話番号＞＜送信者ニックネーム＞＜ＳＭＳ内容＞。＜送信者ニックネーム＞は任意選択的にサーバによって抽出されるが、任意の検証目的のために挿入される。本発明の一部の例示的実施形態では、＜送信者電話番号＞は、メッセージがＨＴＴＰを介してサーバ１０２に送信されるときに、メッセージに含まれる。本発明の例示的実施形態では、メッセージがＳＭＳによって送信されるときに、受信者は送信者の電話番号を見ることができなければならない。本発明の一部の実施形態では、送信者の電話番号は、それをセキュリティトークンと照合させるために使用される。代替的に、送信者の電話番号は送信されず、サーバ１０２はそれをセキュリティトークンから推測する。本発明の例示的実施形態では、着信メッセージは次の通りである：プロトコルバージョン＜送信者電話番号＞＜送信者ニックネーム＞＜ＳＭＳ内容＞。
【００５９】
本発明の例示的実施形態では、＜セキュリティトークン＞＜宛先電話番号＞＜送信者電話番号＞＜送信者ニックネーム＞を単一の＜ヘッダ＞ＴＬＶに短縮する、代替的送出メッセージフォーマットが使用される。任意選択的に、送信者電話番号およびニックネームを除外した＜単純ヘッダ＞、送信者電話番号のみを除外した＜ニックネーム付きヘッダ＞、および全てのフィールドを含む＜ニックネームおよび送信者電話付きヘッダ＞を含め、少なくとも３種類の＜ヘッダ＞がある。
【００６０】
本発明の例示的実施形態では、アイコニック言語のＳＭＳメッセージは、ＴＬＶフォーマットすなわち型、長さ、および値を使用して符号化される。これは任意選択的に、新しい型を追加することによって、アイコニック言語ＳＭＳメッセージに新しい情報を追加することを可能にする。この型フィールドは任意選択的に長さ８ビットであり、２５５の型が可能であり、かつ２５５では少なすぎることが分かった場合には、「エスケープ」タイプを加えることが可能である。長さフィールドは任意選択的に、本発明の一部の例示的実施形態に従って、古いクライアントが新しい未知の型の値フィールドをスキップすることを可能にする。長さフィールドは任意選択的に１０ビットの長さであり、単一チャンクに対して最高で１Ｋの長さが可能である。長さフィールドは任意選択的にサイズをビット単位で指定して、所定の型がそれ自体の暗黙のチャンクサイズを定義することを可能にし、利用可能な空間の最良の使用を可能にする。例えばアイコンは、各アイコンｉｄに９ビットが使用されることを意味し最高で５１２のアイコン値を可能にするアイコン−９型、またはアイコンｉｄ当たり１２ビットを使用し最高で４０９５のアイコン値を可能にするアイコン−１２型を使用して、符号化することができる。
【００６１】
本発明の例示的実施形態では、アイコニック言語のＳＭＳ内容は、３つのカテゴリすなわち＜アイコン−＃＞、＜テキスト−＃＞、および＜拡張アイコン−＃＞から取り出される一連のＴＬＶであり、ここで＃は、下にリストする特定の型に対して利用可能な値の１つである（例えばアイコン−７、テキスト−１６）。
【００６２】
テキストＴＬＶ＜テキスト−＃＞は、本発明の一部の例示的実施形態では、一連のユニコード文字を含む。選択される特定の＃は、各ユニコード文字ｉｄにどれだけのビット数が使用されるかを決定する。例えば、テキスト−１６は１ユニコード文字当たり１６ビットを割り当て、それによって範囲全体をカバーする。任意選択的に、テキスト−７またはテキスト−１２を本発明と共に使用して、全ユニコード範囲のより限定された部分を使用するメッセージが可能になる（例えば英語は７ビット未満のユニコードを使用する）。任意選択的に、１文字当たり２ないし１６ビットが使用される。任意選択的に、１文字当たり１６ビット超が使用される。
【００６３】
アイコンＴＬＶ＜アイコン−＃＞は、本発明の一部の例示的実施形態では、一連のアイコン識別を含む。特定の＃は、各アイコン識別にどれだけのビット数を使用するかを決定する。本発明の一部の例示的実施形態では、アイコン−９が使用され、各アイコン識別に９ビットが割り当てられる（５１２の可能性）。任意選択的に、より大きい範囲のアイコン識別を可能にするために、アイコン−１６またはそれ以上が使用される。任意選択的に、１アイコン当たり２ないし１６ビットが使用される。
【００６４】
複数のアイコンセットをサポートするために、本発明の一部の例示的実施形態ではアイコンセットＩＤがある。本発明の例示的実施形態では、これは１６ビットの整数値であり、非常に広範囲のアドオンアイコンセットが可能である。いずれかの所定のアイコンセットで、アイコンの識別は１から始まる。通常のＳＭＳにこれらのアイコンを含めるために、アイコンセットＩＤは任意選択的に、アイコンＩＤと組み合わせて指定される。本発明の例示的実施形態では、ユーザはごく少数のアドオンアイコンセットしか持たず、したがってアイコンセットテーブルＴＬＶおよび拡張アイコンＴＬＶが使用される。
【００６５】
アイコンセットテーブルＴＬＶ＜アイコンセットテーブル＞は、本発明の一部の例示的実施形態では、最高１６までのアイコンセットＩＤのリストを含む。これらは、メッセージで使用されるアドオンアイコンセットＩＤである。全く無い場合には、アイコンセットテーブルＴＬＶがメッセージに現われる必要は無い。１６未満がある場合、ＴＬＶはそれに応じて短くすることができる。
【００６６】
本発明の例示的実施形態では、拡張アイコンＴＬＶ＜拡張アイコン−＃＞はアイコンＴＬＶと同様であるが、それはアイコンセットテーブルへのインデックスである追加の４ビットフィールドを冒頭に含み、どのアイコンセットＩＤが、ＴＬＶに含まれるアイコンＩＤのシーケンスに適用可能であるかを指定する。
【００６７】
このスキームの実際の結果は、１０個の異なるアドオンアイコンセットからの例えば１０個のアイコンを含むメッセージが、１０個の拡張アイコンＴＬＶを有するようになることである。例えばデフォルトアイコンセットからの１０個のアイコンを含み、その後に単一のアドオンセットからの１０個のアイコンが続くメッセージは２つのＴＬＶを含み、最初の１０個のアイコンのｉｄを持つアイコンＴＬＶの後に、アドオンセットｉｄのアイコンセットテーブルのインデックスおよび次いで残りの１０個のアイコンｉｄを持つ拡張アイコンＴＬＶが続く。
【００６８】
本発明の一部の例示的実施形態では、アイコンおよびテキストの両方を含むメッセージの最適な符号化に使用される、混合内容ＴＬＶが存在する。混合内容ＴＬＶは任意選択的に、アイコン符号化およびテキスト符号化に使用されるビット幅を示すヘッダを有する。本発明の一部の例示的実施形態では、これらの数字はその混合内容ＴＬＶの持続時間中固定される。その後、アイコンｉｄおよびテキストの交互セグメントがあり、各々任意選択的に８ビット長のフィールドが先行する。
【００６９】
任意選択的に使用される型を下にリストする。本発明の例示的実施形態では、リストの番号は、符号化においてその型を表わすために使用される番号である。フィールドの内容の符号化スキームは、本発明の例示的実施形態では、型によって決定される。任意選択的に、フィールドの内容はユニコード７で符号化される。つまり、内容は７ビットのチャンク単位に構成され、その各々がユニコード値を表わす符号無し整数として解釈される。我々が用語ユニコード−７を使用する場合、それは特定の意味論を伴わず、データフォーマットのみを指す。テキスト−７は、ユニコード−７データフォーマットを使用して符号化される、ＳＭＳメッセージのテキスト内容を指すプロトコルのデータ型である。
【００７０】
本発明の一部の例示的実施形態で使用される例示的な型フィールドとして、次のようなものが挙げられる。
１．＜登録識別子＞
２．＜セキュリティトークン＞
３．＜装置型＞
４．＜送信者電話番号＞
５．＜オペレータ＞
６．＜クライアントバージョン番号＞−インストールの一部として提供される
７．＜言語＞−インストールまたは言語更新の一部として提供される
８．＜送信者ニックネーム＞−ユニコード１６で符号化される内容
９．＜宛先電話番号＞
１０−１９．＜アイコン−＃＞  ＃は、１０−１９に対応する７から１６までのいずれかの番号とすることができる。これは一連のアイコン識別を符号化し、ここで各アイコン識別は＃ビット数によって表わされる。
２０−２９．＜テキスト−＃＞  ＃は、２０−２９に対応する７から１６までのいずれかの番号とすることができる。これは一連のユニコード文字を符号化し、ここで各文字は＃ビット数によって表わされる。
３０−３９．＜拡張アイコン−＃＞  ＜アイコン−＃＞に似ているが、一連のアイコン識別の前に追加的な４ビットフィールドがある。４ビットフィールドはアイコンセットテーブルへのインデックスである。
４０．＜アイコンセットテーブル＞は一連の１６個のビットアイコンセット識別である。最高で１６個のそのような識別が存在することができる。本発明の例示的実施形態では、１つの＜アイコンセットテーブル＞ＴＬＶがメッセージに現われる。任意選択的に、複数のそのようなＴＬＶが現われ、１６個を超えるアドオンアイコンセットが可能である。そのようなシナリオで、アイコンセットテーブルの言及は任意選択的に、メッセージ内で最も最近の以前のアイコンセットテーブルを指す。
４１．＜内容検査＞は、内容検査が現われる位置までのメッセージのビット単位の長さを示す１６ビット値を含む。本発明の例示的実施形態では、それはメッセージの最後に配置され、メッセージの完全な内容が受信されたことを検証することができる。
４２．＜混合内容＞は、テキストおよびアイコンの両方を含むほとんどのメッセージを符号化するための特殊フォーマットである。その目標は、本発明の例示的実施形態では、メッセージ内のテキストおよびアイコンの間で交互に切り替えることに関与するオーバヘッドを最小限に低減することである。任意選択的に、それは２つの４ビットフィールドで開始され、最初の１つが１つのアイコン当たりに使用されるビット数を示し、２番目がテキストの１文字当たりに使用されるビット数を示す。その後、それは任意選択的に、メッセージ全体が符号化されるまで必要に応じて何回でも、交互に切り替わる一連のアイコンチャンクおよびテキストチャンクを有する。各チャンクは任意選択的に、チャンク内の項目（アイコンまたは文字のいずれか）の個数を示す、８ビットフィールドで開始される。（したがってこのＴＬＶは、２５５文字より長いテキスト文字列を含むメッセージには使用できない）。本発明の例示的実施形態では、データはその後現われ、各項目がＴＬＶのヘッダに示されたビット数を取る。メッセージがテキスト文字列で開始される場合、混合内容ＴＬＶは任意選択的に依然として、アイコンチャンクから開始されることに注意されたい。そのチャンクの長さは任意選択的に０となる。同様に、メッセージが２５５より長い、例えば２６５の一連のアイコンを有する場合、混合内容ＴＬＶは、本発明の一部の例示的実施形態では、これを長さ２５５のアイコンチャンク、長さ０のテキストチャンク、および長さ１０の別のアイコンチャンクとして符号化する。
【００７１】
＜混合内容＞の例示的内部構造を要約すると、次のようになる。
＜アイコンｉｄ幅＞＜テキスト文字幅＞（＜アイコンチャンク＞＜テキストチャンク＞）＊
ここで、
＜アイコンチャンク＞＝＜ｎｕｍＩｃｏｎｓ＞＜アイコン−ｉｄ−１＞＜アイコン−ｉｄ−２＞．．．
＜テキストチャンク＞＝＜ｓｔｒＬｅｎｇｔｈ＞＜文字−１＞＜文字−２＞．．．
である。
本発明の一部の例示的実施形態では、ｎｕｍＩｃｏｎｓおよび／またはｓｔｒＬｅｎｇｔｈは０であることに注意されたい。
４３．＜単純ヘッダ＞は、本発明の例示的実施形態では、１８ビットのセキュリティトークン、電話番号プレフィックス型を表わす２ビット、および宛先電話番号を含む５０ビットを含む。ビットサイズは単なる例であって、任意選択的に、ヘッダが付加されたメッセージの適切な送信を可能にする、いずれのビットサイズでも使用されることに注意されたい。本発明の一部の例示的実施形態では、プレフィックス符号化と番号符号化との間に区切りが使用される。これは、本発明の一部の実施形態では、完全な宛先電話番号の符号化が、いずれかの非番号プレフィックスを符号化できないことを意味するためであり、かつ／または先行するゼロに関する情報が失われるためである。本発明の例示的実施形態では、有効なプレフィックス型は（０＝プレフィックス無し、１＝プラスプレフィックス、２＝単一ゼロプレフィックス、３＝ダブルゼロプレフィックス）である。
４４．＜ニックネーム付きヘッダ＞は、本発明の一部の例示的実施形態では、＜単純ヘッダ＞に似ているが、テキスト−１２を使用して符号化されたニックネームが付加される。本発明の一部の実施形態では、ニックネームの長さは完全ＴＬＶから最初の２つの固定フィールを差し引いた長さから導出することができることに注意されたい。
４５．＜ニックネームおよび送信者電話付きヘッダ＞は、本発明の一部の例示的実施形態では、＜ニックネーム付きヘッダ＞に似ているが、任意選択的に追加的な２ビットの電話プレフィックスおよび送信者の電話を表わす５０ビットの電話番号が付加され、その後に宛先電話番号が続き、その前に可変調のニックネームが先行する。
【００７２】
通信ネットワークシステム１００はまた、本発明の一部の例示的実施形態に従って、システム１００で送信されるデータを最適化することもできる。図６を参照すると、本発明の例示的実施形態に従って、メッセージサイズを最適化するための方法のフローチャート６００が示されている。メッセージが作成された（６０２）後、それがサービスプロバイダ１０４に送信される（６１０）前、またはそれ以外の仕方でユーザ装置によって操作される前に、任意の最適化の段階がある。通信ネットワークシステム１００によって使用可能ないずれかの容認できるフォーマットが、テキストまたはアイコニック文字等の、作成されたメッセージの少なくとも１つの要素のデフォルトによって指定される（６０４）。任意選択的に、通信ネットワークシステム１００によって使用されている最小効率のフォーマットが使用される。任意選択的に、このフォーマットは、メッセージがアイコン、テキスト、または両方のどれを使用するかによって、アイコン−１６および／またはテキスト−１６である。
【００７３】
適切な型の変形（例えばアイコン−９またはアイコン−１２、またはテキスト−７対テキスト−１６）を選択する論理をアプリケーションに投入する代わりに、アプリケーションは任意選択的に最小効率の変形（アイコン−１６またはテキスト−１６）を指定し、次いでメッセージ内容を分析し（６０６）、かつ可能な場合にはより効率的な型に置換する（６０８）、最適化ツールを有する。換言すると、アプリケーションが全てのテキストにテキスト−１６を使用する場合、最適化ツールは各文字を分析して、内容がより高位のビットを使用しているか否かを調べる。否の場合、どれだけのより高位のビット数が未使用であるかに応じて、クライアントは単に、テキスト−７またはテキスト−１２を使用するようにチャンクを変更することができる。同じことがアイコンに当てはまる。本発明の例示的実施形態では、メッセージサイズは、占める空間の少ない型変形を選択することによって最適化される。
【００７４】
セキュリティ
上述の通り、セキュリティトークンの使用に加えて、ユーザ装置およびサーバ１０２は、メッセージングサービスの現在の標準と互換可能なフォーマットでの送信を容易にするために、メッセージ（関連がある場合、アイコニックおよびテキストセグメントを含む）を符号化および／または復号することができる。本発明の例示的実施形態に従って、アイコニックメッセージを符号化／復号するプロセス７００をさらに図７に示す。メッセージが作成された（７０２）後、それはその後、本発明の例示的実施形態に従って、ＳＭＳおよびＨＴＴＰでの安全な送信を確実にするために，ＵＲＬセーフベース６４符号化を使用して（Ａ−Ｚ、ａ−ｚ、０−９、＊−、文字を使用して）さらに符号化される（または「チャネル符号化」される）。ＵＲＬセーフベース６４への符号化は、ＴＬＶ構造に関係なく、メッセージを６ビット単位でチャンクする（７０４）ことを含む。本発明の例示的実施形態では、ベース６４符号化（７０６）は、メッセージの内容を一度に６ビットずつ取り出し、これをベース６４のＵＲＬセーフ変形の文字にマッピングすることによって行なわれる。本発明の例示的実施形態では、ビット単位の長さが６ビットの倍数ではないメッセージは、それらの長さを６の倍数にするために、「０」ビットを右詰めされる（７０８）。本発明の一部の実施形態では、６ビットのチャンクの値は最高位ビットから始まると解釈されることに留意されたい。したがって「１０００００」は３２であり、「０００００１」は１である。本発明の一部の例示的実施形態では、例えばメッセージのフォーマットおよび／または受信者および／または送信者を識別するために、少なくとも１つのヘッダがメッセージの内容に付加される。本発明の例示的実施形態では、メッセージを符号化した後、送信される（７１０）。メッセージの復号は、受信者がそれを読む前のいずれかの時点で行なわれる。任意選択的に、復号は受信者の装置で行なわれる。任意選択的に、復号はサーバ１０２または１０２’で行なわれる。
【００７５】
例示的使用方法
アイコニック言語ソフトウェアアプリケーションクライアントが初めて実行されるときに、クライアントは任意選択的に、ユーザからニックネームを得、ニックネームおよび装置の型を含む起動／登録メッセージをサーバ１０２に送信する。本発明の一部の例示的実施形態では、ニックネームは英語の文字である。ユーザ装置の型情報は任意選択的に、インストールされたバージョンから取られる（Ｊ２ＭＥの場合、ＪＡＤファイルから）。本発明の例示的実施形態では、例えばユーザがニックネームを更新したい場合、かつ／またはユーザがＳＩＭを新しい装置に送信したい場合に、この登録メッセージは任意選択的に情報を更新するために再送信される。
【００７６】
図８を参照すると、本発明の例示的実施形態に係る使用方法を表わすフローチャート８００が示されている。ユーザがユーザ装置でアイコニックメッセージを作成した（８０２）後、本発明の一部の例示的実施形態に従って、ユーザはメッセージの送信を開始する。ユーザ装置は任意選択的に、メッセージを送信する（８０４）前に、上述の通りそれを符号化する。本発明の例示的実施形態では、メッセージはサービスプロバイダ１０４によって受信される（８０６）。メッセージを受信した（８０６）後、サービスプロバイダ１０４は任意選択的にメッセージを構文解析し（８０８）、特殊なマーク（例えばポート番号）によりメッセージがアイコニックメッセージであることを認識し、さらなる操作のために、サービスプロバイダ１０４に関連付けられるサーバ１０２に、または受信者のサービスプロバイダ１０４’にメッセージを転送する（８１０）。
【００７７】
本発明の一部の例示的実施形態では、サーバ１０２または１０２’は受信者を識別し、メッセージの受信後に、メッセージをいかに配信するかを決定するために、ユーザデータベースから受信者関連情報を得る（８１２）。例えば、メッセージが誰かの電子メールアドレスに送信される場合、本発明の例示的実施形態では、サーバ１０２は、受信した符号化されたアイコニック言語メッセージを復号し、適切なアイコンを持つ画像ファイルを作成し、ＳＭＴＰを介して電子メールメッセージを、画像ファイルをこのメッセージに添付して、ターゲット電子メールアドレスに送信する。このようにして、標準電子メールクライアントが、いかなるインストール等も実行する必要なく、アイコニックメッセージを受信することができる。同様に、インスタントメッセージング、例えばＩＣＱをサポートするために、サーバは任意選択的に、あたかもメッセージが別のＩＣＱクライアントから送信されたかのように、ＩＣＱプロトコルを介してメッセージを送信する。
【００７８】
本発明の例示的実施形態で、アイコニック言語メッセージがセルラ電話機ユーザ装置に送信される場合、サーバ１０２は、受信者の装置の型および／またはそれがメッセージを受信するためにどの方法を使用するかを決定しようと試みる（８１４）。それは例えばＣＤＭＡ  ＢＲＥＷ、ＭＩＤＰ、または他の方法とすることができる。本発明の例示的実施形態で、アイコニック言語メッセージを表示することのできない装置（例えばＭＩＤＰ１装置）を使用している受信者に送信されるアイコニック言語メッセージは、サーバ１０２の例えば受信者のメッセージ入力ボックスに追加する（８１６）ことができる。本発明の特定の実施形態では、サーバ１０２は、通知メッセージ（例えば受信者の装置に送信される通常のＳＭＳ）および／または他のアラートを送信することによって、新しいメッセージについて受信者に通知する。受信者は任意選択的に、アイコニック言語メッセージングアプリケーションを起動し、メッセージを読む（８２０）ためにサーバ１０２をポーリングする（「プル」モード）ことによって、メッセージをダウンロードする（８１８）。Ｊ２ＭＥを実装した旧世代のユーザ装置は、アプリケーションからＳＭＳを生成するオプションを提供するＷＭＡモジュールが欠如しているかもしれない。そのような場合、クライアントは任意選択的に、サーバとのＩＰ（一般的にＨＴＴＰまたはＷＡＰ）セッションを開始し、その後メッセージが受信者に伝達される。本発明の例示的実施形態では、受信者の装置がＭＩＤＰ２をサポートしている場合、サーバ１０２は任意選択的に、アイコニック言語メッセージを装置の指定ポートに送信する（８２２）。本発明の一部の例示的実施形態では、アイコニック言語メッセージングアプリケーションは自動的に起動され、受信者は任意選択的に通知を受信し、かつ／または通常のＳＭＳメッセージ（「プッシュ」モード）と同様の仕方でアイコニック言語メッセージを読む（８２４）。
【００７９】
本発明の例示的実施形態では、受信者の装置がアイコニック言語メッセージを表示することができず、かつ／または受信者がユーザ情報データベースに存在しない他の理由がある場合、サーバ１０２は任意選択的に、サービスプロバイダ１０４を介して送信者に配信が失敗したことを通知する。本発明の特定の例示的実施形態では、サーバ１０２は任意選択的に、図３に関連して述べた通り、アイコニック言語メッセージを受信者が容認できるフォーマットに変換し、変換されたメッセージを、サービスプロバイダ１０４を介して受信者に送信する。代替的に、サーバ１０２は、受信者に送信するためのメッセージのレンダリング画像を持つＷＡＰページを作成する。任意選択的に、ＷＡＰページは様々な一般的スクリーンサイズに適合される。任意選択的に、継続リンクを用いて、レンダリングメッセージを連続ページに分割することができる。本発明の一部の例示的実施形態では、受信者の装置は任意選択的に、ＵＡ−Ｐｒｏｆまたは／およびＵＡヘッダによってＷＡＰトランザクションプロトコルによって伝達されるそのプロファイルまたはＩＤによって識別される。本発明の例示的実施形態では、適切なＷＡＰページは、装置のディスプレイおよび／またはブラウジング能力に適合するようにレンダリングされる。ＷＡＰページはまた、任意選択的に、クライアントソフトウェアをダウンロードサーバからダウンロードするリンクを含む。ＷＡＰページ解決法に代わって、サーバ１０２は任意選択的に、アイコニック言語メッセージを表示するための適切なユーザ装置を持たないユーザに、特定のウェブ位置で見るために利用できるレンダリングメッセージがあることを通知し、受信者がインターネットに接続されたコンピュータ等の適切な手段を用いてそれを見ることを可能にする。任意選択的に、メッセージはテキストで受信者に送信される。任意選択的に、メッセージは受信者の電子メールアドレスに送信される。
【００８０】
本発明の一部の例示的実施形態では、ソフトウェアアプリケーションはユーザ装置にダウンロードされ、サーバ１０２でソフトウェアアプリケーションを起動させることなく、かつ／またはセキュリティトークン（上述の通り）を受け取ることなく、依然として使用することができる。例えば、ユーザ装置１０６にダウンロードされインストールされたソフトウェアアプリケーションは必ずしも、機能するためにサーバ１０２と対話する必要はなく、その場合、アプリケーションは通常通り完全にユーザ装置１０６上で動作することができる。任意選択的に、ソフトウェアアプリケーションはユーザ装置１０６にダウンロードされ、インストールされ、そして試験的に試される。本発明の試験的な例示的実施形態では、起動は試験期間が経過した後でのみ行なわれてよい。
【００８１】
本発明の一部の例示的実施形態では、装置および方法は、例えば、ＰＣＴに従って本願と同時に出願した「Ｉｃｏｎｉｃ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ」と称する出願（代理人整理番号５２４／０４９８３）、およびイスラエル特許庁に本願と同時に出願した「Ｃｏｍｍｕｎｉｃａｔｉｏｎ  Ｎｅｔｗｏｒｋ  Ｓｙｓｔｅｍ  ａｎｄ  Ｍｅｔｈｏｄ  ｆｏｒ  Ｕｓｉｎｇ  Ｓａｍｅ」と称する出願（代理人整理番号５２４／０５０７７）に記載されている通信ネットワークシステム１００と共に使用され、それらの開示内容を参照によって本書に援用する。
【００８２】
本発明は、例示として提供されるその実施形態の限定されない詳細な説明を使用して説明されており、本発明の範囲を限定しようとするものではない。１つの実施形態に関して記載された特徴および／または工程は、他の実施形態で使用されることができること、および本発明の全ての実施形態が、特定の図面において示されたか、または実施形態のうちの１つに関して記載された特徴および／または工程の全てを有するわけではないことが理解されるべきである。記載された実施形態の変形は、当業者が思いつくであろう。さらに、用語「備える／含む（ｃｏｍｐｒｉｓｅ）」、「含む（ｉｎｃｌｕｄｅ）」、「有する（ｈａｖｅ）」およびそれらの活用形は、明細書および特許請求の範囲において使用されるとき、「含むが必ずしも限定されない（ｉｎｃｌｕｄｉｎｇ  ｂｕｔ  ｎｅｃｅｓｓａｒｉｌｙ  ｌｉｍｉｔｅｄ  ｔｏ）」ということを意味するだろう。
【００８３】
記載された実施形態のうちいくつかは、発明者によって企図される最良の形態を記載し、それゆえ本発明に必須ではない、実施例として記載される構造、行為、または構造および行為の詳細を含むことができるということに注意されたい。本明細書中に記載される構造および行為は、構造または行為が異なっていても同じ機能を実行する、当該分野において公知の均等物によって置き換えられる。したがって、本発明の範囲は、特許請求の範囲において使用される要素および限定によってのみ制限される。
【図面の簡単な説明】
【００８４】
【図１】本発明の例示的実施形態に係る、通信ネットワークシステムの構成要素を表わすブロック図である。
【図２】本発明の例示的実施形態に係る、通信ネットワークシステムのサーバ装置を表わすブロック図である。
【図３】本発明の例示的実施形態に係る、変換プロセスを表わすフローチャートである。
【図４】本発明の例示的実施形態に係る、ＭＩＤＰ２および幾らかのＢＲＥＷプロトコルの場合のデータ送信方法を表わすフローチャートである。
【図５】本発明の例示的実施形態に係る、ＭＩＤＰ１および幾らかのＢＲＥＷプロトコルの場合のデータ送信方法を表わすフローチャートである。
【図６】本発明の例示的実施形態に係る、メッセージサイズ最適化方法を表わすフローチャートである。
【図７】本発明の例示的実施形態に係る、メッセージの符号化方法を表わすフローチャートである。
【図８】本発明の例示的実施形態に係る、通信ネットワークシステムの使用方法を表わすフローチャートである。
【図１】
2008529325.tif 000003
【図２】
2008529325.tif 000004
【図３】
2008529325.tif 000005
【図４】
2008529325.tif 000006
【図５】
2008529325.tif 000007
【図６】
2008529325.tif 000008
【図７】
2008529325.tif 000009
【図８】
2008529325.tif 000010