(57)【要約】  ピアツーピア通信システムが、あるネットワークピア上のアプリケーションコンポーネントから別のネットワークピア上のアプリケーションコンポーネントにアプリケーションデータを送信する。プログラミングインタフェースは、通信システムに与えられ、ピアツーピア通信に依存するアプリケーションのプログラミングを促進する。通信システムは、ピアツーピアアプリケーションコンポーネント間の通信以外の目的でそれぞれのピアと接続可能なメッセージングプロバイダを使用し、それによりピアツーピアアプリケーションが通信に要求するリソースを削減し、システムは携帯型電子デバイスで使用するのに有利となる。さらに、通信システムは、それぞれのメッセージングプロバイダに既に割り当てられたアドレスを使用し、アドレス指定可能でなかったピア間のピアツーピア通信を可能とする。
2009506425.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータ実行可能コンポーネントを有するコンピュータ可読媒体であって、
（ａ）複数のメッセージングプロバイダのうち少なくとも１つを使用してメッセージを送受信する通信コンポーネント、
（ｂ）複数のエントリを備えるデータストアであって、それぞれのエントリは宛先の識別子を記憶するフィールドと、前記複数メッセージプロバイダのメッセージングプロバイダの識別子を記憶するフィールドと、前記指定されたメッセージングプロバイダにおける宛先に関連付けるアドレスとを備えることを特徴とするデータストア、
（ｃ）前記複数のメッセージングプロバイダの１つを使用して受信されたメッセージとアプリケーションを関連付け、前記メッセージを前記関連付けられたアプリケーションに与えるルーティングコンポーネント、および
（ｄ）前記通信コンポーネントと前記データストアとの間の対話を引き起こしデータの送信または受信に関連する通信機能を実施する通信関連命令を、アプリケーションが指定可能なプログラミングインタフェース
を備えることを特徴とするコンピュータ可読媒体。
【請求項２】
前記プログラミングインタフェースが、レジストリ内のエントリ生成を備える通信機能を実施するように適応されることを特徴とする請求項１に記載のコンピュータ可読媒体。
【請求項３】
前記プログラミングインタフェースが、前記複数のメッセージングプロバイダの１つのメッセージングプロバイダを使用したメッセージ送信を備える通信機能を実施するように適応されることを特徴とする請求項１に記載のコンピュータ可読媒体。
【請求項４】
前記プログラミングインタフェースが、前記データストア内のエントリ変更を備える通信機能を実施するように適応されることを特徴とする請求項１に記載のコンピュータ可読媒体。
【請求項５】
前記コンピュータ可読媒体が、ポータブル電子デバイスに組み込まれることを特徴とする請求項１に記載のコンピュータ可読媒体。
【請求項６】
（ｅ）前記データストア内のエントリにより示されるアドレスをポーリングして、ピアツーピアアプリケーションに関する通信の受信を望む宛先を識別するメッセージ送信コンポーネント
をさらに備える請求項１に記載のコンピュータ可読媒体。
【請求項７】
第１のピア上の第１のコンポーネントと第２のピア上の第２のコンポーネントとを有するアプリケーション間の通信方法であって、
（ａ）前記第１のコンポーネントから、前記第１のピア上の第１のストアアンドフォワードメッセージングクライアントにデータを与えること、
（ｂ）前記第１のストアアンドフォワードメッセージクライアントで複数のメッセージングプロバイダから少なくとも１つのメッセージングプロバイダを選択すること、
（ｃ）前記の少なくとも１つの選択したメッセージングプロバイダを使用して前記データを前記第２のピア上の第２のストアアンドフォワードメッセージングクライアントに送信すること、および
（ｄ）前記データを前記第２のストアアンドフォワードメッセージングクライアントから前記第２のコンポーネントに与えること
の動作を備えることを特徴とする方法。
【請求項８】
前記アプリケーションはマルチプレイヤゲームであり、データを与える前記動作（ａ）は前記ゲームにおけるプレイヤ動作を表すデータを与えることを特徴とする請求項７に記載の方法。
【請求項９】
前記データを送信する前記動作（ｃ）は、前記第１のストアアンドフォワードメッセージングクライアントからリレーサーバに前記データを送信し、前記リレーサーバから前記第２のストアアンドフォワードメッセージングクライアントにデータを送信することを特徴とする請求項７に記載の方法。
【請求項１０】
選択する前記動作（ｂ）は、ＩＭＡＰ、ＰＯＰ３、ＳＭＴＰ、ＳＭＳ、ＨＴＴＰ、ＴＣＰ／ＩＰおよびＭＭＳから成る集合におけるプロトコルに従って動作するメッセージングプロバイダを選択することを備えることを特徴とする請求項７に記載の方法。
【請求項１１】
データを与える前記動作（ａ）は、定義されたインタフェースを通してデータを与えることを備えることを特徴とする請求項７に記載の方法。
【請求項１２】
前記第１のストアアンドフォワードメッセージングクライアントが電子メールプログラムを備え、前記方法はさらに
（ｅ）前記第１のストアアンドフォワードメッセージクライアントでユーザ入力を受信してテキストベースのメッセージを送信すること、および
（ｆ）前記テキストベースのメッセージを前記複数のメッセージングプロバイダの１つの上で送信すること
の動作を備えることを特徴とする請求項７に記載の方法。
【請求項１３】
前記動作（ｄ）は、前記データが第２のアプリケーションに関連するとの識別に基づいて、前記第２のストアアンドフォワードメッセージングクライアントにより受信された少なくとも１つのメッセージを、第２のアプリケーションコンポーネントに選択的にルーティングすることを特徴とする請求項７に記載の方法。
【請求項１４】
（ａ）複数のメッセージングプロバイダ、
（ｂ）コンピュータ実行可能コンポーネントを有するコンピュータ可読媒体を備える前記複数のメッセージングプロバイダの少なくとも一部に接続した第１のピアであって、前記コンピュータ実行可能コンポーネントは
（i）前記複数のメッセージングプロバイダの少なくとも一部を使用してデータを送受信する第１の通信コンポーネントであって、前記第１の通信コンポーネントは、第１のプログラミングインタフェースを有し、前記第１のプログラミングインタフェースを通して、前記複数のメッセージングプロバイダの１つのメッセージングプロバイダを使用してデータが送信のために提供される可能性があり、前記複数のメッセージングプロバイダのメッセージングプロバイダからの情報がアプリケーションに渡される可能性があることを特徴とする第１の通信コンポーネント、
（ii）アプリケーションデータを生成および処理する第１のアプリケーションであって、前記第１のアプリケーションは、生成されたアプリケーションデータを前記第１のプログラミングインタフェースを通して渡し、前記第１のプログラミングインタフェースを通して処理するためにアプリケーションデータを受信するように適合されることを特徴とする第１のアプリケーション
を備えることを特徴とする第１のピア、
（ｃ）コンピュータ実行可能コンポーネントを有するコンピュータ可読媒体を備える前記複数のメッセージングプロバイダの少なくとも一部に接続した第２のピアであって、前記コンピュータ実行可能コンポーネントは
（i）前記複数のメッセージングプロバイダの少なくとも一部を使用してデータを送受信する第２の通信コンポーネントであって、前記第２の通信コンポーネントは、第２のプログラミングインタフェースを有し、前記第２のプログラミングインタフェースを通して、前記複数のメッセージングプロバイダの１つのメッセージングプロバイダを使用してデータが送信のために提供される可能性があり、前記複数のメッセージングプロバイダのメッセージングプロバイダからの情報がアプリケーションに渡される可能性があることを特徴とする第２の通信コンポーネント、
（ii）アプリケーションデータを生成および処理する第２のアプリケーションであって、前記第２のアプリケーションは、生成されたアプリケーションデータを前記第２のプログラミングインタフェースを通して渡し、前記第２のプログラミングインタフェースを通して処理するためにアプリケーションデータを受信するように適合されることを特徴とする第２のアプリケーション
を備えることを特徴とする第２のピア
を備えるピアツーピア通信システム。
【請求項１５】
前記第１のピアおよび前記第２のピアは、前記複数のメッセージングプロバイダの少なくとも１つにおけるアドレス可能でないコンピュータデバイスであることを特徴とする請求項１４に記載のピアツーピア通信システム。
【請求項１６】
前記複数のメッセージングプロバイダの少なくとも１つはストアアンドフォワードメッセージングプロバイダであることを特徴とする請求項１４に記載のピアツーピア通信システム。
【請求項１７】
前記複数のメッセージングプロバイダの少なくとも１つはリアルタイムメッセージングプロバイダであることを特徴とする請求項１４に記載のピアツーピア通信システム。
【請求項１８】
前記少なくとも１つのリアルタイム送信メッセージングプロバイダはＳＭＳプロトコルを使用することを特徴とする請求項１７に記載のピアツーピア通信システム。
【請求項１９】
前記ＳＭＳプロトコルを使用する前記少なくとも１つのメッセージングプロバイダに接続したウェブサービスをさらに備え、それにより前記メッセージングプロバイダは前記ウェブサーバを通して前記第１のピアおよび前記第２のピアに接続されることを特徴とする請求項１８に記載のピアツーピア通信システム。
【請求項２０】
前記少なくとも１つのリアルタイムメッセージングプロバイダはＩＭプロトコルを使用することを特徴とする請求項１７に記載のピアツーピア通信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ピアツーピア通信システムに係り、特にあるネットワークピア上のアプリケーションコンポーネントから別のネットワークピア上のアプリケーションコンポーネントにアプリケーションデータを送信するピアツーピア通信システムに関する。
【背景技術】
【０００２】
コンピュータネットワークは、データ通信に広く使用され、様々な位置のコンピュータデバイス間のデータ交換に依存する多数のビジネスおよび個人アプリケーションを提供するために使用される。インターネットは、広く使用される通信ネットワークの例である。上記ネットワークは、複数の相互接続されたサーバおよび他のデバイスを含み、それらに対してデータが送信され、またはそれらからネットワークに接続した他のデバイスによりデータが獲得される可能性がある。ネットワーク内部の特定のデバイスにネットワーク通信を向けることを可能とするため、それぞれのデバイスはネットワークアドレスを割り当てられる可能性がある。それぞれのアドレスは、一般に一意かつ固定的であり、特定のデバイスに対するアドレスを含むネットワーク上で送信される任意のメッセージは、そのデバイスに常にルーティングされる。
【０００３】
ネットワーク通信を利用する多数のアプリケーションユーザは、「ピア」としてネットワークに接続する。本コンテクストにおいて、「ピア」とはハードウェアおよびソフトウェアを含みうるプラットフォームを示し、上記ハードウェアおよびソフトウェアを通してしばしば１人のユーザによりネットワークへのアクセスが獲得される。結果として、サーバのような他のデバイスよりも多数のピアがネットワーク内に存在することがありうる。ネットワークは、一般に有限個の利用可能なアドレスを有するので、全てのピアが一意のネットワークアドレスを有するためのネットワークアドレスが不足することがよくある。
【０００４】
一意かつ固定的なアドレスを割り当てるのではなく、それぞれのピアは従来、ネットワークアドレス変換（ＮＡＴ）を実施するルータのようなデバイスを通してネットワークに接続する。ネットワーク上で送信されるメッセージのアドレスがルータとなるように、ルータは、一意かつ固定的なネットワークアドレスを有することができる。ルータは、サブネットワーク上で複数にピアに接続される。それぞれのピアは、サブネットワーク内部でのみ意味を有するアドレスを割り当てられる可能性がある。
【０００５】
ピアがネットワーク上の通信を目的としたメッセージを送信すると、ピアはそのサブネットワークアドレスをメッセージの送信元アドレスとして挿入することができる。ルータはサブネットワーク上でこれらのメッセージを受信し、それらをネットワークに転送する。メッセージの転送前に、ルータはピアのサブネットワークアドレスを、妥当なネットワークアドレスとして認識されるルータ自身のアドレスに変換する。
【０００６】
メッセージを処理するサーバおよび他のネットワークデバイスは、メッセージ内の上記アドレスを使用して、応答を元のメッセージの送信者に向けることができる。したがって、ルータは、ルータのサブネットワークを通して接続された任意のピアを宛先とする全ての応答を受信する。次いで、ルータはこれらメッセージをそのサブネットワーク上で転送するが、最初にそれぞれの入力メッセージにおけるアドレスを、上記メッセージの受信が意図されるピアのサブネットワークアドレスに変換する。このように、それぞれのピアはメッセージをネットワーク上で送信し、応答を受信することができる。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
しかしながら、ピアのアドレスは一意かつ固定的でない可能性があるため、ネットワークデバイスがピアとの通信を開始することは困難である。ピアとの通信を開始するために、別のピアまたはネットワークデバイスは、そのピアへのメッセージ送信に使用可能なアドレスを探索する必要があるであろう。
【０００８】
アドレス探索の必要性を回避する１つの方法は、ストアアンドフォワードメッセージングシステムを使用することである。ストアアンドフォワードメッセージングシステムは、ネットワーク内部で一意かつ固定的なアドレスを有するリレーサーバを利用する。ピア宛のメッセージは、リレーサーバに送信されることができ、リレーサーバはそのメッセージを記憶する。リレーサーバは、上記メッセージの宛先であるピアがピア宛の任意の記憶メッセージを要求するメッセージを送信することを待機する。このメッセージは、リレーサーバが応答をピアに向けるために使用可能なアドレスを含み、リレーサーバはピア宛の任意の記憶メッセージを上記メッセージへの応答として送信することができる。
【０００９】
ストアアンドフォワードシステムが動作するために、リレーサーバはメッセージの宛先である特定のピアを識別する方法を有さなければならない。ピアを識別するため、リレーサーバは自身のアドレッシングメカニズムを確立することができる。上記アドレスはネットワークアドレスとして使用されないので、リレーサーバはアドレス割当におけるネットワークアドレスの利用可能数制限により拘束されることはない。
【００１０】
電子メールは、広く使用されているストアアンドフォワードメッセージングシステムの例である。電子メールサービスの全てのユーザは、電子メールアドレスを有し、電子メールアドレスは、リレーサーバおよび他のピアの両方により使用され、メッセージをユーザが電子メールシステムにアクセスするピアにルーティングできる。
【００１１】
他のネットワークアドレッシングメカニズムが公知である。一部のメッセージングプロバイダは、ネットワークアドレスが全てのピアに割り当てられるネットワークを使用する。例えば、携帯電話システムは一意かつ固定的なアドレス（すなわち、電話番号）を全てのピアに割り当て、それによりＳＭＳフォーマットでのテキストメッセージを、リレーサーバの介入なしにあるピアから別のピアに送信することができる。
【００１２】
別の例として、インスタントメッセージングは、異なるアプローチを使用してピアに対するリアルタイムなメッセージ送信を与える。インスタントメッセージングフォーマットにおいて、メッセージを受信可能なピアは、自分自身をメッセージングプロバイダが運用するリレーサーバに対して識別する。メッセージをピアに送信可能なアドレスをリレーサーバが得ると、このピアとの通信を望む他のピアに上記アドレスを与えることができる。
【課題を解決するための手段】
【００１３】
本発明は、ピアツーピア通信に関する。１つの態様において、プログラミングインタフェースは、データを送受信可能なそれぞれのピア上の通信コンポーネントに対して与えられる。上記インタフェースは、ピアツーピア通信を要求するアプリケーションプログラムの作成を促進する。
【００１４】
通信コンポーネントは、メッセージングプロバイダを使用してメッセージを送受信することができ、上記メッセージングプロバイダは、ピア上でピアツーピアアプリケーション間のデータ通信以外の理由でアクセスされ、それにより通信用リソースを大幅に消費せずにピアツーピアアプリケーションを実施することができる。これは、スマートフォン、ＰＤＡおよびポケットＰＣのようなリソースが限定されたデバイスに対しては重要であろう。既に確立したアドレッシングメカニズムを使用可能とすることにより、既存のメッセージングプロバイダを使用してピアツーピアアプリケーションデータを送信すると、通信も簡略化される。
【００１５】
別の態様において、通信コンポーネントは、複数のメッセージングプロバイダから受信したメッセージを集計すること、または複数の利用可能なメッセージングプロバイダからメッセージングプロバイダを選択してメッセージを送信することができる。本構造により、例えば様々な送信特性を提供するメッセージングプロバイダを使用して同一アプリケーションに異種のメッセージを伝達可能とすることで、様々なアプリケーションのニーズを満たすか、または同一アプリケーションの様々な時点での様々なニーズを満たすような、様々な特性を有するサービスを提供するメッセージングプロバイダが利用可能となる。
【００１６】
前述の要約は、本発明に対する限定ではない。本発明は添付請求項により定義する。
付属図面は正しい縮尺で描くようには意図していない。図面では、様々な図で示したそれぞれの同一またはほぼ同一の構成要素を同じ番号で表す。明快さのため、全ての図面において全ての構成要素にラベル付けするということはない。
【発明を実施するための最良の形態】
【００１７】
本発明者は、ピアツーピア通信に依存するアプリケーションの提供において大幅な利点が得られることを認識している。上記アプリケーションは、データを交換するための単純な方法を与えることにより、ピアツーピア環境に対してアプリケーションは、より容易に開発されることができる。
【００１８】
以下でより詳細に説明するように、プログラミングインタフェースが与えられ、それによりアプリケーションプログラムは、既存のメッセージングプロバイダを使用してデータを送受信することができる。上記インタフェースにより、それぞれのピア上で実行されるアプリケーションは、アプリケーションがデータストアに対して情報を記憶および取り出すことができるのとほぼ同じように他のピアとデータを交換することができる。それによりアプリケーション開発者は、ネットワーク通信に関連するネットワークアドレッシングまたは複雑性を理解する必要性から解放される。さらなる利点として、既存のメッセージングプロバイダを使用することにより、ピアツーピア通信に基づくアプリケーションのサイズを大幅に削減することができる。上記サイズ削減は、リソースが制限されたシステムにおいては特に重要であろう。従って、メッセージングプロバイダに容易にアクセス可能とするアプリケーションプログラミングインタフェースを与えることにより、携帯型電子デバイスに対するピアツーピアアプリケーションの開発が促進される。
【００１９】
さらに、プログラミングインタフェースは、通常はそのメッセージングプロバイダによりマスクされるアドレスを有するデバイスとの通信を促進することができる。例えば、携帯メッセージングプロバイダが使用する現行のアドレッシング技術は、アプリケーションから特定のアドレスへの通信に関する便利なメカニズムを与えない。
【００２０】
本発明の実施形態は、図１に示すピアツーピアネットワーク１００において使用される可能性がある。ピアツーピアネットワーク１００は、例えば１１０Ａおよび１１０Ｂのような複数のピアを有する。それぞれのピアは、デスクトップコンピュータであるか、または任意の他のネットワーク可能なコンピュータデバイスであることができる。１１０Ａおよび１１０Ｂのようなピアは、メッセージングプロバイダ１２０を通して通信することができる。本例において、メッセージングプロバイダ１２０は、ストアアンドフォワード型の電子メールシステムが与えられる。
【００２１】
本例において、メッセージングプロバイダ１２０は、インターネット１４０を使用して電子メールメッセージを送信する。ピア１１０Ａおよび１１０Ｂの各々を、ネットワークアドレス変換を実施し、従って固定インターネットアドレスを有さないデバイスを通して、インターネット１４０に接続することができる。本例において、ピア１１０Ａおよび１１０Ｂは、ネットワークアドレス変換を実施するルータ１１２Ａおよび１１２Ｂを通して接続される。
【００２２】
メッセージングプロバイダ１２０は、リレーサーバ１３０を含む。本例において、リレーサーバ１３０は、メールサーバである。リレーサーバ１３０は、任意のピアがそれとの通信を開始できるように、固定のインターネットアドレスを有することができる。
【００２３】
ピア１１０Ａおよび１１０Ｂのそれぞれは、データおよびコンピュータ実行可能命令が記憶されるコンピュータ可読媒体を含むことができる。ピア１１０Ａおよび１１０Ｂのそれぞれにあるコンピュータ実行可能命令の一部は、メッセージングクライアント２３０（図２）を実施することができる。メッセージングクライアント２３０を使用して、メッセージングプロバイダ１２０を使用した電子メールメッセージの送受信を行うことができる。例えば、ピア１１０Ａ上のメッセージングクライアント２３０は、送信電子メールメッセージと上記メッセージの送信先電子メールアドレスとを指定するユーザ入力を受信することができる。メッセージングクライアントは、次いでルータ１１２Ａを通してメッセージをリレーサーバ１３０に送信することができる。電子メールメッセージの宛先がピア１１０Ｂを通してネットワークにアクセスするユーザである場合、ピア１１０Ｂ上のメッセージングクライアント２３０（図２）は、ルータ１１２Ｂを通してリレーサーバ１３０にアクセスし、サーバ１３０から電子メールメッセージを取り出すことができる。このように、電子メールメッセージをピア１１０Ａからピア１１０Ｂに送信することができる。逆のステップを取ってメッセージをピア１１０Ｂからピア１１０Ａに送信することができる。
【００２４】
ピア１１０Ａ上で実行されるアプリケーションコンポーネントとピア１１０Ｂ上で実行されるアプリケーションコンポーネントとの間でアプリケーションデータを共有することを容易にするため、ピア１１０Ａ上の通信クライアント２３０はアプリケーションデータを含むメッセージをリレーサーバ１３０に送信することができる。同様に、ピア１１０Ｂ上の通信クライアント２３０は、アプリケーションデータを含むメッセージをリレーサーバ１３０から取り出すことができる。通信クライアント２３０は次いで上記データを、ピア１１０Ｂ上の受信側アプリケーションコンポーネントに対して利用可能とすることができる。このように、仮想リンク１１４は、ピア１１０Ａ上のピアアプリケーションコンポーネントとピア１１０Ｂ上のピアアプリケーションコンポーネントとの間に確立されることができる。同様な仮想リンクは、メッセージングプロバイダ１２０に対するアクセスを有する任意の複数のピア間に確立されることができる。
【００２５】
ピアツーピアネットワーク１００は、アプリケーションデータの送信に使用可能な他のメッセージングプロバイダも含むことができる。図１の例において、メッセージングプロバイダ１６０を示す。本実施形態においては、メッセージングプロバイダ１６０は、携帯電話システムを使用してメッセージを送信する。メッセージングプロバイダ１６０は、アクセスポイント１７０Ａおよび１７０Ｂのような複数のアクセスポイントを操作する。アクセスポイントをメッセージングバックボーン１８０により相互接続する。本例において、メッセージングプロバイダ１６０は、携帯電話会社により管理されるネットワークであり、テキストメッセージを含む多種のメッセージを送信することができる。メッセージングプロバイダ１６０のユーザは、ピアを通してネットワークにアクセスする。上記ピアは、携帯電話、スマートフォン、またはメッセージの送受信を備えた他のデバイスであることができる。本例において、ピア１５０Ａおよび１５０Ｂは、ＳＭＳフォーマットでメッセージを受信するよう構築した携帯型ハンドヘルド電子デバイスとして示される。
【００２６】
メッセージングプロバイダ１２０および１６０は、様々なネットワークピア上で実行されるアプリケーションコンポーネント間でデータを通信するために使用可能なメッセージングプロバイダの例である。任意の適切なメッセージングプロバイダが使用可能である。本明細書で説明されたピア上で相対的に少量のリソースを使用するピアツーピア通信に対するアプローチの例は、携帯型コンピュータデバイスに基づくピアに対して特に望ましいであろう。上記デバイスは、一般に、ＩＭＡＰ、ＰＯＰ３、ＳＭＴＰ、ＳＭＳ、ＨＴＴＰ、ＴＣＰ／ＩＰおよびＭＭＳのようなプロトコルに従って動作するメッセージングプロバイダに接続する。
【００２７】
メッセージングプロバイダは、ウェブサービスまたは他の適切な手段を通して間接的にアクセスされる可能性がある。ネットワーク１００において、インターネット１４０に接続したデバイスによるメッセージングプロバイダ１６０へのアクセスは、サーバ１９０によりウェブサービスを通して与えられる。サーバ１９０は、メッセージングプロバイダ１６０のバックボーン１８０に接続される。サーバ１９０は、１５０Ａおよび１５０Ｂのような、メッセージングプロバイダ１６０によりバックボーン１８０に接続された任意のピア宛てのメッセージを送信することができる。さらに、サーバ１９０は、メッセージングプロバイダ１６０により認識されるネットワークアドレスを有し、メッセージングプロバイダ１６０を通して接続されたピア１５０Ａまたは１５０Ｂからメッセージを受信することができる。
【００２８】
サーバ１９０は、インターネット１４０への接続を通してピア１１０Ａおよび１１０Ｂのようなピアにも接続され、インターネット１４０に接続された任意のピアとメッセージを交換することができる。上記ピアは、サーバ１９０により与えられるウェブサービスを使用し、メッセージングプロバイダ１６０を使用してメッセージを送受信することができる。
【００２９】
サーバ１９０は、メッセージングプロバイダ１２０および１６０を相互接続し、送信されたメッセージを１つのメッセージングプロバイダを使用して、他のメッセージングプロバイダ上でメッセージを受信するピアに転送することができる。インターネット１４０およびバックボーン１８０間のこのクロス結合により、インターネット１４０に接続されたピアからメッセージングプロバイダ１６０に接続されたピアにデータを送信することができる。仮想リンク１５４は、ピア１１０Ｂおよび１５０Ｂの間の通信が可能であることを示す。同様な仮想リンクを使用して、異なるメッセージングプロバイダに接続されたピア間でアプリケーションデータを送信することができる。
【００３０】
図２を参照して、メッセージングクライアント２３０のソフトウェアアーキテクチャが示される。上記メッセージングクライアントは、通信を望む任意のピア上で使用される可能性がある。メッセージングクライアント２３０は、アプリケーション２１０Ａ．．．２１０Ｄのようなアプリケーションを実行するピア上で使用される可能性がある。上記ピアは、電子メールユーザインタフェース２５０でプログラムされ、電子メール通信を与えることもできる。
【００３１】
メッセージングクライアント２３０は、メッセージングプロバイダ２２０Ａ、２２０Ｂ、２２０Ｃおよび２２０Ｄのような複数のメッセージングプロバイダを使用して通信を促進する。例えば、上記メッセージングプロバイダは、電子メールメッセージングシステムへのアクセスを与えるインターネットサービスプロバイダ、ＳＭＳメッセージングシステムへのアクセスを与える携帯電話会社、あるいは現在公知であるかまたは将来開発される任意の他のメッセージングプロバイダであることができる。上記メッセージングプロバイダは、商用的な実体である必要はなく、ネットワークピアがメッセージを送信可能な任意のメカニズムを「メッセージングプロバイダ」と見なすことができる。また、メッセージングプロバイダを単一の実体により確立する必要もない。「メッセージングプロバイダ」は、様々な実体により所有または操作される、対話してメッセージを送信するコンポーネントの集合であることができる。
【００３２】
示された実施形態において、メッセージングクライアント２３０は、ピアと関連付けられたコンピュータ可読媒体上に記憶された複数のコンピュータ実行可能命令として実施される。デスクトップコンピュータまたは他のコンピュータデバイス上で実行するソフトウェアとしてピアが実施される実施形態において、コンピュータ可読媒体は、コンピュータデバイス内のコンピュータメモリであることができる。コンピュータ実行可能命令は、任意の所望のプログラミング言語で準備される可能性があり、コンピュータ可読媒体内に記憶する前に機械語または実行可能コードに変換される可能性があり、あるいは翻訳され、またはＪＩＴコンパイラに適用され実行時に実行可能コードを導出される可能性がある。
【００３３】
図２において、メッセージングクライアント２３０を構成するコンピュータ実行可能命令は、複数のモジュールとして編成される可能性があり、上記モジュールの各々はメッセージングクライアントに関連付けられた機能を実施する。それぞれのモジュールは、モジュール生成に使用されるプログラミング言語の構成子に従い、他のモジュールと対話することができる。例えば、それぞれのモジュールは、あるモジュールの機能を別のモジュールから呼び出せるように他のモジュールに公開した機能呼び出しを含むことができる。または、モジュールは、リンキングの一部として解決されるあるモジュールから別のモジュールへの参照を有する１つの実行可能ファイルにリンクすることができる。更なる代替手段として、それぞれのモジュールは、実行時に動的にリンクされるモジュールライブラリの要素であることができる。従って、モジュールの各々が実施される特定の形態およびモジュールが対話する特定の形態は本発明には重要ではなく、任意の適切な方法を使用することができる。
【００３４】
図２に示されるモジュールの１つは、メッセージングアグリゲータ２３２である。メッセージングアグリゲータ２３２は、複数のメッセージングプロバイダ２２０Ａ．．．２２０Ｄに対するインタフェースとして動作する。メッセージングアグリゲータ２３２は、インボックス２３６とアウトボックス２３４を含む。メッセージングアグリゲータ２３２は、公知の技術を使用してそれぞれのメッセージングプロバイダと対話するように構築される可能性がある。しかしながら、メッセージングアグリゲータ２３２は、複数のメッセージングプロバイダと対話するメカニズムを提供する。示された実施形態において、メッセージングアグリゲータ２３２には、メッセージを任意のメッセージングプロバイダから受信可能なインボックス２３６と、メッセージを任意のメッセージングプロバイダを使用して送信可能なアウトボックス２３６とが含まれる。
【００３５】
インボックス２３６は、メッセージングプロバイダ２２０Ａ．．．２２０Ｄの全てからメッセージを受信し、それらを電子メールユーザインタフェース２５０または２１０Ａ．．．２２０Ｄのようなアプリケーションにより処理されるまでメモリにバッファすることができる。メッセージは、メッセージ源の識別子とともに記憶される可能性があり、上記メッセージ源の識別子は、それを通してメッセージが受信されたメッセージングプロバイダの識別子を含むことができる。上記識別子は、明示的に記憶されるかまたは記憶された他の情報から暗示される可能性がある。例えば、メッセージは、メッセージ源であるアドレスの識別子を含むことができ、その識別子はメッセージを送信したメッセージングプロバイダを示すことができる。
【００３６】
アウトボックス２３４は、メッセージを電子メールユーザインタフェース２５０またはアプリケーション２１０Ａ．．．２１０Ｄから受信し、それらが送信されるまでメモリにバッファすることができる。アウトボックス２３４は、任意のメッセージングプロバイダ上で送信されるメッセージをバッファすることができる。送信されるそれぞれのメッセージは、それが送信されるべきメッセージングプロバイダの識別子のようなメッセージルーティング情報とともに記憶される可能性がある。上記識別子は、メッセージに明示的に含まれるか、または例えば上記メッセージが送信されるメッセージングプロバイダを特定するフォーマットでメッセージの宛先アドレスを特定することにより、暗示的に含まれる可能性がある。
【００３７】
メッセージルーティング情報の提供を促進するため、メッセージングクライアント２３０は、メッセージルーティング情報モジュール２４２が含まれる。メッセージルーティング情報モジュール２４２は、それぞれの宛先に対するルーティング情報に関連する宛先のディレクトリを含むことができる。ルーティング情報は、その宛先にメッセージを送信するのに有用な１つまたは複数のアドレスを含むことができる。ルーティング情報は、メッセージをその宛先に伝達可能なメッセージングプロバイダを明示的に指定することができる。ルーティング情報を代替または追加として、記憶したアドレスの形態に基づいて暗示的に与えることができる。一部の実施形態においては、メッセージルーティング情報モジュール２４２は、単一アドレスに対する複数の送信モードに関するルーティング情報を含むことができ、それによりメッセージングクライアント２３０が配信されるメッセージの形態に対して最適なメッセージングプロバイダを選択すること、または最初に選択されたメッセージングプロバイダ経由でメッセージを配信できない場合に代替メッセージングプロバイダを使用することができる。アウトボックス２３４は、ルーティング情報を使用して、メッセージングプロバイダ２２０Ａ．．．２２０Ｄの１つを使用して送信メッセージをフォーマットすることができる。
【００３８】
図２は、コンピュータアプリケーション間のピアツーピアメッセージを促進するメッセージングクライアント２３０の追加モジュールを示す。示された実施形態において、メッセージングクライアント２３０は、メッセージディスパッチャ２３８、レジストリ２４０ならびに、メッセージングクライアント２３０および電子メールユーザインタフェース２５０またはアプリケーション２１０Ａ、２１０Ｂ、２１０Ｃおよび２１０Ｄの間の通信を促進するアプリケーションプログラミングインタフェース（ＡＰＩ）２４４が含まれる。
【００３９】
本例において、アプリケーション２１０Ａ、２１０Ｂ、２１０Ｃおよび２１０Ｄは、ピア上で実行可能な任意のアプリケーションを表す。アプリケーションは、ワードプロセッサまたはスプレッドシートのようなデータ処理アプリケーションであることができる。本例において、データ処理アプリケーションは、別のピアからデータを取得または別のピアにデータを送信するピアツーピアモードにおいて機能される可能性がある。データは、対応するデータ処理アプリケーション、あるいはデータを生成または使用する任意の他のアプリケーションから送受信される可能性がある。
【００４０】
しかしながら、本発明は、データ処理アプリケーションに関連した使用に限定されず、アプリケーション２１０Ａ、２１０Ｂ、２１０Ｃおよび２１０Ｄは、公知であるかまたは将来開発されるかに関わらず、ピアツーピアモードにおいて動作可能な任意のアプリケーションであることができる。例えば、アプリケーション２１０Ａ、２１０Ｂ、２１０Ｃおよび２１０Ｄの一部または全部は、ゲームまたは、娯楽に利用する他のピアツーピアアプリケーションであることができる。アプリケーションがゲームである実施形態において、ピアツーピアネットワーク１００内部のピアはそれぞれ、ゲーミングアプリケーションのコンポーネントを備え付けられる可能性がある。ピア間で送信されるデータは、ゲームまたは他のゲーミング情報における「動き」を表すことができる。
【００４１】
電子メールユーザインタフェース２５０は、メッセージングクライアント２３０が組み込まれたピアの人間のユーザに対してユーザインタフェースを提示するソフトウェアが含まれる。インタフェースの正確な形態は、ピアのコンピュータプロセッサのハードウェアコンポーネントに依存しうるが、マウスまたは他のポインティングデバイスにより起動されるディスプレイ上に提示されるグラフィカルユーザインタフェース、キーボードによりアクセスされるテキストインタフェース、またはオーディオインタフェースによりアクセスされる自然言語インタフェースのようなインタフェースを含むことができる。電子メールユーザインタフェース２５０は、さらに、送信される電子メールメッセージの内容とそのメッセージに対するルーティング情報とを指定する、人間のユーザからのテキストまたは他の入力を受信する。
【００４２】
電子メールユーザインタフェース２５０ならびにアプリケーション２１０Ａ、２１０Ｂ、２１０Ｃおよび２１０Ｄの各々は、コンピュータ実行可能命令を含む１つまたは複数のコンポーネントとして実施される可能性がある。コンピュータ実行可能命令は、任意の適切なコンピュータ言語であることができる。上記アプリケーションは、当技術分野で公知であり、電子メールユーザインタフェース２５０ならびにアプリケーション２１０Ａ、２１０Ｂ、２１０Ｃおよび２１０Ｄは、公知のプログラミング技術を使用して構築される可能性がある。
【００４３】
電子メールユーザインタフェース２５０ならびにアプリケーション２１０Ａ、２１０Ｂ、２１０Ｃおよび２１０Ｄは、それらがＡＰＩ２４４を使用してメッセージを送受信する点で、当技術分野で公知である従来の電子メールクライアントソフトウェアおよびアプリケーションとは異なる。ＡＰＩ２４４は、アプリケーション２１０Ａ、２１０Ｂ、２１０Ｃおよび２１０Ｄが別のピア上のアプリケーションコンポーネントに対してデータを送受信するためのメカニズム、および電子メールユーザインタフェース２５０が他のピア上の電子メールクライアントと電子メールメッセージを送受信するためのメカニズムを与える。ＡＰＩ２４４は、上記プログラムがメッセージングクライアント２３０により実施される任意のデータ通信機能を実施するソフトウェアを含む必要性がないので、ＡＰＩ２４４は、アプリケーションのプログラミングと、電子メールクライアントの生成とを簡略化する。
【００４４】
いくつかの実施形態において、ＡＰＩ２４４は、データストアに対するインタフェースと同じ形態であるインタフェースをアプリケーション２１０Ａ、２１０Ｂ、２１０Ｃおよび２１０Ｄに与える。データストアは共通的にアプリケーションプログラム内で使用されるので、ＡＰＩ２４４は、コンピュータプログラマが良く知られた形態の単純な命令を使用してピアツーピア通信をアプリケーションに組み込むためのメカニズムを与える。ＡＰＩ２４４は、さらにメッセージの送受信のような電子メールクライアントに従来見られる機能を電子メールユーザインタフェース２５０に与え、それにより複数のメッセージングプロバイダを使用してメッセージが送信されうる場合でも、電子メールユーザインタフェース２５０は、従来の電子メールクライアントソフトウェアより単純であることができる。
【００４５】
ＡＰＩ２４４は、任意の適切なコンピュータ言語でのコンピュータ実行可能命令を含むモジュールであることができる。本実施形態において、ＡＰＩ２４４は、動的に電子メールユーザインタフェース２５０ならびにアプリケーション２１０Ａ、２１０Ｂ、２１０Ｃおよび２１０Ｄにリンクすることができ、その結果、ＡＰＩ２４４で実施された機能は、電子メールユーザインタフェース２５０ならびにアプリケーション２１０Ａ、２１０Ｂ、２１０Ｃおよび２１０Ｄから呼び出すことができる。リンクにより、アプリケーション２１０Ａ、２１０Ｂ、２１０Ｃおよび２１０Ｄならびに電子メールユーザインタフェース２５０内部の機能をＡＰＩ２４４内部から呼び出すことができる。
【００４６】
本実施形態において、ＡＰＩ２４４は、アプリケーション２１０Ａ、２１０Ｂ、２１０Ｃおよび２１０Ｄならびに電子メールユーザインタフェース２５０から呼び出し可能な複数の通信機能を含む。上記機能の１つ（“ＳＥＮＤ”機能）は、ピアがアクセスを有するメッセージングプロバイダを使用してデータを送信することができる。データを送信するため、ＡＰＩ２４４は、データをアウトボックス２３４に与える。
【００４７】
ＳＥＮＤ機能は、同期または非同期に動作することができる。同期的な動作に関して、上記機能は、選択したメッセージングプロバイダによりメッセージが送信されるときに返送されることができ、それにより送信が完了するまで呼び出しプログラムの実行をブロックする。非同期的な動作に関して、ＳＥＮＤ機能は、呼び出しプログラムの実行をブロックしないように動作することができる。
【００４８】
アウトボックス２３４は、メッセージを適切な形で所望のメッセージングプロバイダに与えることができる。例えば、アウトボックス２３４は、宛先、送信者アドレス、タイムスタンプ、または他の所望の情報を指定するヘッダでメッセージをフォーマットし、上記データをメッセージボディに加えることができる。
【００４９】
ＡＰＩ２４４により与えられるＳＥＮＤ機能は、そのパラメータの１つとして情報の受信者の識別子を受け取ることができる。受信者は、任意の適切な方法で識別される可能性がある。１つの実施形態において、受信者は、名前付きの宛先として特定され、メッセージングプロバイダの１つを介して接続されるピアに対するアドレスにより指定される必要はない。アウトボックス２３４は、適切なアドレスを、メッセージングプロバイダ２２０Ａ．．．２２０Ｄの１つにより認識されるフォーマットで、メッセージングルーティング情報モジュール２４２内のレコードから決定することができる。このように、アプリケーション情報は、ピアのアドレスを使用するようにアプリケーションコンポーネントがプログラムされる必要なしに、１つのピア上のアプリケーションコンポーネントから、別のピア上のアプリケーションコンポーネントに送信されることができる。
【００５０】
上記メッセージがアプリケーションコンポーネントの実行するピアに到達した際に、上記メッセージを上記宛先アプリケーションコンポーネントに配信することを促進するために、メッセージングクライアント２３０は、送信前にピアアプリケーション間の通信データに識別子をタグ付けするよう構築される可能性がある。例えば、ＡＰＩ２４４内部のＳＥＮＤ機能は、データをアウトボックス２３４に渡す前に、ピアツーピア通信用のデータを表すものとしてデータを識別するアプリケーションタグを添付することができる。上記アプリケーションタグは、データの発生元であるアプリケーションおよび／またはデータの宛先であるアプリケーションも識別することができる。または、電子メールユーザインタフェース２５０により処理される電子メールメッセージを表すものとしてデータを識別するように、データはアプリケーションタグがタグ付けされる可能性がある。
【００５１】
アプリケーション２１０Ａ、２１０Ｂ、２１０Ｃおよび２１０Ｄの１つに対するデータを含むメッセージングプロバイダ２２０Ａ，．．．，２２０Ｄの１つでメッセージを受信すると、通信クライアント２３０は、アプリケーションタグを使用して適切なアプリケーションに対するデータ配信を管理することができる。図２の実施形態において、メッセージディスパッチャ３２８は、メッセージをアウトボックス２３４から取り出し、ＡＰＩ２４４を通してそれらを宛先の受信アプリケーションに転送する。
【００５２】
メッセージディスパッチャ２３８は、インボックス２３６内のメッセージを監視するコンピュータ実行可能命令を備えるコンポーネントであることができ、受信メッセージ内のアプリケーションタグに基づいて、メッセージ内のデータを必要に応じて電子メールユーザインタフェース２５０またはアプリケーション２１０Ａ、２１０Ｂ、２１０Ｃおよび２１０Ｄの１つに転送する。配信は、ＡＰＩ２４４を通してデータを受信アプリケーションのコンポーネントに提示するメッセージディスパッチャ２３８により実現される可能性がある。
【００５３】
アプリケーションデータを含むそれぞれのメッセージが受信されると、メッセージディスパッチャ２３８は、複数のアプリケーション２１０Ａ、２１０Ｂ、２１０Ｃおよび２１０Ｄのうちどれが上記メッセージからデータを受信するかを決定する。説明した実施形態において、レジストリ２４０は、メッセージディスパッチャ２３８により維持され、データを受信可能であるアプリケーションを追跡する。上述のように、メッセージ内のデータの受信アプリケーションを識別するアプリケーションタグを、送信前にデータに加えることができる。アプリケーションタグは、電子メールデータを含むメッセージを同様に識別することができ、それによりメッセージディスパッチャ２３８は同様に電子メールデータを電子メールユーザインタフェース２５０に送信することができる。
【００５４】
レジストリ２４０は、メッセージディスパッチャ２３８により使用される情報を含むことができ、メッセージングディスパッチャ２３８は、上記情報を使用して、アプリケーションタグに基づいて情報を受信者アプリケーションに渡す。例えば、それぞれのアプリケーションは、機能を与えることができ、その機能を通してデータを受信する。本機能の名前または他の識別子は、アプリケーションタグに関連してレジストリ２４０に記憶される。メッセージディスパッチャ２３８は、インボックス２３６内のメッセージにあるアプリケーションタグを読み、そのアプリケーションタグに対するレジストリ２４０内のエントリを識別することができる。レジストリ２４０内のエントリの一部として、上記アプリケーションに対する機能が与えられる可能性がある。メッセージディスパッチャ２３０は、インボックス２３６からメッセージを削除して、レジストリ２４０内で指示されるようにアプリケーションに対して機能を呼び出すことができる。電子メールユーザインタフェース２５０に向けたメッセージに対して、上記メッセージからのデータは、レジストリ２４０内で指示される電子メールユーザインタフェース２５０内の機能を通して同様に与えられる可能性がある。
【００５５】
上述のように、インボックス２３６内のメッセージからのデータは、メッセージディスパッチャ２３８により受信アプリケーションに配信される。データはアプリケーションに配信される必要はない。それぞれのアプリケーションは、データを引き出すことができる。プル型アーキテクチャを実施するため、メッセージディスパッチャ２３８は、アプリケーション２１０Ａ，．．．，２１０Ｄまたは電子メールユーザインタフェース２５０により呼び出し可能な「ＲＥＣＩＥＶＥ」機能を含むことができる。上記機能は、インボックス２３６内のメッセージを検査して、ＲＥＣＩＥＶＥ機能を呼び出すアプリケーションに対するデータを含むメッセージを識別することができる。アプリケーションタグは、インボックス２３６内のメッセージを宛先アプリケーションに一致させるために使用されてもよいが、任意の適切な手段が使用されてもよい。
【００５６】
ＡＰＩ２４４は、メッセージルーティング情報モジュール２４２に記憶される情報を管理する機能のような他の通信機能を含むようにプログラムされてもよい。例えば、ＡＰＩ２４４は、メッセージルーティング情報モジュール２４２内のレコードを追加または削除する機能でプログラムされてもよい。上記機能は、アプリケーションがデータ交換を行うピアツーピアネットワーク１００内のピアを指定する上記のユーザ入力を受信するアプリケーション２１０Ａ，．．．，２１０Ｄの１つにより呼び出されてもよい。逆に、アプリケーションは、ＡＰＩ２４４内部の機能を呼び出してデータ構造３００内のレコードを、そのレコード内で指定したアドレスを通して到達可能なピアとの通信をもはや望まないときに、削除することができる。データ構造３００内のレコードは、電子メールユーザインタフェース２５０による機能呼び出しにより同様に追加または削除される可能性がある。
【００５７】
ＡＰＩ２４４は、データ構造３００内の任意のレコード情報を編集するために呼び出し可能な機能を含むことができる。ＡＰＩ２４４は、アプリケーションにデータ構造３００内の特定レコードを検索可能とする機能を含むこともできる。データ構造内部のレコードを追加、削除、編集または検索する機能は公知である。したがって、ＡＰＩ２４４内部のこれら機能は、公知であるかまたは将来開発されるかに関わらず、従来のプログラミング技術を使用して実施される可能性がある。
【００５８】
ＡＰＩ２４４は、メッセージングクライアント２３０を管理する他の機能性を与えることができる。例えば、ＡＰＩ２４４は、メッセージディスパッチャ２３８で登録するためにアプリケーションが呼び出し可能な機能を与えることができる。上記機能は、登録機能を呼び出すアプリケーションに対するアプリケーションタグを含むレコードを、レジストリ２４０内に置くことができる。登録機能は、アプリケーションに対するアプリケーションタグに加えて、アプリケーションに対するエントリポイントを記憶することができる。メッセージディスパッチャ２３８は、上記エントリポイントを使用して、そのアプリケーションに向けたメッセージからデータを送信することができる。
【００５９】
図３を参照する。メッセージルーティング情報モジュール２４２の更なる詳細を示す。メッセージルーティング情報モジュール２４２は、任意の適切な形のデータ構造として実施される可能性がある。図３は、使用可能なデータ構造の例を示す。データ構造３００は、メッセージクライアント２３０が実行されるピアに関連付けられるコンピュータ可読メモリに記憶される可能性がある。
【００６０】
図３の例は、データ構造３００にはレコード３１０Ａ、３１０Ｂおよび３１０Ｃのような複数のレコードが含まれることを示す。それぞれのレコードは、複数のフィールドを含むことができ、その中でレコード３１０Ｃ内のフィールド３２０Ｃ、３２２Ｃおよび３２４Ｃに採番してある。
【００６１】
フィールド３２０Ｃは、宛先を記憶する。宛先は、符号化識別子によりテキスト文字列として記憶するか、または任意の他の適切な方法でテキスト文字列として記憶される可能性がある。宛先は、任意のメッセージングプロバイダにより使用されるアドレスである必要はない。例えば、宛先は人間のユーザまたはアプリケーションコンポーネントとして指定されてもよい。
【００６２】
フィールド３２２Ｃは、メッセージングプロバイダを示し、そのメッセージングプロバイダ上で、フィールド３２０Ｃ内で指示される宛先にメッセージが送信される可能性がある。メッセージングプロバイダを表現する任意の適切な方法が使用される可能性があり、その方法は例えば、メッセージングプロバイダの名前、メッセージングプロバイダに関連付けられたコード、またはメッセージングプロバイダにアクセスするためのポートである可能性がある。
【００６３】
フィールド３２４Ｃは、アドレスを含み、そのアドレスにより、フィールド３２０Ｃ内で指示される宛先がフィールド３２２Ｃ内で指示されるメッセージングプロバイダを使用してアクセスされる可能性がある。
【００６４】
データ構造３００は、宛先フィールドにあるものと同じ値を有する複数のレコードを含むことができ、同じ宛先が複数のメッセージングプロバイダを使用してアクセスされてもよいことを示す。または、データ構造３００内のレコードは、指示されたものより多くのフィールドを有することができ、それにより複数のメッセージングプロバイダを宛先に対して指定することができる。
【００６５】
図４を参照して、データをピアツーピア通信の一部として送信可能なプロセスを示す。本例において、ストアアンドフォワードメッセージングシステムを運用するメッセージングプロバイダを使用してデータが送信されるが、任意の適切なメッセージングプロバイダが使用されてもよい。図４のプロセスは、データを送信するアプリケーション内部で実施されるサブプロセス４１０を含む。ブロック４１２において、アプリケーションは送信データを生成する。ブロック４１２は、アプリケーションによる従来の処理を表すことができる。例えば、ワードプロセッシングアプリケーションにおいて、プロセッサブロック４１２は、任意の適切な方法で取得可能なユーザ入力を取得することを含む。
【００６６】
ブロック４１４において、アプリケーションは、ＡＰＩ２４４内部でＳＥＮＤ機能の呼び出しを行うことにより送信プロセスを開始する。ブロック４１４において行われたＡＰＩ２４４の呼び出しは、宛先と送信データとを識別するパラメータをＳＥＮＤ機能に渡すことを含む。本例において、宛先情報は、上記データをリモートピア上で処理するアプリケーションのアプリケーションタグを指定することにより通信を受信するピア内の別のアプリケーションコンポーネントを識別する。
【００６７】
次いで、サブプロセス４２０は、メッセージングクライアント２３０内部で実施される。ＡＰＩ２４４のＳＥＮＤ機能の呼び出しがブロック４１４において行われることにより、メッセージルーティング情報モジュール２４２へのアクセスが行われる。ブロック４１４において行われたＡＰＩの呼び出しで指定された宛先に関連付けられたルーティング情報は、データ構造３００から取り出される。上記情報は、データの受信が意図されるピアに関連付けられたメッセージングプロバイダにより認識されたメッセージングプロバイダおよびアドレスを指定する。ピアのアドレスは、ピアのネットワークアドレスである必要はなく、メッセージングプロバイダにより認識される任意のアドレスであることができる。例えば、ストアアンドフォワードメッセージングプロバイダが使用されると、メッセージは、リレーサーバに最初に送信される可能性があり、上記リレーサーバからメッセージを取り出すピアは、上記メッセージの送信に使用されるネットワーク上でアドレス指定可能とならない可能性がある。
【００６８】
ブロック４２４において、メッセージングプロバイダが選択される。ブロック４１４において呼び出されるＳＥＮＤ命令に対するパラメータとして指定される宛先に対して１つのエントリがデータ構造３００内に存在する場合、上記レコード内で指定されるメッセージングプロバイダがブロック４２４において選択される。複数のレコードが上記宛先に対して存在する場合、ブロック４２４での処理は、好適なメッセージングプロバイダを選択するためのアルゴリズムの実施を含むことができる。メッセージングプロバイダは複数のメッセージングプロバイダから選択される可能性があり、上記メッセージングプロバイダは、送信待ち時間、通信データ量または、それぞれのメッセージングプロバイダと所望の送信特性とに関連付けられた他の要因に基づいてメッセージを送信することができる。
【００６９】
ブロック４２５において、１つまたは複数のアプリケーションタグは、送信データに加えられる。アプリケーションタグは、送信データを生成したアプリケーションおよび／またはデータを受信するアプリケーションを識別することができる。
【００７０】
ブロック４２６において、メッセージアグリゲータ２３２は、データ、アプリケーションタグ、およびアプリケーションが実行されるピアの宛先アドレスをメッセージにフォーマットする。上記メッセージは、上記メッセージの送信に選択されたメッセージングプロバイダにより認識される形態である。例えば、上記メッセージは、メッセージを受信するピアのアドレスを含むヘッダを含む。上記メッセージは、選択されたメッセージングプロバイダに対して適切にフォーマットされ、アウトボックス２３４に渡される。
【００７１】
ブロック４３０において、アウトボックス２３４内のメッセージは、選択されたメッセージングプロバイダにより送信される。本例において、選択されたメッセージングプロバイダは、ストアアンドフォワードメッセージングプロバイダである。従って、メッセージングプロバイダを使用したメッセージ送信の結果、メッセージはブロック４３２においてリレーサーバに記憶される。
【００７２】
図４のプロセスは、電子メールユーザインタフェース２５０による電子メールメッセージの送信に使用される可能性もある。電子メールの送信時、データを電子メールメッセージとして識別するアプリケーションタグがブロック４２５において加えられる。
【００７３】
図５は、あるピアにより送信されたデータがリモートピア上のアプリケーションにより受信されるプロセスを示し、図４のプロセスの続きとして実施される可能性がある。図５のプロセスは、ブロック５１０において開始し、上記ピアに関連するメッセージングクライアント２３０のメッセージアグリゲータ２３２が上記メッセージをインボックス２３６に移動する。メッセージがストアアンドフォワードメッセージングプロバイダ上で伝送される例においては、ブロック５１０はリレーサーバからメッセージを取り出してそれをインボックス２３６に移動することを含む。他のメッセージングプロバイダは、プッシュ型の技術を利用することができ、その結果、メッセージアグリゲータ２３２が転送を開始せずに、メッセージがインボックス２３６に到着する。
【００７４】
次に、サブプロセス５２０が実施される。本例において、サブプロセス５２０は、データ受信アプリケーションが実行するピア内のメッセージディスパッチャ２３８内部で実施される。ブロック５２２において、メッセージはインボックス２３６から読み出される。ブロック５２４において、メッセージディスパッチャ２３８は上記メッセージのデータ部を分析して、上記メッセージの送信の一部としてブロック４２４（図４）において上記データに加えたアプリケーションタグを読み出す。メッセージディスパッチャ２３８は、受信メッセージから読み出したアプリケーションタグをレジストリ２４０に記憶した識別コードと比較して、データの宛先であるアプリケーションを識別する。
【００７５】
ブロック５２６において、メッセージディスパッチャ２３８は、受信メッセージのデータ部分を抽出することができる。ブロック５２８において、本データはＡＰＩ２４４内部のＲＥＣＩＥＶＥ機能呼び出しにおいて使用される。ブロック５２８において、呼び出されたＲＥＣＩＥＶＥ機能は、ブロック５２６において抽出されたデータをパラメータとして受け取る。上記機能は、レジストリ２４０から読み出された情報をパラメータとして受け取ることもできる。上記情報はエントリポイント、または識別したアプリケーションがメッセージを受信する他の方法を識別する。ブロック５２８において行われたＡＰＩ２４４の呼び出しは、次いで、アプリケーションに対して指定されたエントリポイントを使用して、指定されたアプリケーションにデータを送信する。
【００７６】
次いで、処理はブロック５３０に続く。ブロック５３０において、データ受信アプリケーションは、アプリケーションに従ってデータを処理する。処理は、データがアプリケーションに送信される方法に対して独立であることができる。
【００７７】
このように、本発明の少なくとも１つの実施形態に関するいくつかの態様を説明したので、当業者は、様々な変更、修正、および改善を思いつくであろうことは理解できる。例えば、本発明は、パーソナルコンピュータまたはスマートフォンのような単一のユーザデバイスであるピアに関連して説明される。しかしながら、本発明はそのように限定されない。上述のシステムは、一般にサーバと見なされるデバイスからピアへの送信に使用される可能性がある。上記実施形態において、サーバはピアデバイスにメッセージを配信通知することができる。
【００７８】
別の例として、ソフトウェアは、複数のモジュールから成るものとして説明される。それぞれのモジュールは物理的に独立したコンピュータ実行可能命令の集合であることができ、例えばソースコードまたは実行可能コードのいずれかの形態で、独立かつ認識可能なコンピュータ可読媒体のセクションに記憶される可能性がある。しかしながら、モジュールは、より大規模なプログラムまたはプログラムのコンポーネントの一部として組み合わされ、または実施される可能性があり、別々に識別可能な構造を有しなくともよい。後者の場合、「モジュール」はより大規模なコンポーネントの機能部分であることができる。
【００７９】
更なる変更の例として、メッセージングプロバイダがメッセージをあるピアからリモートピアに送信するために使用される実施形態が上述される。メッセージは、任意の形式で通信される可能性がある。単一のメッセージは、複数のプロバイダを使用して通信される可能性がある。例えば、メッセージは、携帯電話会社にメッセージをリレーしてリモートピアに配信する電子メールメッセージングプロバイダを最初に使用して、送信される可能性がある。従って、任意数または任意の組み合わせのメッセージングプロバイダまたは通信チャネルは、メッセージに対するメッセージングプロバイダとして使用される可能性がある。
【００８０】
さらに、ＡＰＩまたはメッセージングクライアントにより実施可能な通信機能は、上述の特定のメッセージに限定されない。例えば、通信システムのいくつかのコンポーネントがプログラムされ、データ構造３００内のアドレスをポーリングし、ピアツーピア通信に参加を希望する宛先および／またはピアツーピア通信に参加可能な宛先を発見することができる。上記機能は、マルチプレイヤゲームを実施するアプリケーションコンポーネントに対して有効である可能性がある。宛先がポーリングされ、ゲームに参加を希望する宛先を発見することができる。上記機能は、メッセージングクライアント２３０の一部として実施されない場合でも、アプリケーションは、データ構造３００内のエントリを読み出してメッセージを宛先に送信する機能を使用することでアドレスをポーリングすることができる。
【００８１】
上記変更、修正、および改善は、本開示の一部であると意図しており、本発明の精神および範囲の内であると意図している。したがって、前述の説明および図面は例示の目的のためにあるに過ぎない。
【００８２】
本発明の上述の実施形態は、任意の多数の方法で実施されることができる。例えば、実施形態は、ハードウェア、ソフトウェアまたはそれらの組み合わせを使用して実施される可能性がある。ソフトウェアで実施するとき、ソフトウェアコードは、単一のコンピュータ内で与えられるかまたは複数コンピュータ間で分散させるかに関わらず、任意の適切なプロセッサまたはプロセッサ集合上で実行される可能性がある。
【００８３】
また、本明細書で概観した様々な方法またはプロセスは、様々なオペレーティングシステムまたはプラットフォームのうち任意の１つを使用する１つまたは複数のプロセッサ上で実行可能なソフトウェアとしてコーディングされる可能性がある。さらに、上記ソフトウェアは、任意の多数の適切なプログラミング言語、および／または従来のプログラミングまたはスクリプティングツールを使用して記載される可能性があり、実行可能なマシン語コードとしてコンパイルされる可能性もある。
【００８４】
この点で、本発明は、１つまたは複数のプログラムでエンコードされたコンピュータ可読媒体（または複数のコンピュータ可読媒体）（例えば、コンピュータメモリ、１つまたは複数のフロッピー(登録商標）ディスク、コンパクトディスク、光ディスク、磁気テープ、等）として具現化される可能性があり、上記１つまたは複数のプログラムは、１つまたは複数のコンピュータあるいは他のプロセッサ上で実行するとき、上述の本発明の様々な実施形態を実装する方法を実施する。１つまたは複数のコンピュータ可読媒体は、移動可能であることができ、その上に記憶した１つまたは複数のプログラムを１つまたは複数の異なるコンピュータまたは他のプロセッサ上にロードして上述した本発明の様々な態様を実施することができる。
【００８５】
「プログラム」または「ソフトウェア」の用語は、本明細書において汎用的な意味で使用し、コンピュータまたは他のプロセッサをプログラムして上述の本発明の様々な態様を実施するために使用可能な、任意の種類のコンピュータコードまたはコンピュータ実行可能命令集合を示す。さらに、本実施形態の１つの態様によれば、実行時に本発明の方法を実施する１つまたは複数のコンピュータプログラムは単一のコンピュータまたはプロセッサ上に存在する必要はなく、モジュール形式で多数の異なるコンピュータまたはプロセッサ間で分散させて本発明の様々な態様を実施できることは理解されるべきである。
【００８６】
コンピュータ実行可能命令は、１つまたは複数のコンピュータあるいは他のデバイスにより実行されるプログラムモジュールのような多数の形態であることができる。一般に、プログラムモジュールは、特定のタスクを実施するかまたは特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造、等を含む。一般に、様々な実施形態で望ましいようにプログラムモジュールの機能性は、組み合わされるかまたは分散される可能性がある。
【００８７】
本発明の様々な態様は、単体、組合せ、または前述した実施形態において具体的に議論されなかった様々な配置で使用される可能性があり、したがって本発明は前述または図面で示した構成要素の詳細および配置に対する適用において限定されない。例えば、１つの実施形態で説明された態様は、他の実施形態で説明された態様と任意の方法で組み合わされる可能性がある。
【００８８】
「第１」、「第２」、「第３」等のような序数語を請求項で使用して請求項要素を修正することは、それ自体、優先度、順位、あるいはある請求項要素の別の請求項要素に対する順序または方法の動作を実施する時間的順序を暗示せず、ある特定の名前を有する１つの請求項要素を（序数語の使用を除いて）同一名を有する別の要素から区別するための単なるラベルとして使用して請求項要素を区別する。
【００８９】
また、本発明で使用された表現および用語は、説明の目的であって限定と考えるべきではない。「〜を含む」、「〜を備える」、または「〜を有する」およびそれらの変形は本発明において、それ以前に列挙した項目およびその等価物、および追加項目を包含することを意味する。
【図面の簡単な説明】
【００９０】
【図１】ピアツーピアネットワークのスケッチである。
【図２】図１のピアツーピアネットワークにおいて使用するソフトウェアのアーキテクチャを示す図である。
【図３】図２のアーキテクチャを有するソフトウェアに関連付けたデータ構造を示すスケッチである。
【図４】ピアにより使用されるメッセージを送信するプロセスのフローチャートである。
【図５】メッセージの受信プロセスのフローチャートである。
【図１】
2009506425.tif 000003
【図２】
2009506425.tif 000004
【図３】
2009506425.tif 000005
【図４】
2009506425.tif 000006
【図５】
2009506425.tif 000007
【国際調査報告】
2009506425.tif 000008