JP2007299392A - 動的移動コンテンツの配信用プッシュフレームワーク - Google Patents

動的移動コンテンツの配信用プッシュフレームワーク Download PDF

Info

Publication number
JP2007299392A
JP2007299392A JP2007112402A JP2007112402A JP2007299392A JP 2007299392 A JP2007299392 A JP 2007299392A JP 2007112402 A JP2007112402 A JP 2007112402A JP 2007112402 A JP2007112402 A JP 2007112402A JP 2007299392 A JP2007299392 A JP 2007299392A
Authority
JP
Japan
Prior art keywords
content
push
metadata
application
client
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2007112402A
Other languages
English (en)
Other versions
JP2007299392A5 (ja
JP4635025B2 (ja
Inventor
Michael Shenfield
シェンフィールド マイケル
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
BlackBerry Ltd
Original Assignee
Research in Motion Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Research in Motion Ltd filed Critical Research in Motion Ltd
Publication of JP2007299392A publication Critical patent/JP2007299392A/ja
Publication of JP2007299392A5 publication Critical patent/JP2007299392A5/ja
Application granted granted Critical
Publication of JP4635025B2 publication Critical patent/JP4635025B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/02Traffic management, e.g. flow control or congestion control
    • H04W28/10Flow control between communication endpoints
    • H04W28/14Flow control between communication endpoints using intermediate storage
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/02Details
    • H04L12/16Arrangements for providing special services to substations
    • H04L12/18Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1859Arrangements for providing special services to substations for broadcast or conference, e.g. multicast adapted to provide push services, e.g. data channels
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/55Push-based network services
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/56Provisioning of proxy services
    • H04L67/561Adding application-functional data or data for application control, e.g. adding metadata
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/02Traffic management, e.g. flow control or congestion control
    • H04W28/06Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/04Protocols specially adapted for terminals or networks with limited capabilities; specially adapted for terminal portability
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/60Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/62Establishing a time schedule for servicing the requests

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Library & Information Science (AREA)
  • Information Transfer Between Computers (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Telephonic Communication Services (AREA)

Abstract

【課題】移動環境における動的コンテンツ配信において、アプリケーションおよびコンテンツプロバイダが、アーキテクチャを変更することなく、追加され得るジェネリック動的コンテンツ配信アーキテクチャを構築するため、プッシュプロキシおよびプッシュクライアントを提供すること。
【解決手段】ジェネリック動的コンテンツ配信システムにおいて使用するプッシュプロキシおよびプッシュクライアント。該プッシュプロキシは、コンテンツプロバイダ登録サービスプロバイダインターフェースと、チャネルメタデータ貯蔵庫と、コンテンツメタデータ抽出器・キャッシュモジュールと、コンテンツ断片化モジュールと、据え置き検索メッセージストアモジュールと、コンテンツ満了・置換モジュールと、コンテンツ依存性モジュールと、プッシュスケジューラと、加入・ルールモジュールとを備える。
【選択図】図1

Description

本方法およびシステムは、移動環境における動的コンテンツ配信に関する。より具体的には、アプリケーションおよびコンテンツプロバイダが、アーキテクチャを変更することなく、追加され得るジェネリック(generic)動的コンテンツ配信アーキテクチャに関する。
移動デバイスまたは移動ユーザ設備(UE)のユーザは、ユーザが自身の移動デバイスに要求する機能と、ユーザが移動デバイスからデータにアクセスする方法とに関して、ますます洗練されるようになってきている。
動的コンテンツ配信によって、ユーザは、自らデータを探しに行く必要なしに、むしろ、プッシュされた情報またはデータを入手することができる。データの例には、株価、天気の最新情報、交通の最新情報、動的壁紙、広告、アプリケーション、あるいは、ユーザが望む他のデータが含まれ得る。
無線アプリケーションプロトコル(WAP)のような移動デバイスの現在の技術は、コンテンツをする能力を有する。しかしながら、WAPは、無線アプリケーションプロトコルを満足させ、ユーザのサイトを見る能力に適応するために変わらない均一なサイトを提供するために、ウェブサイトを書き換えることを要求する。
他の代替は、SMSをベースとするプッシュ・アンド・ブロードキャスト(push and broadcast)またはセル・ブロードキャスト(cell broadcast)を含む。ブロードキャストの場合、配信は、特定のユーザまたは特定機器の能力のニーズによってカスタム化され得ない。それゆえ、これらのシステムは、それらのニーズと関連する知能(intelligence)を一切有しない。移動デバイスに対して、より良き解決策が求められている。
現在のシステムおよび方法は、一般的なアプリケーションおよびコンテンツプロバイダが、アーキテクチャを改変する必要なしに、システムに追加されることを可能にする動的コンテンツ配信アーキテクチャおよびシステムを提供することが好ましい。具体的には、現在のシステムおよび方法は、移動デバイスが、その移動デバイスにアプリケーションが追加され、コンテンツが提供され得る動的アプリケーションプラットホームになることができる。ここで、動的コンテンツ配信システムのアーキテクチャは、機器にインストールされ得るアプリケーションのタイプも、機器が受信するコンテンツのタイプも限定しない。
本出願の一局面において、メタデータは、好ましくは、コンテンツを提供し、このコンテンツと関連して、動的コンテンツ配信アーキテクチャ内の様々な処理エレメントに対するコンテンツに知能を加える。このアーキテクチャは、コンテンツ供給、プッシュプロキシを含むサービス供給、無線ネットワーク、プッシュクライアントおよびクライアントアプリケーションを提供する。
本出願の更なる局面において、メタデータは、好ましくは、プッシュコンテンツメタデータに対する層状の「エンベロープ」されたモデルで提供される。コンテンツは、メタデータでラップされ、プッシュフレームワークの中の各エレメントで、処理するために使用され得る。各連続的な(successive)エレメントに対するデータは、層状にされ、それゆえ、処理エレメントは、そのエレメントに対するメタデータのみを抽出することが可能になる。例えば、プッシュプロキシおよびクライアントアプリケーションに向けられるメタデータを含むコンテンツパッケージは、クライアントアプリケーションに対するメタデータの第一のレベル、およびプッシュプロキシに対するメタデータの第二の層を有するコンテンツを含み得る。それゆえ、エンベロープがプッシュプロキシに到達するとき、プッシュプロキシに対するメタデータは、抽出され、コンテンツに適用され、修正されたコンテンツおよびクライアントアプリケーションに対するメタデータは、さらに処理エレメントにパスされる。
本出願の別の局面において、メタデータは、静的メタデータ(本明細書で、またチャネルメタデータとも称される)と動的メタデータ(本明細書で、コンテンツメタデータとも称される)とに分かれ(split)得る。静的メタデータは、アプリケーションとコンテンツプロバイダとの双方への登録の際に確立されるのが好ましい。しかしながら、チャネルメタデータは、後に確立され得る。チャネルメタデータは、配信されているコンテンツのタイプに特定である処理ルールと、コンテンツタイプに対するアプリケーションの要求を特定する。
動的メタデータは、パスされる特定のコンテンツと、逆に関連している。
本出願の別の局面において、プラグイン登録モデルが、プッシュフレームワークの中で表現されることが好ましい。ジェネリックプッシュクライアントおよびプッシュプロキシが同定され、そのそれぞれが様々な処理ブロックまたはモジュールを有することで、これらのエレメントは、コンテンツとメタデータとの双方を処理できる。これらのブロックは、コンテンツがパスされているか、メタデータがパスされているか、あるいはコンテンツとメタデータとの双方がパスされているかのいずれかで、処理されるように向けられ得る。
プラグイン登録は、さらにサービスマニフェストおよびアプリケーションマニフェストをパスすることを好ましくは提供し、コンテンツプロバイダとアプリケーションとの間のチャネルメタデータを確立することができる。具体的には、サービスマニフェストは、コンテンツプロバイダをプッシュフレームワークに登録するために使用され得、アプリケーションマニフェストは、アプリケーションをプッシュフレームワークに登録するために使用され得る。
本出願の別の局面において、シンジゲートされたコンテンツをプッシュする方法が、好ましくは、提供される。この方法によって、データをその優先順位に基づいて、ならびに、データ送信のコスト、接続されているネットワークのタイプ、またはユーザの好みを含むネットワーク因子に基づいて、取り扱うことが可能になる。シンジゲートされたコンテンツに対する随意の混合プッシュ/プルモデルによって、ネットワーク条件が好都合になったとき、プッシュプロキシがコンテンツをプッシュすること、あるいは、ユーザがコンテンツを要求したとき、クライアントがコンテンツをプルすることのいずれかが可能になる。
様々な移動デバイスに適合するために、本出願の更なる局面は、非線形コンテンツ断片化を含むコンテンツに対するコンテンツ断片化を好ましくは提供する。非線形コンテンツ断片化は、コンテンツをメタデータで増加させることを含み、これによって、データが、一度クライアントにパスされると、再構成されることが可能になる。
これらの局面および他の局面が、図面を参照して、より詳細に確認される。
本出願は、好ましくは、ジェネリック動的コンテンツ配信システムにおいて使用するプッシュプロキシを提供する。該プッシュプロキシは、該プッシュプロキシをコンテンツプロバイダに登録して、該コンテンツプロバイダに対するチャネルメタデータをさらに受信するのに適合した、コンテンツプロバイダ登録サービスプロバイダインターフェースと;該コンテンツプロバイダから受信した該チャネルメタデータを格納するのに適合したチャネルメタデータ貯蔵庫と;該コンテンツプロバイダから受信したコンテンツ・メタデータエンベロープから、該プッシュプロキシに対するメタデータを抽出するのに適合し、該メタデータを該プッシュプロキシ上でキャッシュ化するのにさらに適合したコンテンツメタデータ抽出器・キャッシュモジュールと;コンテンツ・メタデータエンベロープをセグメントに分解するのに適合したコンテンツ断片化モジュールと;該コンテンツ断片化モジュールからのコンテンツエンベロープまたは1つ以上のセグメントを格納するのに適合した据え置き検索メッセージストアモジュールと;該据え置き検索メッセージストア内に格納されたコンテンツを満了すること、あるいは該据え置き検索メッセージストア内に格納されたコンテンツを置換することに適合した、コンテンツ満了・置換モジュールと;プッシュクライアントの選択を提供し、サービスを広告するのに適したコンテンツ依存性モジュールと;据え置き検索メッセージストア内に格納されたコンテンツエンベロープのプッシュをスケジューリングするのに適合した、プッシュスケジューラと;アプリケーションと該コンテンツプロバイダとの間の加入を維持し、該加入に対するルールのリストを維持するのに適合した、加入・ルールモジュールとを備える。
本出願は、動的コンテンツ配信アーキテクチャにおいて使用するプッシュクライアントをさらに提供する。該プッシュクライアントは、該プッシュクライアントへのアプリケーションを登録するのに適合し、該アプリケーションに対するアプリケーションマニフェストを受信するのにさらに適合した、アプリケーション登録アプリケーションプロバイダインターフェースであって、該アプリケーションマニフェストは、チャネルメタデータを含む、アプリケーション登録アプリケーションプロバイダインターフェースと;該アプリケーションから受信したチャネルメタデータを格納するのに適合したチャネルメタデータ貯蔵庫と;コンテンツ・メタデータエンベロープをプッシュプロキシから受信するのに適した通信手段と;前記コンテンツ・メタデータエンベロープから、該プッシュクライアントに対するメタデータを抽出するのに適合し、該メタデータを該プッシュクライアント上でキャッシュ化するのにさらに適合しているコンテンツメタデータ抽出器・キャッシュモジュールと;該プッシュクライアントによってまだ受信されていない該プッシュプロキシからのコンテンツの検索をスケジューリングするのに適合した、据え置き検索マネージャと;以前にセグメントに分解されたコンテンツを再構成するのに適合したコンテンツ依存性モジュールと;該据え置き検索メッセージストア内に格納されたコンテンツを満了すること、あるいは据え置き検索メッセージストア内に格納されたコンテンツを置換することに適合した、コンテンツ満了・置換モジュールと;該アプリケーションと協働し、新たなコンテンツが該アプリケーションを待っている旨を該アプリケーションに通知する更新通知ブロックと;該アプリケーションとコンテンツプロバイダとの間の加入を管理するのに適合した加入管理ブロックと;該プッシュクライアントによって要求されたとき、コンテンツをプルするのに適合し、該据え置き検索マネージャによって駆動されるプルブローカとを備え、該プッシュクライアントは、ジェネリックアプリケーションを登録し、ジェネリックコンテンツタイプを該コンテンツプロバイダから受信するのに適合している。
本発明は、さらに、以下の手段を提供する。
(項目1)
ジェネリック動的コンテンツ配信システムにおいて使用するプッシュプロキシであって、
該プッシュプロキシをコンテンツプロバイダに登録して、該コンテンツプロバイダに対するチャネルメタデータをさらに受信するのに適合した、コンテンツプロバイダ登録サービスプロバイダインターフェースと、
該コンテンツプロバイダから受信した該チャネルメタデータを格納するのに適合したチャネルメタデータ貯蔵庫と、
該コンテンツプロバイダから受信したコンテンツ・メタデータエンベロープから、該プッシュプロキシに対するメタデータを抽出するのに適合し、該メタデータを該プッシュプロキシ上でキャッシュ化するのにさらに適合したコンテンツメタデータ抽出器・キャッシュモジュールと、
コンテンツ・メタデータエンベロープをセグメントに分解するのに適合したコンテンツ断片化モジュールと、
該コンテンツ断片化モジュールからのコンテンツエンベロープまたは1つ以上のセグメントを格納するのに適合した据え置き検索メッセージストアモジュールと、
該据え置き検索メッセージストア内に格納されたコンテンツを満了すること、あるいは、該据え置き検索メッセージストア内に格納されたコンテンツを置換することに適合した、コンテンツ満了・置換モジュールと、
プッシュクライアントの選択を提供し、サービスを広告するのに適したコンテンツ依存性モジュールと、
据え置き検索メッセージストア内に格納されたコンテンツエンベロープのプッシュをスケジューリングするのに適合した、プッシュスケジューラと、
アプリケーションと該コンテンツプロバイダとの間の加入を維持し、該加入に対するルールのリストを維持するのに適合した、加入・ルールモジュールと
を備える、プッシュプロキシ。
(項目2)
コンテンツ・メタデータエンベロープをプッシュクライアントにプッシュするプッシュエージェントをさらに備える、項目1に記載のプッシュプロキシ。
(項目3)
フロー制御メッセージを上記プッシュクライアントから受信し、コンテンツ・メタデータエンベロープのプッシュを開始または中止するのに適合したフロー管理制御モジュールをさらに備える、項目1または項目2に記載のプッシュプロキシ。
(項目4)
コンテンツ・メタデータエンベロープを格納し、管理するメッセージブローカ・配信待ち行列をさらに備える、項目1〜3のいずれか1項に記載のプッシュプロキシ。
(項目5)
上記プッシュプロキシは、1つのコンテンツプロバイダのみを登録するのに適合した、項目1〜4のいずれか1項に記載のプッシュプロキシ。
(項目6)
上記プッシュプロキシは、複数のコンテンツプロバイダを登録するのに適合した、項目1〜4のいずれか1項に記載のプッシュプロキシ。
(項目7)
コンテンツを格納するコンテンツストレージモジュールをさらに備える、項目1〜6のいずれか1項に記載のプッシュプロキシ。
(項目8)
上記プッシュプロキシを統治するサービス統治モジュールをさらに備える、項目1〜7のいずれか1項に記載のプッシュプロキシ。
(項目9)
動的コンテンツ配信アーキテクチャにおいて使用するプッシュクライアントであって、
該プッシュクライアントへのアプリケーションを登録するのに適合し、該アプリケーションに対するアプリケーションマニフェストを受信するのにさらに適合した、アプリケーション登録アプリケーションプロバイダインターフェースであって、該アプリケーションマニフェストは、チャネルメタデータを含む、アプリケーション登録アプリケーションプロバイダインターフェースと、
該アプリケーションから受信したチャネルメタデータを格納するのに適合したチャネルメタデータ貯蔵庫と、
コンテンツ・メタデータエンベロープをプッシュプロキシから受信するのに適した通信手段と、
該コンテンツ・メタデータエンベロープから、該プッシュクライアントに対するメタデータを抽出するのに適合し、該メタデータを該プッシュクライアント上でキャッシュ化するのにさらに適合しているコンテンツメタデータ抽出器・キャッシュモジュールと、
該プッシュクライアントによってまだ受信されていない該プッシュプロキシからのコンテンツの検索をスケジューリングするのに適合した、据え置き検索マネージャと、
以前にセグメントに分解されたコンテンツを再構成するのに適合したコンテンツ依存性モジュールと、
該プッシュクライアント内に格納されたコンテンツを満了すること、あるいは該プッシュクライアント内に格納されたコンテンツを置換することに適合した、コンテンツ満了・置換モジュールと、
該アプリケーションと協働し、新たなコンテンツが該アプリケーションを待っている旨を該アプリケーションに通知するのに適合した更新通知ブロックと、
該アプリケーションとコンテンツプロバイダとの間の加入を管理するのに適合した加入管理ブロックと、
該プッシュクライアントによって要求されたとき、コンテンツをプルするのに適合し、該据え置き検索マネージャによって駆動されるプルブローカと
を備え、
該プッシュクライアントは、ジェネリックアプリケーションを登録し、ジェネリックコンテンツタイプを該コンテンツプロバイダから受信するのに適合した、プッシュクライアント。
(項目10)
コンテンツ・メタデータエンベロープを上記プッシュプロキシから受信する、プッシュエージェントをさらに備える、項目9に記載のプッシュクライアント。
(項目11)
フロー制御メッセージを上記プッシュプロキシに送信し、コンテンツ・メタデータエンベロープのプッシュを開始または中止するのに適合したフロー制御管理モジュールをさらに備える、項目9または項目10に記載のプッシュクライアント。
(項目12)
コンテンツ・メタデータエンベロープを格納し、管理するメッセージブローカ・配信待ち行列をさらに備える、項目9〜11のいずれか1項に記載のプッシュクライアント。
(項目13)
上記プッシュクライアントは、1つのアプリケーションのみに登録するのに適合した、項目9〜12のいずれか1項に記載のプッシュクライアント。
(項目14)
上記プッシュクライアントは、複数のアプリケーションに登録するのに適合した、項目9〜12のいずれか1項に記載のプッシュクライアント。
(項目15)
コンテンツを格納するコンテンツストレージモジュールをさらに備える、項目9〜14のいずれか1項に記載のプッシュクライアント。
(項目16)
上記プッシュクライアントを統治するサービス統治モジュールをさらに備える、項目9〜15のいずれか1項に記載のプッシュクライアント。
(項目17)
上記プッシュクライアントは、該プッシュクライアントと接続されていないアプリケーションに対するバックグラウンド更新を実行するのに適合したバックグラウンド更新処理モジュールをさらに備える、項目9〜16のいずれか1項に記載のプッシュクライアント。
(項目18)
上記更新通知モジュールは、所定のロケーション内に上記アプリケーションに対するコンテンツを格納するのに適合した、項目9〜17のいずれか1項に記載のプッシュクライアント。
(項目19)
上記更新通知は、データが上記所定のロケーション内に格納されたというメッセージを、上記クライアントアプリケーションに送信する、項目19に記載のプッシュクライアント。
(項目20)
上記更新通知は、上記コンテンツ・メタデータエンベロープを上記アプリケーションに送信する、項目9〜17のいずれか1項に記載のプッシュクライアント。
(摘要)
ジェネリック動的コンテンツ配信システムにおいて使用するプッシュプロキシおよびプッシュクライアント。該プッシュプロキシは、該プッシュプロキシをコンテンツプロバイダに登録して、該コンテンツプロバイダに対するチャネルメタデータをさらに受信するのに適合した、コンテンツプロバイダ登録サービスプロバイダインターフェースと;該コンテンツプロバイダから受信した該チャネルメタデータを格納するのに適合したチャネルメタデータ貯蔵庫と;該コンテンツプロバイダから受信したコンテンツ・メタデータエンベロープから、該プッシュプロキシに対するメタデータを抽出するのに適合し、該メタデータを該プッシュプロキシ上でキャッシュ化するのにさらに適合したコンテンツメタデータ抽出器・キャッシュモジュールと;コンテンツ・メタデータエンベロープをセグメントに分解するのに適合したコンテンツ断片化モジュールと;該コンテンツ断片化モジュールからのコンテンツエンベロープまたは1つ以上のセグメントを格納するのに適合した据え置き検索メッセージストアモジュールと;該据え置き検索メッセージストア内に格納されたコンテンツを満了すること、あるいは該据え置き検索メッセージストア内に格納されたコンテンツを置換することに適合した、コンテンツ満了・置換モジュールと;プッシュクライアントの選択を提供し、サービスを広告するのに適したコンテンツ依存性モジュールと;据え置き検索メッセージストア内に格納されたコンテンツエンベロープのプッシュをスケジューリングするのに適合した、プッシュスケジューラと;アプリケーションと該コンテンツプロバイダとの間の加入を維持し、該加入に対するルールのリストを維持するのに適合した、加入・ルールモジュールとを備える。
(好ましい実施形態の説明)
ここで、図1を参照する。クライアントアプリケーションに動的コンテンツを配信するジェネリックなプッシュシステムが示される。図1のシステムは、簡略化されたシステムであり、動的コンテンツ配信アーキテクチャ内にあることを必要とするロジカルコンポーネントを示す。しかしながら、当業者には、他のコンポーネントが存在し得ること、あるいは、様々なコンポーネントが一緒にグループ化され得ることが理解される。
アーキテクチャ100は、コンテンツプロバイダ110を含む。コンテンツプロバイダ110は、コンテンツプロバイダ110に契約しているユーザに動的コンテンツを提供するようにアレンジされる。実施例は、例えば、本を販売するウェブサイトを含み得る。ユーザは、コンテンツプロバイダ110と契約して、特定のジャンルの新刊本のリストを入手し得る。他の実施例は、とりわけ、定期的にユーザへヘッドラインを提供し得るニュースサイト、一日の所定の期間の間、ユーザに最新の交通情報を提供し得る交通サイト、最新の株価または為替レートを提供し得る株式市場サイトを含み得る。
以下に、より詳細に説明されるように、サービスプロバイダのクライアントが、コンテンツプロバイダ110からコンテンツを受信できるようにするために、コンテンツプロバイダ110は、サービスプロバイダ120と契約する。サービスプロバイダ120は、プッシュプロキシ122を含み、このプッシュプロキシ122は、クライアントまたはクライアントアプリケーションに対するプロキシとして機能し、コンテンツプロバイダ110にコンテンツを送信する目的地を提供する。
サービスプロバイダ120は、移動デバイスに位置するプッシュクライアント140と、無線ネットワーク130を介して通信する。プッシュクライアント140は、以下に、より詳細に説明される。プッシュクライアント140は、コンテンツプロバイダ110から配信されるコンテンツを受信し、クライアントアプリケーション150と、コンテンツを通信し得、そのクライアントアプリケーション150は、最終的にコンテンツを消費する。
本明細書において、コンテンツプロバイダ110、サービスプロバイダ120、プッシュプロキシ122、無線ネットワーク130、プッシュクライアント140、またはクライアントアプリケーション150への参照は、図1のアーキテクチャに戻っての参照である。
図2を参照すると、図1のコンポーネントは、単にロジカルコンポーネントであり、必ずしも、個別の物理的コンポーネントではないことが、当業者には理解される。図1は、ジェネリックなアーキテクチャを示し、その中に、1つのコンテンツプロバイダ110と、1つのプッシュプロキシ122と、1つのプッシュクライアント140と、1つのクライアントアプリケーション150とが存在する。代替が、図2に示される。
特に、第一の代替アーキテクチャ210は、プッシュプロキシ122と通信する複数のコンテンツプロバイダ110を含む。プッシュプロキシ122は、図1のアーキテクチャにおいてのように、無線ネットワーク130を介して、プッシュクライアント140と通信する。さらに、複数のクライアントアプリケーション150は、アーキテクチャ210の中に存在する。それゆえ、これは、複数のコンテンツプロバイダ110および複数のクライアントアプリケーション150を有するN−1−1−Nシステムである。
図2のアーキテクチャ220は、プッシュプロキシ122と通信し、それに登録された1つのコンテンツプロバイダ110を含む。さらに、プッシュプロキシ122は、無線ネットワーク130を介して、複数のプッシュクライアント140と通信する。各プッシュクライアント140は、クライアントアプリケーション150と通信する。それゆえ、アーキテクチャ220は、クライアントアプリケーション150およびプッシュクライアント140のロジカルコンポーネントをグループ化し、N(1−1)−1−1システムである。
図2のアーキテクチャ230は、複数のプッシュプロキシ122を有し、そのそれぞれは、コンテンツプロバイダ110と通信する。プッシュプロキシとコンテンツプロバイダとの各組み合わせ232は、無線ネットワーク130を介して、ジェネリックなプッシュクライアント140と通信し、次いで、このプッシュクライアント140は、クライアントアプリケーション150と通信する。これは、1−1−N(1−1)システムである。
図2のアーキテクチャ240において、コンテンツプロバイダ110およびプッシュプロキシ122のグループピング232は、無線ネットワーク130を介して、ジェネリックなプッシュクライアント140とクライアントアプリケーション150との組み合わせと通信する。それゆえ、これは、N(1−1)−N(1−1)システムである。
当業者によって理解されるように、他の代替も可能である。上記は、様々なロジカルコンポーネントを示し、これらのロジカルコンポーネントは、個別の物理的コンポーネントになり得るし、あるいは、一緒にグループ化され得る。例えば、プッシュクライアントは、アプリケーションに組み込まれ得るし、共有クライアントは、複数のアプリケーションまたは他の代替によって、使用され得る。
ここで、図3を参照する。システムに知能を加えるために、コンテンツは、メタデータと関連している。この場合、メタデータは、処理エレメントによって使用され、コンテンツを操作し得るデータとして定義される。理解されるように、ジェネリックプッシュシステムは、様々なコンテンツプロバイダおよびアプリケーションが、システム内に存在できるようにするために、メタデータを要求する。メタデータは、処理パラメータまたはルール、直接提供される処理ハンドラ、コードまたはリファレンス、あるいは、別の場所にある処理ハンドラ、コードまたはルールへのリンクを含む様々な形式であり得る。
図3から分かるように、コンテンツは、コンテンツプロバイダ110からクライアントアプリケーション150へと通過し、これは、矢印310によって示されている。アーキテクチャ100の中にある様々なコンポーネントへの命令を提供するメタデータも、また、アーキテクチャ100の中のコンポーネントの間を、通常はコンテンツに沿って通過し得る。例えば、矢印320は、コンテンツプロバイダで生成し、クライアントアプリケーション150に到達するまで、配信システムに対して認識されないメタデータを示す。
矢印330は、コンテンツプロバイダ110によって生成されたメタデータを示す。このメタデータは、プッシュクライアント140向けに意図されているので、ジェネリックプッシュクライアント140に流れるのみである。
矢印340は、サービスプロバイダ120によって生成されたメタデータを示す。このメタデータは、プッシュクライアント140向けに意図されているので、プッシュプロキシ122でコンテンツと最初に関連し、ジェネリックプッシュクライアント140で、コンテンツからストリップされる。これが起こり得る場所の例として、請求プランおよび提供されるべきサービスのレベルに関してのユーザとサービスプロバイダとの契約を含み、こうして、サービスプロバイダは、メタデータを用いて、利用可能なサービスを制限し得るし、あるいは拡張されたサービスを提供し得る。
メタデータのフローおよびメタデータの役割は、以下に、より詳細に記載される。
ここで、図4を参照する。図4は、詳細な例示的なプッシュプロキシ410を示し、このプッシュプロキシ410は、現在のシステムおよび方法と関連して使用され得る。当業者には理解されるように、プッシュプロキシ410は、図1および図2からのプッシュプロキシ122と同じであり得る。
図4のプッシュプロキシ410は、プッシュプロキシ410がジェネリックなプッシュ環境で動作することができる様々なエレメントを含む。これによって、プッシュプロキシは、特定のコンテンツプロバイダまたはプッシュクライアントとの相互作用に限定されず、その代わりに、動的な環境に適応し得るので、融通性が向上する。プッシュプロキシ410に対して以下に記載されるエレメントは、プッシュプロキシ410内に有することが好ましいが、これらのエレメントは網羅的なものではなく、他のエレメントも可能である。さらに、ある種のエレメントは、プッシュプロキシ410から除外され得るが、それでも、残りのエレメントで、ジェネリックなプッシュサービスを実行できる。
プッシュプロキシ410は、その中に登録されたコンテンツプロバイダ412を含む。コンテンツプロバイダ412は、コンテンツプロバイダ登録にサービスプロバイダインターフェース(SPI)420を登録する。以下に、より詳細に記載されるように、この登録において、コンテンツプロバイダ412は、確立されるチャネルに対するある種の情報、本明細書ではチャネルメタデータと称するが、これを含むことが望ましい。コンテンツプロバイダ412は、図1のコンテンツプロバイダ110と同じであり得る。
プッシュプロキシ410は、プッシュプロキシサービスを管理するためのサービス管理ブロック430を含む。
プッシュプロキシ410は、コンテンツと、そのコンテンツと関連するメタデータとの双方を取り扱う様々なモジュールを含む。第一のモジュールは、メッセージブローカ・配信待ち行列440であり、これは、コンテンツプロバイダ412からのメッセージを消費するconsumeサブシステムであり、コンテンツ配信待ち行列を管理する。当業者には理解されるように、全てのクライアントアプリケーションに対する全てのコンテンツが、一度に配信され得ないで、配信待ち行列は、コンテンツを順当に配信するために、確立される必要がある。例えば、デバイスは、カバー範囲外であり得て、コンテンツが格納されるべき必要があり得る。
プッシュプロキシ410は、フロー制御管理ブロック442をさらに含む。フロー制御管理ブロック442によって、コンテンツのフローを制御できる。例えば、限られた空間内の移動局は、所定の量の情報を受信できるだけであり得る。この場合、移動デバイスは、図1に示されるようなプッシュクライアント140を介して、プッシュプロキシ410に、プッシュクライアント140へのデータのフローを止めるように求め得る。このフロー制御管理ブロック442は、これに対処する。
代替として、移動デバイスは、オフラインであり得る。フロー制御管理ブロック442は、コンテンツがプッシュプロキシ410によって受信されたままの状態で配信され得ないとき、プッシュクライアント140へのデータのフローを中止し、開始する。
プッシュプロキシ410の更なるコンポーネントは、プッシュエージェント444である。プッシュエージェント444は、クライアントにデータを送信する役割を担う。
当業者には理解されるように、ブロック440、442および444は、メッセージ伝達のみを扱い、メタデータ関連とは関係しない。言い換えれば、これらのブロックは、メッセージのコンテンツを取り扱うが、コンテンツと関連するメタデータは一切取り扱わない。
プッシュプロキシ410の更なるコンポーネントは、コンテンツメタデータ抽出器・キャッシュブロック450である。コンテンツメタデータ抽出器・キャッシュブロック450は、エンベロープされた(enveloped)コンテンツメタデータで動作する。具体的には、以下に、より詳細に記載されるメタデータシステムのエンベロープモデルにおいて、システム内の各ロジカルコンポーネントは、コンテンツ処理と関連するメタデータを有し得る。このメタデータによって、ロジカルコンポーネントは、コンテンツにアクションを実行することができる。このように、各ロジカルコンポーネントは、自身と関連するメタデータを抽出できる必要がある。
コンテンツメタデータ抽出器・キャッシュブロック450は、プッシュプロキシ410と関連するメタデータを抽出し、このメタデータをキャッシュ化する役割を担う。キャッシュ化機能によって、同じコンテンツプロバイダからの引き続きくるコンテンツエンベロープ内の同一のメタデータをパスする必要がなくなるので、最適化できる。メタデータの抽出およびキャッシュ化は、以下に記載される。
据え置き検索・メッセージストアブロック452は、コンテンツまたはそのコンテンツの一部をクライアントアプリケーションに配信することが効率的でないときに、使用される。据え置き検索・メッセージストアブロック452は、クライアントに配信されないコンテンツを、そのコンテンツを送信するのが効率的になるまで、あるいは、そのコンテンツがクライアントによって引き出されるまで、格納するために使用され得る。据え置き検索・メッセージストアは、また、補助コンテンツをキャッシュ化するためにも使用され得る。この補助コンテンツは、既に配信されたコンテンツを介するクライアントアプリケーションナビゲーションに依存するクライアントに随意に送信され得るか、あるいは、そのクライアントによって引き出され得る
据え置き検索メッセージストアブロック452の目的は、図19および図21を参照して、以下に、より良く説明される。一例として、据え置き検索メッセージストアブロック452は、ユーザが、ユーザのロケーションの近くにあるレストランなどのロケーション情報をリクエストした場合に使用され得る。コンテンツプロバイダまたはサービスプロバイダは、情報を提供するモデルを有し得る。このとき、広告主は、お金を払って、自分たちの情報をサーチリクエストに追加し得る。したがって、あるロケーションに対するレストラン情報をリクエストしているユーザは、自分がリクエストしている自分のロケーションの近くに、商店、ゴルフコース、体育館または他のサービスに関する情報を有し得る。コンテンツプロバイダは、リクエストされたレストラン情報に追加情報を束ねて、これらの情報をプッシュプロキシ410にパスする。
プッシュプロキシ410は、提供されたメタデータに基づいて、コンテンツパッケージを生成し、クライアントに送信する。コンテンツパッケージには、クライアントによってリクエストされた情報、およびユーザが関心を有し得る関連情報のダイジェストまたは概要が含まれ得る。概要は、ユーザに送信されるが、据え置き検索・メッセージストアブロック452は、コンテンツプロバイダ110から受信された実際のデータを格納する。こうして、将来、ユーザが、そのダイジェスト内にある情報に関するより詳細な情報を入手したいと思った場合、この情報は、プッシュプロキシ410に既に格納されている。
据え置き検索・メッセージストアブロック452に対する代替的な使用は、ユーザが一度にコンテンツ全体を受け入れ得ない場合である。例えば、デバイスにコンテンツ全部を送信することが、実現可能でない場合、あるいは経済的でない場合、コンテンツの一部は、しばらく経つまで、つまり、クライアントによって引き出され得るときまで、あるいは所定のルールが合致して、プッシュされ得るときまで、格納され得る。これらのルールは、満足される所定のネットワークまたはサービス条件により、ネットワークまたはサービス条件によって特定され得る。これについては、以下に、図19を参照して、より詳細に記載される。
プッシュスケジューラ454は、クライアントに対する配信スロットをスケジューリングする。前述のように、一部の状況において、一度にコンテンツの全部をプッシュすることは効率的でないことがあり得る。プッシュスケジューラ454は、一部の情報を即座にそして、その残りを所定のスケジュールに従ってプッシュすることを決定し得る。また、プッシュスケジューラ454は、コンテンツの性質を用い、そのコンテンツがプッシュされるべきときを決定し得る。特に、一部のコンテンツが高い優先度を有すること、あるいは時間的に限られた満了期限を有することをメタデータが示し得ると、このコンテンツは、即座にプッシュされ得る。それに対し、低い優先度を有するか、あるいは満了期限を有しないことを示されたコンテンツは、後に、データをパスする条件が、より好ましくなったときに、プッシュされ得る。
当業者には理解されるように、ブロック450、452および454は、メッセージのコンテンツと、このメッセージと関連するメタデータとの双方を扱う。
加入・ルールブロック460は、配信されている特定のコンテンツを取り扱う上でのサービスおよびモニタルールを受信するために登録されるアプリケーションを追跡(track)する。コンテンツは、典型的には、クライアントによる加入またはクライアントの代理としての加入に基づいて配信される。例えば、特定のサービスをユーザが欲する場合、そのユーザは、積極的に加入をリクエストし得る。加入は、ユーザの代理としてなされ得る。例えば、ユーザが、サービスの恩恵を受けるために、サービスプロバイダ120と契約にサインをした場合である。これは、ユーザが、所定の数の広告を毎日受信することに同意しさえすれば、ユーザが優遇料金で受信する場合を含み得る。この場合、サービスプロバイダ120は、クライアントの代理として、広告プロバイダに加入し得る。
アプリケーションが移動デバイス上で消去されるとき、あるいはアプリケーションが加入を登録解除するとき、加入・ルールブロック460は、そのユーザを加入中止にし得る。
コンテンツ依存ブロック462は、プッシュプロキシ410によって使用され、移動デバイスが利用し得るサービスを広告する。したがって、移動デバイスのユーザが、サービスに対する十分な画面または帯域幅あるいはメモリを有しない場合、コンテンツ依存ブロック462は、そのサービスの広告をそのユーザに対して阻止し得る。
コンテンツ断片化ブロック464は、コンテンツを断片化するために使用される。これが用いられ得るのは、例えば、移動デバイスが、一度にコンテンツの全てを受信できない場合である。コンテンツ断片化ブロック464は、コンテンツを様々なコンポーネントに分解するために使用される。これは、据え置き検索・メッセージストア452と連携して使用され、まだ配信されていない断片化コンテンツを格納し得る。
コンテンツ満了・置換ブロック466は、2つの目的で使用される。第一に、このブロックは、加入をモニタするために使用され得る。各加入には、満了時があり、この満了時に達したときに、加入は終了し得る。
また、コンテンツ満了・置換ブロック466は、情報をモニタするためにも使用され得る。ある種のコンテンツには、その情報の有効期限がある。例えば、ラッシュ時の交通をモニタするために使用される交通アプリケーションは、非常に時間依存性がある。何らかの理由で、プッシュプロキシ410は、移動デバイスにコンテンツを即座に配信できない場合、このコンテンツは、将来の配信のために、コンテンツストレージ480の中に格納される。しかしながら、コンテンツが所定の特定期間内に配信されない場合、このコンテンツは満了し得、全く配信され得ない。
同様に、コンテンツ置換は、情報が更新される状況で扱われる。例えば、株価を受信するクライアントアプリケーションは、最新の株価を欲するのみであり得る。したがって、プッシュプロキシ410は、株価をプッシュクライアント140に配信できず、引き続く株価がコンテンツプロバイダ110から受信される場合、引き続く株価の中にあるメタデータが、以前の株価に置換されて使用されるべきであることを指示し得る。格納された情報の置換は、配信待ち行列に全ての情報を加えるより、コンテンツストレージ480内の空間を開放する。
チャネルメタデータ貯蔵庫470はチャネルメタデータを格納するために使用される。これについては、以下に、より詳細に記載される。
以上は、本明細書の方法およびシステムで使用され得る例示的なプッシュプロキシ410を説明するものである。このプッシュプロキシ410は、プッシュプロキシ410のブロックおよびエレメントによって、ジェネリックな動的コンテンツ配信システムで使用される。ここで、アプリケーションにおけるコンテンツのタイプおよびコンテンツの取り扱いは、変動し得、事前に決定されない。
ここで、図5を参照する。図5は、本明細書のシステムおよび方法と関連して使用され得るプッシュクライアント510を示す。プッシュクライアント510は、図1および図2のプッシュクライアント140と同じであり得る。
当業者には理解されるように、コンテンツおよびそのコンテンツ処理が事前に決定されていないジェネリックなシステムで用いられることになるプッシュクライアント510は、コンテンツと、そのコンテンツと関連するメタデータとの双方に適合して使用され得るブロックまたはモジュールを含むべきである。図5に関して規定されるブロックは、網羅的であることを意図するものではなく、プッシュクライアント510内に他のブロックもまた存在し得る。さらに、プッシュクライアント510内のブロックは、一部の例において、プッシュクライアント510内の他のブロックの機能性を制約することなく、省かれ得る。
プッシュクライアント510は、アプリケーションをサービスし、1つ以上のアプリケーション512は、プッシュクライアント510に登録され得る。アプリケーション登録は、登録用のインターフェースとして、アプリケーションプロバイダインターフェース514を使用し、アプリケーションプロバイダインターフェース514は、以下により詳細に記載されるように、アプリケーション用のチャネルメタデータを抽出するために、さらに使用され得る。
プッシュクライアント510は、プッシュクライアント510を統治(administer)するために使用されるクライアント統治(administration)520を含む。
図4のプッシュサーバ410と同様に、プッシュクライアント510は、メッセージ伝達を扱う様々なブロック、メタデータを扱う様々なブロック、およびメッセージ伝達とメタデータとの双方を扱う様々なブロックを含む。
メッセージブローカ・アプリケーション配信待ち行列540は、配信用プッシュプロキシ410からアプリケーション512へのメッセージを扱う。アプリケーション待ち行列は、アプリケーション512に対するメッセージの待ち行列である。
フロー制御管理ブロック542は、図4のプッシュプロキシ410に、コンテンツのプッシュ中止またはコンテンツのプッシュ再開を通知するために使用される。これが使用されるのは、例えば、プッシュクライアント510が、プッシュされたコンテンツを受け入れ得るメモリ量が限られているときである。この場合、プッシュコンテンツが消費される前に、プッシュクライアント510は、プッシュプロキシ410からのコンテンツのフローを止める必要がある。一度、コンテンツが消費されると、フロー制御管理ブロック542は、再び、データのフローを開始するために使用され得る。
プッシュクライアント510内のプッシュエージェント544は、図4のプッシュプロキシ410から情報を受信するために使用される。
当業者には理解されるように、メッセージブローカ・アプリケーション待ち行列540、フロー制御管理ブロック542、およびプッシュエージェント544は、メッセージ伝達を独占的に扱い、メタデータを扱わない。
コンテンツメタデータ抽出器・キャッシュブロック550は、プッシュクライアント510に向かうことになっている動的メタデータを抽出するために使用される。図4のプッシュプロキシ410を参照して、以前に述べたように、動的コンテンツ配信アーキテクチャ内の処理エレメントはいずれも、これらの処理エレメントに向かう予定のメタデータを有し得、このメタデータは抽出される必要がある。このように、プッシュクライアント510に向かう予定のメタデータは、コンテンツメタデータ抽出器・キャッシュブロック550によって抽出される。
さらに、コンテンツメタデータ抽出器・キャッシュブロック550は、キャッシュメタデータに適合することが好ましい。第一のコンテンツパッケージと第二のコンテンツパッケージとの間で変化しないプッシュクライアント510に対するメタデータは、パスされる必要はない。こうして、このメタデータの抽出を要求しないので、プッシュクライアント510での処理時間を節約でき、無線ネットワーク130を介してパスされるプッシュクライアント510に対するメタデータを要求しないので、ネットワークリソースをさらに節約できる。
据え置き検索マネージャ552は、受信されたコンテンツの断片を解析し、コンテンツを正しい方法で一緒に置くために使用される。以下により詳細に記載されるように、データは、線形、あるいは非線形であり得る。データが非線形の場合、データを再構築するために、メタデータが必要とされ、これは、据え置き検索マネージャ552によって行われる。据え置き検索マネージャ552は、また、プッシュプロキシ510の据え置き検索ストア452で利用可能な情報のダイジェストを解析するようにも適合され、ユーザによって要求されたとき、コンテンツプルブローカ554(以下に記載)を駆動して、この情報を検索する。これは、コンテンツナビゲーションが、コンテンツ構造グラフの所定のブランチに入るとき、あるいは帯域幅またはコスト条件が満足されるとき、予測検索を含む。
コンテンツプルブローカ554は、プッシュクライアント510がある状況下で、コンテンツを引き出すことができるプッシュ/プルモデルで使用される。このような状況は、図19を参照して、以下に詳細により記載される。
当業者には理解されるように、コンテンツメタデータ抽出器・キャッシュ550、据え置き検索マネージャ552およびコンテンツプルブローカ554は、メッセージ伝達コンテンツとメタデータとの双方を扱う。
加入管理ブロック560は、図4の加入・ルールブロック460と同じである。特に、加入管理ブロック560は、加入を管理するために使用される。アプリケーションが、移動デバイスから登録解除する場合、あるいは削除される場合、加入管理ブロック560は、加入を終了する。加入管理ブロック560は、また、加入チャネルが満了するとき、クライアントアプリケーションの代理として、再加入し得る。
更新通知ブロック562は、クライアントアプリケーションと協働し、新たなコンテンツがクライアントアプリケーションを待っていることをアプリケーションに通知するために使用される。これは、3つの方法のうちの1つで行われる。
a.更新通知ブロック562が、アプリケーション512に通知し得る第一の方法は、プッシュクライアント510が、コンテンツをアプリケーションに直接送信する方法である。
b.更新通知ブロック562が、新たなコンテンツのアプリケーション512に通知し得る第二の方法は、コンテンツストレージ580内にコンテンツを格納し、コンテンツが待っていることを随意にアプリケーション512に通知する方法である。この場合の通知は、随意である。具体的には、アプリケーション512が、自身に向けられた情報が、特定のメモリブロック内に格納されていることを知っている場合、そのアプリケーションにとって、それが新たなデータを有することを発見するための一つの選択肢は、メモリロケーションを定期的に調査し、そのメモリロケーションに何か書かれていないかを見ることである。代替として、更新通知ブロック562は、自身が新たなデータを有することと、おそらく、データが格納されているロケーションとを指示するメッセージをアプリケーションに送信し得る。
c.更新通知562が、新たなコンテンツのアプリケーション512に通知し得る第三の方法は、コンテンツを内部に格納し、アプリケーションに通知する方法である。このアプリケーションは、次いで、プッシュクライアントに呼びかけて、そのコンテンツを検索する。
コンテンツ依存ブロック564は、図4のコンテンツ依存ブロック462と同じであり、移動デバイスにサービスを広告するかどうかを判断し得る。
コンテンツ満了・置換ブロック566は、図4のコンテンツ置換・満了ブロック466と同じである。コンテンツの満了およびコンテンツの置換は、このように、プッシュサーバまたはプッシュプロキシに加えて、プッシュクライアント510で扱われ得る。
チャネルメタデータ貯蔵庫570は、アプリケーション512に対するチャネルメタデータを格納するために使用される。
バックグラウンド更新処理モジュール575は、アプリケーション512が利用できないとき、更新を実行するために使用される。バックグラウンド更新によって、例えば、アプリケーションストレージ内部のデータをより新しいデータと置換が可能になる。その後、ユーザは、アプリケーションを開始し、アプリケーションによって表示されるデータは、補正され、更新される。
バックグラウンド更新処理モジュール575は、処理ルールを用いて、コンテンツをアプリケーションに対して許容可能なフォーマットに翻訳する。このモジュールは、コンテンツストア580内のコンテンツを実行し、処理し得る。
一例として、夜間契約者(contractor overnight)に対して更新されるタスクリストは、それにプッシュされたタスクを有し得る。タスクアプリケーションは、この間、開始されず、バックグラウンド更新処理モジュール575は、タスクアプリケーション用のコンテンツを更新するために使用され得る。これは、拡張マークアップ言語(XML)ファイルを扱うためのコードで行われ得、「handler.exe」と称されるファイルで、デバイス上に存在し得る。プッシュクライアント510上のバックグラウンド更新処理ブロック575は、handler.exeをランさせ得、パラメータを有するXMLドキュメントをパスさせる。次いで、ハンドラは、タスクをアプリケーションの内部フォーマットに構築する。
一度、プッシュクライアント510のバックグラウンド更新処理ブロック575が、アプリケーション内部フォーマットにタスクを構築すると、このブロックは、コンテンツストレージ580からのタスクリストに、そのタスクを読み込まれ得、その新しいタスクをリストに添付し得る。次いで、そのブロックは、改変されたバックをコンテンツストレージ580に格納する。これは、タスクアプリケーションが、次にプッシュクライアント510に接続するときに備えてである。
図5は、それゆえ、ジェネリック動的コンテンツ配信システムにおいて使用され得るプッシュクライアント510を示す。ここで、コンテンツおよびコンテンツの処理は、動的であり、事前に決定されていない。図5のプッシュクライアント510を参照して上述されたブロックは、システムの動的な性質に適合するように使用される。
図3を参照して示されたように、コンテンツは、メタデータと関連し、コンテンツの処理に対する知能を提供する。本方法およびシステムに従うと、メタデータは、2つのタイプのメタデータに分けられ得る。具体的には、静的(チャネル)メタデータおよび動的(コンテンツ)メタデータである。
コンテンツプロバイダおよびアプリケーションのタイプには無限の可能性があるので、ジェネリックシステムを構築するためには、メタデータは、クリティカルである。特定のタイプのコンテンツを扱う唯一の方法は、メタデータを介してである。
静的メタデータは、特定タイプのコンテンツをいかに処理するかのルールを提供するメタデータである。静的メタデータは、様々な抽象化レベルに分解され得、例えば、コンテンツ自体に関する構造情報を含む。例えば、Real−time Simple Syndication(RSS)ドキュメントは、RSS 2.0.XSD構造で配信され得、そのコンテンツプロバイダからの全てのコンテンツは、この構造で配信される。
静的メタデータの更なる抽象化レベルは、コンテンツサブタイプに対する処理ルールの提供を含む。これは、アプリケーションに特定的であり得る。したがって、例えば、金融ニュースのアプリケーションは、所定のロケーションに格納された金融ニュースRSSストリームからデータが抽出されるべきことと、そのアプリケーションが情報の着信に関する通知を受けるべきこととを指示する。アプリケーションは、自身に向けられる予定のコンテンツを常に要求し、この方法で取り扱う。
静的メタデータ(本明細書では、チャネルメタデータとも称される)は、アプリケーションとコンテンツプロバイダとの間での加入の間、ずっと留まる。したがって、静的メタデータは、アーキテクチャ内の各エレメントに対して、また、各コンテンツ配信チャネルに対して、一回確立され得る。一つの実施形態において、これは、アプリケーションまたはコンテンツプロバイダの登録時に行われる。
動的メタデータは、コンテンツの特定のピースと関連しているメタデータである。例えば、データの特定のピースと関連する満了情報、または置換ルール、およびデータの特定のピースと関連する情報である(すなわち。ドキュメントKがドキュメントLと置換する)。
以上に、図4および図5を参照して示したように、各処理エンティティは、その処理エンティティに向けられる静的メタデータと動的メタデータとの双方を受信し得る。したがって、プッシュプロキシ410は、コンテンツメタデータ抽出器・キャッシュ450を、動的メタデータを抽出するため用いられ、コンテンツ満了・置換モジュラー466は、配信されなかったコンテンツをプッシュプロキシ410で受信された新たなコンテンツと置換するために用いられる。
ここで、図6を参照する。図6は、コンテンツメタデータに対する多層エンベロープモデルを示す。
プッシュプロキシ410は、プロキシサーバ612およびプッシュクライアントエンベロープ614に対するコンテンツ処理メタデータを含むプッシュエンベロープ610を受信する。プッシュプロキシ410は、コンテンツ処理メタデータ612を抽出し、このメタデータをプッシュクライアントエンベロープ614を処理するために使用する。メタデータ612は、プッシュクライアントエンベロープ614で何を行うかをプッシュプロキシに記述する。
プッシュクライアントエンベロープ614は、コンテンツクライアント510にパスされ、そこで、コンテンツエンベロープ620と、コンテンツ処理メタデータ622とに分解される。コンテンツ処理メタデータ622は、コンテンツエンベロープ620を処理するために、プッシュクライアント510によって使用される。例えば、これは、クライアントアプリケーション150が、コンテンツの最新バージョンにのみ関心ある場合、プッシュクライアント510に命令して、以前に配信されたコンテンツエンベロープ620を最新のエンベロープに置換を実行するために使用され得る。
コンテンツエンベロープ620は、クライアントアプリケーション150にパスされる。コンテンツエンベロープは、アプリケーション用に対するコンテンツ処理メタデータ630、およびクライアントアプリケーション150によって消費されることになるコンテンツペイロード632を含む。
当業者には理解されるように、図6に従うエンベロープのネスティングは、処理がアーキテクチャの任意の処理エレメントで起こり得て、どのように特定のコンテンツが処理されるかをコンテンツプロバイダ110が特定し得るリッチな動的環境を備える。一つの実施形態において、特定のロジカルエレメントに向けられたメタデータは、他の処理エレメントに不透明(opaque)である。
代替として、サービスプロバイダ120は、またプッシュプロキシ410で、プッシュクライアント510またはクライアントアプリケーション150を処理するために、メタデータを追加し得る。
図7を参照すると、この図は、図6のエンベロープモデルと、各処理エレメントがエンベロープとともに行うステップとを示す。図7に示されるように、プッシュプロキシ410は、まずプッシュエンベロープ610からメタデータを抽出する。これは、ステップ710で行われる。
ステップ712で、プッシュプロキシ410は、メタデータを用いて、プッシュクライアントエンベロープ614を処理する。ステップ714で、プッシュプロキシ410は、プッシュクライアントエンベロープ614をプッシュクライアント510に配信する。
同様に、プッシュクライアント510は、ステップ720で、コンテンツ処理メタデータ622をプッシュクライアントエンベロープ614から抽出する。ステップ722において、プッシュクライアント510は、コンテンツエンベロープ620にコンテンツ処理メタデータ622を用いる。ステップ724で、プッシュクライアント510は、コンテンツエンベロープ620をクライアントアプリケーション150に配信する。
ステップ730で、クライアントアプリケーション150は、コンテンツ処理メタデータ630を抽出し、ステップ732で、コンテンツ処理メタデータ630をコンテンツペイロード632で用いる。
図8を参照すると、この図は、図7に示された方法に、静的メタデータまたはチャネルメタデータを用いる追加のステップとともに示す。具体的には、ステップ710で、メタデータがプッシュエンベロープ610から抽出された後、プッシュプロキシ410は、次いで、静的チャネルメタデータを用いて、ステップ810で、プッシュクライアントエンベロープを処理する。ステップ712で、プッシュプロキシ410は、次いで、コンテンツ処理動的メタデータ612を処理する。プッシュプロキシ410は、次いで、ステップ714で、プッシュクライアントエンベロープ614を配信する。
同様に、プッシュクライアント510は、ステップ720で、コンテンツ処理メタデータ622を抽出する。ステップ820において、プッシュクライアント510は、次いで、コンテンツエンベロープ620でコンテンツ処理メタデータ622を用いる。プッシュクライアント510は、次いで、ステップ722で、動的コンテンツメタデータをコンテンツ処理メタデータ622内で使用する。その後、ステップ724で、クライアントアプリケーション150にコンテンツエンベロープ620を配信する。
ステップ730で、クライアントアプリケーション150は、最初に、コンテンツ処理メタデータ630を抽出する。クライアントアプリケーション150は、次いで、ステップ830で、コンテンツペイロード632でチャネルメタデータを用いる。クライアントアプリケーション150は、次いで、ステップ732で、コンテンツペイロード632でコンテンツ処理メタデータ630を用いる。
当業者には理解されるように、上記のモデルによって、それゆえ、チャネルに対して適用される静的メタデータと、その特定のコンテンツと関連する動的メタデータと一緒に、その双方を送信すること可能になる。
ここで、図9を参照する。図5から分かるように、プッシュクライアント510は、移動デバイス上の複数のターゲットアプリケーション512にサービスし得る。アプリケーションが、他のアプリケーションに対するサービスを中断することなく、動的コンテンツ配信フレームワークを登録し得る効率的なランタイム登録メカニズムが、要求される。
図9を参照すると、プッシュクライアント510は、3つのアプリケーションを含み、具体的には、アプリケーション910、912および914は、既にプッシュクライアントに登録されている。理解されるように、プラグイン(plug in)モデルは、重要である。なぜなら、新しいデバイスは、制限のないアプリケーションタイプが、それらのデバイス上にインストールされることを可能にし得るからである。さらに、アプリケーションは、動的にインストールされ、移動デバイスがアプリケーションプラットホームになるように導き得る。なぜなら、デバイスは、アプリケーションプラットホームであり得、デバイスは、新たなアプリケーションを動的に組み込むことが可能であるはずだからである。
図9に示されるように、アプリケーション916は、プッシュクライアント510に登録したいと欲する。アプリケーション916は、アプリケーションマニフェスト918を含む。好ましい実施形態において、アプリケーションマニフェスト918は、そのアプリケーションに対するチャネルメタデータを提供する。特定的には、アプリケーションマニフェスト918は、情報をプッシュクライアント510に、そして、究極的には、図1のプッシュプロキシ410およびコンテンツプロバイダ110に、そのアプリケーションに対する静的メタデータとともに、情報を提供する。この情報には、どのタイプのコンテンツをこのアプリケーションが期待しているか、どのようにコンテンツが配信されるか、アプリケーションに通知が必要かどうか、あるいは、本システムおよび方法に関する分野の当業者にとって明らかであろう他のチャネル情報が含まれ得るが、これらに限定されない。
アプリケーション916は、それゆえ、プッシュクライアント510に登録され、アプリケーションマニフェスト918を提供し、アプリケーション916をサービスするためのコンテンツプロバイダにチャネルを確立する。
図10を参照すると、代替のモデルは、図2のアーキテクチャ220に対して記載されたモデルであり得る。具体的には、図10のモデルにおいて、クライアントアプリケーション150は、プッシュクライアント140とペアになっている。クライアントアプリケーション150/プッシュクライアント140のペアは、プッシュコンテナ1010を用いて調整される。
アプリケーション1020が、プッシュコンテナ1010に登録したいと願うとき、クライアント140が、プッシュコンテナ1010によって、生成されるか、あるいは、クライアント140が既に存在する場合は、使用される。さらに、登録において、アプリケーション1020は、アプリケーションマニフェスト1030をプッシュコンテナ1010に提供することによって、チャネルメタデータ(静的データ)をアプリケーション1020に対して提供する。
図10の代替の図が、図11に示される。具体的には、プッシュコンテナ1110が、プッシュクライアントのプールをマネージ/維持する。アプリケーションが、コンテナに登録されるとき、アプリケーションは、専用のプッシュクライアント510を得る。単純な場合において、これは、ソケットリスナ1130とコンテンツハンドラのペアによって表現され得る。プッシュクライアントは、アプリケーションがコンテナ(およびコンテンツ配信サービス)から登録解除されたとき、プールに戻るか、あるいは、デバイスから削除される。
プッシュコンテナ1110は、通信用ソケット1120を含む。さらに、プッシュコンテナ1110は、特定のソケットに割り当てられたソケットリスナ1130およびコンテンツプロセッサ1140を含む。
図11に示されるように、様々なコンテンツプロセッサおよびソケットリスナのペアが、以前に登録されたアプリケーション150によって使用される。
新たなアプリケーション1150は、プッシュコンテナ1110に登録されたいと欲するとき、新たなコンテンツプロセッサ1120およびソケットリスナ1130は、サービスアプリケーション1050に割り当てられる。
それゆえ、上記は、ジェネリックなプッシュフレームワークに対して提供される。このフレームワークにおいて、新しいクライアントアプリケーション150は、インプリメントされ得、プッシュクライアント510、あるいはプッシュコンテナ1010または1110に登録され得る。これによって、デバイスが、新たなアプリケーションを動的に組み込みことの可能なアプリケーションプラットホームとなることができる。上記の図9および図10のアプリケーションマニフェスト1030または918をパスすることによって、チャネルメタデータの確立が可能になり、これによって、コンテンツが、アプリケーションの要求に従って処理される。
図12を参照すると、コンテンツプロバイダ110は、同様に、プッシュプロキシ410に登録される必要がある。図12に示されるように、プッシュプロキシ410は、3つのコンテンツプロバイダ、すなわち、1210、1212および1214を含み、これらは既にプッシュプロキシ410に登録されている。コンテンツプロバイダ1216は、プッシュプロキシ410に登録されたいと願う。
図9に示されるアプリケーション916によって提供されたアプリケーションマニフェスト918と同様に、プッシュクライアント510に登録されるとき、コンテンツプロバイダ1216は、サービスマニフェスト1218を含み、このサービスマニフェスト1218は、コンテンツプロバイダ1216が登録するとき、プッシュプロキシ410にパスされる。サービスマニフェスト1218は、コンテンツプロバイダが提供する情報のタイプに関する情報、この情報を提供する頻度、情報のフォーマット、およびサービスまたはサービスの広告に有用な他の情報を含む。他の情報も可能である。
プッシュプロキシ410は、サービスマニフェスト1218を用いて、コンテンツプロバイダ1216に対するチャネル(静的)メタデータを確立する。
図13を参照すると、図2のアーキテクチャ230によって示される代替の実施形態は、プッシュプロキシ122およびコンテンツプロバイダ110のペアを幾つか備えたプッシュコンテナを有する。図12と同様に、様々なアプリケーションが、プッシュコンテナ1310に既に登録され得、図12の例において、アプリケーション1312、1314および1316は、それぞれプッシュプロキシ1313、1315および1317に既に登録されている。
新たなアプリケーション1320は、プッシュコンテナ1310に登録されたいと欲する。こうして、プッシュコンテナ1310は、新たなプロキシ(図示せず)を生成するか、あるいは、コンテンツプロバイダ1320と関連する既存のプロキシ(図示せず)を使用する。さらに、コンテンツプロバイダ1320は、サービスマニフェスト1322を提供し、コンテンツプロバイダ1320が提供することになるコンテンツを記述する。これによって、チャネルメタデータの確立が可能になる。
当業者には理解されるように、図9および図10の実施形態は、プッシュクライアントに対する2つの選択肢を示し、それは、共有アプリケーションであるか、あるいは、アプリケーションごとに専用プッシュクライアントであるかのいずれかである。当業者は、他の実施形態も可能であることを理解する。同様に、図12および図13に関して、自身に登録された複数のコンテンツプロバイダを有するプッシュプロキシが示されるか、あるいは、各コンテンツプロバイダ対して専用で、プッシュコンテナに統合されたプッシュプロキシが示される。
図14を参照すると、コンテンツプロバイダ110とクライアントアプリケーション150との間のメッセージ伝達が示される。コンテンツプロバイダ110は、プッシュプロキシ410への登録メッセージを提供する。このメッセージには、プッシュプロキシ410にチャネルメタデータを提供するために使用され得るサービスマニフェストを含み得る。これは、ステップ1410で行われる。
コンテンツプロバイダ110は、また、あるいは代替として、ステップ1412で示されるように、チャネルメタデータを引き続くメッセージに提供し得る。
プッシュプロキシ410は、次いで、ステップ1414で、利用可能なサービスのリスト(サービスカタログ)に、サービスを追加する。
図14の例における随意のステップは、ステップ1416で、プッシュプロキシ410に、プッシュクライアント510に新たな利用可能なサービスを通知するためである。この通知は、ステップ1418で、クライアントアプリケーション110に伝播され得る。
当業者には理解されるように、ステップ1416および1418は随意であり、他の代替には、クライアントアプリケーション150が、新たなサービスを閲覧するために、プッシュプロキシ410から定期的にサービスカタログをプルすることを含む。
クライアントアプリケーション150に対するユーザまたはサービスプロバイダは、アプリケーション150がサービスに加入するべきであると決定し、クライアントアプリケーション150は、ステップ1420で、加入メッセージを送信する。この加入メッセージは、ステップ1422で、さらにプッシュプロキシ410にパスされる。
一度、プッシュプロキシ410が、ステップ1422で加入メッセージを受信すると、2つの選択肢が利用可能である。第一の選択肢は、加入するために、メッセージ1424をコンテンツプロバイダ110に送信し、次いで、ステップ1426に戻って、メタデータを含むメッセージエンベロープを受信する。このメタデータは、デバイスまたはデバイスのタイプに特定的であり得る。
代替として、プッシュプロキシ410は、ステップ1422で、コンテンツプロバイダ110によって既に提供され、プッシュプロキシ410に格納された情報に基づいて、加入メッセージを受信し得、ステップ1430で、プッシュクライアント510に返答する。この返答は、ステップ1532で、クライアントアプリケーション150に伝播される。理解されるように、この返答は、コンテンツプロバイダ110に特定的なチャネルメタデータを含み得る。
モデル間の違いは、そのアプリケーションに対するデータを誰がカスタム化するかに依存し得る。理解されるように、コンテンツプロバイダ110は、他の処理エレメントと比べて、コンテンツの最良のカスタム化を提供する。しかしながら、また、サービスプロバイダ120も、プッシュプロキシ410を介して、コンテンツのカスタム化も提供し得る。
さらに、理解されるように、コンテンツの構造は、アプリケーションが要求するデータに依存し得る。例えば、金融でのアプリケーションにおいて、アプリケーションは、株価と為替レートとの双方を欲し得る。以下のXML:
<FIN>
<quotes>
<quote ticker=ABC>
18.54
</quote>
<quote ticker=XYZ>
123.45
</quote>
</quotes>
<rates>
<rate id=“US−CAN”>
1.15
</rate>
<rate id=“US−EURO”>
0.85
</rate>
</rates>
</FIN>
が使用され得る。
ユーザが、株価のみを欲し、為替レートを欲しない場合、構造は、以下:
<FIN>
<quote ticker=ABC>
18.54
</quote>
<quote ticker=XYZ>
123.45
</quote>
</FIN>
のように変化し得る。
メタデータは、アプリケーションに、構造にデータはパスされているという情報を提供し得る。
したがって、2つのモデルが存在する。静的データが、登録中に、または登録後に、プッシュプロキシ410およびプッシュクライアント510に提供され得る。代替として、プッシュプロキシ410およびプッシュクライアント510に対するメタデータは、事前に用意され得る。すなわち、情報は、アプリケーションがクライアントに登録されるまで、プッシュクライアントまたはプッシュプロキシに格納される。
ここで、図15を参照する。図15は、プッシュクライアント510にアプリケーションを登録すると生じるロジカルステップを示す。
一度、アプリケーションがプッシュクライアント510に登録されると、第一のステップ1510は、登録されたアプリケーションを、そのアプリケーションによって要求されるコンテンツタイプと合わせることである。これは、図9に示されるように、アプリケーションマニフェスト918から知られている。
第二のステップ1520は、アプリケーションに対する環境を設定することである。これらには、アプリケーションに対する格納および配信を随意に含むが、これらに限定されない。例えば、アプリケーションは、送信を所定のデータ量で制限し得る。フロー制御のイベントにおいて、あるいは、アプリケーションまたはクライアントが連絡を取らない場合、プッシュクライアント510は、アプリケーションに対するデータを捕らえることと、そして、随意で、データが待っている旨をアプリケーションに通知することとを要求し得る。
第三のステップ1530は、プッシュプロキシ410にアプリケーション設定を通知することである。これには、例えば、アプリケーションまたはプッシュクライアント510に利用可能なストレージを含む。理解されるように、プッシュプロキシ410は、プッシュクライアント510が格納し得るより多くのデータをプッシュしてはならない。したがって、アプリケーション設定は、パスされるデータの上限を含み得る。図4および図5を参照すると、これは、コンテンツ断片化ブロック464を呼び出し、アプリケーションが処理し得るより大きいコンテンツの場合、コンテンツを断片化し得る。また、データが非線形の場合、コンテンツ依存ブロック462は、図5のコンテンツ依存ブロック564用のメタデータを生成することを要求され得る。これは、コンテンツ依存ブロック564が、データを再構成することができるようにするためである。
再び、図15を参照すると、ステップ1530は、また、データ配信に対する優先度を指示し得る。例えば、アプリケーションは、あるタイプのデータを他のタイプのデータに対して優先し得、これらのタイプのデータには、優先度が与えられ得る。こうして、ステップ1530は、タイプ「A」のデータが即座に配信されるのに対し、タイプ「B」のデータが据え置き時間に配信され得る。
ここで、図16を参照する。コンテンツプロバイダ110が、プッシュプロキシ410に登録されるとき、様々なステップが実行される。第一のステップ1610は、コンテンツ格納および配信に対して要求されたクライアント設定を解析することを含む。これは、コンテンツプロバイダ110からのコンテンツを消費できるデバイス上のプッシュクライアント510を同定するために、例えば、サービス広告に使用され得る。
第二のステップ1620は、とりわけ、プロキシ格納、配信オプション、変換オプションを含むプッシュプロキシが環境を設定することを可能にする。
ステップ1630で、プッシュプロキシ410は、アプリケーションが既にコンテンツプロバイダ110に登録されたかどうかをチェックし得る。このような場合、アプリケーションは、コンテンツと、配信チャネルが確立され、アプリケーションはコンテンツが送信され得る準備ができているという旨で、プッシュプロキシ410からコンテンツプロバイダ110への通知とを受信する準備ができている。
ステップ1630は、例えば、コンテンツプロバイダ110がオンラインに来る前に、アプリケーションがデバイスに事前にインストールされる場合に生じ得る。したがって、アプリケーションは、コンテンツプロバイダ110が利用可能になるのを待っているか、あるいは、アプリケーションがジェネリックタイプ(例えば、ブラウザまたRSSビューア)で、複数のコンテンツプロバイダからの情報を消費できるかである。代替の設定において、コンテンツプロバイダ110は、アプリケーションがインストールされる前に既に利用可能であり、図15の通知ステップ1530は、コンテンツを開始するために使用され得、コンテンツプロバイダ110からクライアントアプリケーション150へのフローを開始し得る。
図16を参照して理解されるように、クライアント設定は、所定の情報を含み得る。この情報は、例えば、とりわけ、コンテンツ仕切りに対して使用される利用可能なストレージサイズ、フロー制御に対して使用される待ち行列サイズ、プッシュインターバルを含む配信スケジューリング、クライアントがプロキシから情報を取り出しているかどうか、偽プッシュモードを生成しているか、移動デバイスの画面サイズのようなカスタム化オプションである。
さらに理解されるように、サービスカタログは、異なるクライアントに対して、異なり得る。例えば、あるクライアントは、より多くのデータを利用可能であり得、異なる画面サイズ、または、他の条件を有し得る。これによって、コンテンツプロバイダ110に対し、そのクライアントは、この量の情報を扱い得ず、より小さな画面サイズなどを有するデバイスに比べ、より適切なものとなる。したがって、プッシュプロキシ410は、特定のクライアントアプリケーションに対するサービスカタログを、これらのクライアントアプリケーションの知識に基づいて生成し得、このクライアントアプリケーション150を有するこれらのデバイスのみが、コンテンツプロバイダに関する情報を受信し得る。
さらに理解されるように、一部の場合において、アプリケーションは、ユーザが介入することなく、サービスプロバイダおよびコンテンツプロバイダに基づいてインストールされ得る。例えば、コンテンツプロバイダ110は、プッシュプロキシ410に登録される場合、移動デバイスのユーザは、所定の情報を受け入れる契約義務を有し得る。したがって、プッシュプロキシ410は、アプリケーションをインストールし、アプリケーションをプッシュクライアント510にプッシュする準備ができていることをプッシュクライアント510を通知し得る。これは、例えば、ユーザが、自分の移動デバイスプランに優遇料金を得るために、所定量の広告を毎月受信することに同意したことを含み得る。コンテンツプロバイダ110は、広告プロバイダであり得、プッシュプロキシ410は、それゆえ、プッシュクライアント510に広告表示アプリケーションをプッシュし得る。このプッシュクライアント510は、プッシュクライアント410に登録されたアプリケーションインストーラによってサービスされ得、これによって、その処理を完全に駆動するコンテンツプロバイダ110およびサービスプロバイダ120を有する。
それゆえ、上記は、各アプリケーションまたはコンテンツプロバイダが、アプリケーションマニフェストまたはサービスマニフェストをそれぞれ登録し、提供するところに、プッシュフレームワークにおけるプラグイン登録モデルを提供する。アプリケーションマニフェストまたはサービスマニフェストは、登録中に、または登録に引き続き、プッシュプロキシ410およびプッシュクライアント510に、チャネルメタデータを確立するために使用される。その後、アプリケーション150が登録し、コンテンツプロバイダ110が登録するとき、コンテンツは、アプリケーション150とコンテンツプロバイダ110との間を流れ始め得る。
図4および図5を参照すると、チャネルメタデータは、メタデータ貯蔵庫470および570に格納される。しかしながら、動的メタデータが繰り返される場合、アーキテクチャ100内に、様々な処理エレメント上に動的メタデータを格納することは、また有利である。理解されるように、これによって、プッシュプロキシ410上での処理の節約となる。なぜなら、現在のメタデータ抽出器450は、同じメタデータを何度も抽出する必要がなくなるからである。さらに、コンテンツ満了・置換モジュール466または566のような様々なモジュールは、パスされるコンテンツの各ピースに対して更新される必要がない。なぜなら、プッシュプロキシ410は、大量のプッシュクライアント510と協働し得るので、各コンテンツメッセージに対するこの処理の節約は、有意義であり得る。さらに、帯域幅は、コンテンツプロバイダ110とプッシュプロキシ410との間の固定ラインを介して、あるいは、プッシュプロキシ410とプッシュクライアント510との間の無線通信機器を介して、メタデータをパスする必要がないことによって、節約され得る。
ここで、図17を参照する。図17は、自分の最後のメタデータバージョンが処理エレメントによって格納される場合のランタイムフローの例を示す。
図17に示されるように、コンテンツプロバイダ110は、コンテンツ[C+M(p,c,a)]を含むコンテンツエンベロープを提供する。これは、第一のコンテンツペイロードが、プロキシメタデータ、クライアントメタデータおよびアプリケーションメタデータを含むメタデータに沿って流れることを意味する。これは、ステップ1710で送信される。
ステップ1712で、プッシュプロキシ410は、「M(P)を使用せよ」という文によって表わされているプロキシメタデータを使用する。さらに、ステップ1714で、
クライアントメタデータおよびアプリケーションメタデータを含むこのコンテンツプラスメタデータは、プッシュクライアント510にパスされる。
プッシュクライアント510は、ステップ1716で、クライアントメタデータを使用し、さらに、ステップ1718で、コンテンツペイロードをクライアントアプリケーション150にパスする。クライアントアプリケーション150は、ステップ1720で、アプリケーションメタデータを使用し、さらに、コンテンツペイロードを消費する。
ステップ1722で、Cによって指定される第二のコンテンツペイロードは、第一のコンテンツペイロードと同じメタデータを有する。なぜなら、各処理エレメントは、すなわち、プッシュプロキシ410、プッシュクライアント510およびクライアントアプリケーション150は、コンテンツプロバイダ110に対するメタデータをキャッシュ化し、メタデータは、再びパスされる必要がないが、その代わりに、既に、処理エレメント上に常駐している。
その後、ステップ1724で、プッシュプロキシ410は、プッシュプロキシ410に対して以前にキャッシュ化されたメタデータを使用する。同様に、ステップ1726および1728で、プッシュクライアント510は、クライアントメタデータを使用し、クライアントアプリケーション150は、アプリケーションメタデータをそれぞれ使用する。ステップ1725および1727で、コンテンツは、メタデータを使用せずに、パスされる。
ステップ1740に示されるように、コンテンツは、プッシュクライアント510およびクライアントアプリケーション150に対する新たなメタデータを有し得るが、プッシュプロキシ410に対する古いメタデータを保存し得る。この場合、ステップ1740でパスされるメタデータは、クライアントメタデータおよびアプリケーションメタデータのみを含む。ステップ1742で、プッシュプロキシ410は、キャッシュ化プロキシメタデータを用いて、ステップ1744で、新たなクライアントメタデータおよびアプリケーションメタデータと一緒にコンテンツペイロードをパスする。
ステップ1746で、プッシュクライアント510は、自身にパスされた新たなクライアントメタデータを用いて、さらに、ステップ1748で、コンテンツペイロードおよびアプリケーションメタデータをパスする。
ステップ1750で、クライアントアプリケーションは、新たなアプリケーションメタデータを用い、さらにコンテンツペイロードを消費する。
当業者には理解されるように、メタデータが変化すること、メタデータが同じままで留まること、および変化したメタデータのみがそれを必要とする処理エレメントにパスされることに関して、様々な構成が存在し得る。当業者には理解されるように、処理エレメントは、自身が新たなメタデータを受信しない場合、自身が格納したキャッシュ化メタデータに戻り、これをコンテンツペイロード上で用いる。
更なる代替の実施形態において、インクリメントによる変化が、またメタデータになされ得る。例えば、ステップ1760で、新たなコンテンツペイロードは、デルタメタデータバージョンとともに、サービスプロキシ410にパスされ得る。プロキシメタデータのデルタは、以前にパスされたプロキシメタデータと、コンテンツが処理されるべき現在のメタデータとの間の差を含み得る。プッシュプロキシ410は、デルタを有する以前のメタデータを加えて、メタデータを構成し、次いで、ステップ1762で、これを用いてコンテンツペイロードを処理する。その後、変化がなかったので、ステップ1764で、コンテンツペイロードは、自身によって送信され、ステップ1766で、プッシュクライアント510は、以前にキャッシュ化されたクライアントメタデータを用いる。
プッシュクライアントは、次いで、ステップ1768で、コンテンツペイロードをクライアントアプリケーション150にパスし、このクライアントアプリケーション150は、ステップ1770で、コンテンツペイロード上の以前にキャッシュ化されたロケーションメタデータを用い、次いで、それをコンテンツペイロードで消費する。
インクリメンタルなデータの例は、コンテンツプロバイダが、コンテンツペイロード内の既存のフィールドの中で、30が抽出され、クライアントアプリケーション150に送信されるべきであると、プロキシに告げる状況において使用され得る。引き続くトランザクションで、そのコンテンツペイロードのピースにとって重要である2つの追加フィールドが、コンテンツプロバイダ110によって、クライアントアプリケーション150にパスされる必要と思われ得る。コンテンツプロバイダは、それゆえ、インクリメンタルな変化を用いて、2つの追加のフィールドを抽出し、それらを以前に抽出された30フィールドに追加するように、プロキシに告げ得る。デルタ(すなわち、2つの追加フィールド)をパスすることを必要とするだけなので、プッシュプロキシ410でメタデータを抽出するための処理時間は、削減され、それによって、処理は最適化される。
さらに理解されるように、メタデータは、様々な形式で到来し得る。メタデータは、ネイティブコード、あるいはJava(登録商標)またはC#(登録商標)のようなインタープリタ型コードでコンパイルされ得る。メタデータは、所定のプロパティを使用することを示すまた、データ/プロパティファイルでもあり得る。別の代替の実施形態において、メタデータは、バイナリコンテンツであり得て、例えば、XMLドキュメント上のXSLT変換のような変換であり得る。
上記は、様々なアプリケーションに対して使用され、特定のクライアントアプリケーションにトランスファーされるコンテンツに対して、知能を提供し得る。また、上記は、単に、様々なコンテンツプロバイダが自分のデータを提供するメタデータに単に基づくことで、様々なアプリケーションに対するコンテンツを提供し得るリッチなコンテンツプロバイダに対しても提供され得る。これは、図18の例によって示され得る。
コンテンツプロバイダ110は、例えば、オンライン書店であり得る。アプリケーションは、オンライン書店に登録し得、アプリケーション自らは、特定のジャンルの新刊を知らせて欲しいことをオンライン書店に指示し得る。これは、毎日、または毎週、あるいは毎月ベースで起こり得る。
コンテンツプロバイダ110は、例えば、ブックリスト1812を有するコンテンツエンベロープ1810をプッシュプロキシ410に送信し得る。また、コンテンツプロバイダが、変換(transform)メタデータ1814も送信し得、このメタデータ1814は、例えば、自身が受信するアプリケーションに基づいて特定のコンテンツを変換するためのURLリンクであり得る。
一実施形態において、ブックリスト1812は、多数の本発明を含み得、本の著者と概要とを含む各本の記載を含む。ファイルは、例えば、サイズが100KBであり得る。
プッシュプロキシ410は、この大きなファイルを受信し得、サービスされているクライアントアプリケーションに基づいて、その大きなコンテンツファイルにされる必要がある変換を実現し得る。それは、クライアントにより良く適合するために、例えば、クライアントが受信可能であり得る10キロバイトの情報に適合するためである。プロキシメタデータとしてパスされる変換は、それゆえ、ブックリストを10KB修正ドキュメント1820に縮小するために、ブックリストに適用され得る。これは、例えば、概要を取り除き、本をランク付けし、上位50冊のみを含めることによって、あるいは、当業者には明らかな他の変換によって、行われ得る。
一度、変換が完了すれば、修正ドキュメント1820は、次いで、プッシュクライアント510に送信される。
さらに、図4に示されるような据え置き検索メッセージストア452が、変換プロセスで取り除かれた格外のコンテンツを格納するために使用される。
上記の利点は、書店が1つのサイトを有し得、そのクライアントの全てに1つのリストを送り得ることである。様々なクライアントが、移動無線クライアントではないので、100KBファイルもこれらのクライアントに対して適切であり得る。また、変換データを提供することによって、書店は、書店が全員に送信する1つのリストを有し得る。当業者には理解されるように、ほとんどの現在のウェブ技術は、移動クライアントに対する別個のウェブサイトを要求するが、このことが上記の解決策によって克服される。
上記は、また、シンジゲートされたモデルに結び付き、ここで、図19を参照する。
当業者には理解されるように、移動デバイスは、ネットワーク条件が大量のデータを受信するのに最適でないとき、大量のデータを受信することを望まないことがあり得る。さらに、ネットワークオペレータは、ネットワークのトラフィックが時間に対して、より均一になるようにするために、帯域幅の利用がピークの間は、大量のデータを送信することを避けたいと望み得る。これは、図19に示されるように、プッシュ/プルモデルを用いて達成され得る。
図4を参照して以上に記載されたように、コンテンツは、ユーザが現在必要とし得るより多くの情報を含んで、提供され得る。例えば、ユーザが、自分のエリア内のレストランに対するロケーション情報をリクエストする場合、サービスプロバイダは、そのエリア内で利用可能な他のサービスのような広告を追加したいと望み得る。しかしながら、サービスプロバイダは、この追加コンテンツを即座にユーザへプッシュしたいと望まず、その代わりに、その追加コンテンツを示す見出しまたは目次のようなプライマ(primer)を提供したいと望み得る。
他の状況において、コンテンツは、ユーザにとってあまりにも大きくあり得るので、ユーザは、コンテンツの第一部のみを受信し得、そのコンテンツの残りは、据え置き検索メッセージストア452に格納される。
その後、格納されたコンテンツは、プッシュプロキシ410によって、あるいは自分のプッシュクライアント510に対して問われたときのいずれかに、プッシュクライアント510にパスされ得る。
プッシュクライアント510は、ネットワークのステータスをモニタし得るネットワークステータスモニタ1910を含む。プッシュクライアント510は、ある種の条件で、格外のデータを受信するのみでありたいと望み得る。例えば、WiFiおよびセルラのオプションを有するハイブリッド移動デバイス上で、WiFi接続上のデータを提供する方が安価である。それゆえ、ネットワークステータスモニタ1910は、据え置きされたコンテンツを入手する前に、プッシュクライアント510がWiFiネットワークに接続されるまで待ち得る。代替として、ネットワークステータスモニタは、ローミング料金を最低にするために、クライアントが外国のネットワーク内でローミングしているのか。国内のネットワークで接続されているのかをチェックし得る。ネットワークステータスモニタは、また、専用データチャネルがデバイス用に確立されているかどうかをチェックし得る。プッシュクライアント510にパスされるべく据え置かれたデータをリクエストする前に、ネットワークステータスモニタ1910は、またネットワーク内の様々な他の前提条件をチェックし得ることを当業者は理解する。
無線ネットワーク130は、またプッシュクライアント510とプッシュプロキシ410との一方または双方に、データ配信のコストに関する情報を提供し得る。当業者には理解されるように、様々なピーク時間が、コンテンツ配信に生じる。交通情報の場合、ピーク時間は、人々が職場に行き、帰りする平日の始業および終業であり得る。株価に関しては、ピーク時間は、市場が開いている時間の間であり得る。他のピークも存在する。データトラフィックを平均化するために、ネットワーク内での現在のデータ利用に基づき、異なる料金を課すことが、ネットワークにとって望ましくあり得る。したがって、ピーク時間は、真夜中のような非ピーク時間に比べて、高い料金が課され得る。無線ネットワーク130は、それゆえ、プッシュクライアント510上の据え置き検索マネージャ552およびプッシュプロキシ410上のプッシュスケジューラ454に、配信コスト通知を提供する。
一つの実施形態において、コンテンツプロバイダ110からで、プッシュプロキシ410へパスされるデータは、クライアントにとってのその重要度に基づいてランク付けされ得る。ある種の情報は、メタデータを介して即座に配信されるように指定され得る。別の情報は、ネットワークコストが、第一の値(例えば、1メガバイト当たり10セント)より小さいときに配信されるように指定され得、他のデータは、第二の値(例えば、1メガバイト当たり5セント)より小さいときに配信されるように指定され得る。こうして、スケジューラ454は、据え置き検索メッセージストア452内に格納されるデータを考慮し、据え置かれたデータをプッシュクライアント510のプッシュエージェント544にパスするように、プッシュエージェント444に命令する。
代替として、据え置き検索マネージャ552は、無線ネットワーク130から送信されるようなネットワーク状態をモニタし得、データ速度が、所定の速度未満の場合、コンテンツプルブローカ554に、据え置き検索メッセージストア452からのコンテンツをプルするように頼み得る。
代替として、マネージャ552は、ネットワークステータスが、より大量のデータをプルするのに好都合であること、例えば、移動デバイスがWiFiネットワークに接続されていたかどうかのようなことを確認し得、コンテンツプルブローカに、データを据え置き検索メッセージストア452からプルするように頼み得る。
さらに理解されるように、ユーザは、常にコンテンツがプルされるようにリクエストし得る。したがって、ユーザのリクエスト1940は、コンテンツプルブローカ554をトリガして、据え置き検索メッセージストア452からデータをプルするために使用され得る。
プッシュスケジューラ454および据え置き検索マネージャ552内に格納されたルールは、コンテンツの分類に基づく静的メタデータであり得る。ルールは、また、パスされてきた特定のデータに対する動的メタデータに基づき得る。この場合、コンテンツプロバイダ110は、データを分類する。
ここで、図20を参照する。当業者には理解されるように、データは、線形または非線形の2つの形式の一方であり得る。線形データは、例えば、線形に流れるアレイまたはストリングあるいはコンテンツであり得る。非線形データは、逆に、互いに線形に関係しないデータであり、コンテンツマップまたはリンクに複雑に依存することを含み得る。
線形のコンテンツに対し、断片化は、データを線形進行(linear progression)に基づく様々なコンポーネントに分解する(break)ことをただ伴うだけである。データは、セグメントに区分され、セグメントは、プッシュクライアント410に配信される。図20に示されるように、断片化プロセッサ2010は、コンテンツ2012と相互作用し、コンテンツが線形進行とともに解析され(parsed)得ることを決定する。断片化プロセッサ2010は、次いで、データを図20の例のセグメント2014、2016、および2018に区分し、図20に示されるように、第二および第三のセグメント2016および2018をそれぞれパスすることを据え置く間に、第一のセグメント2014をパスする。
カーソルマネージメントモジュール2030は、配信されたセグメントの跡をつけ、順番に次のセグメントを配信する。
図21を参照すると、非線形コンテンツは、より賢明な方法で区分される必要がある。さらに、先方で、セグメントを再構成するために、メタデータが要求される。
断片化プロセッサ2110は、メタデータベースの解析に基づき、コンテンツを解析する。これらは、論理的に要求される場合、所定のセグメントまたはデータエレメントを一緒に保つことを含む。断片化プロセッサ2110は、コンテンツ2112を解析し、コンテンツを論理的なルールに基づいて、セグメントに区分する。各セグメントは、コンテンツとメタデータとを含み、例えば、各コンダクタセグメントに対する依存性、マップ、およびナビゲーションルールを含む。
一度区分されると、第一のセグメント2114は、プッシュクライアント510に送信され、セグメント2116および2118の残余が、図21に示されるように据え置かれる。セグメントナビゲーションブロック2130は、どのセグメントを次に送信するかを扱う。当業者には理解されるように、セグメント2114は、データ部分およびメタデータ部分を含む。セグメント2114のメタデータ部分は、断片化プロセッサ2110によって加えられるメタデータの層であり、そのコンテンツをどのように再構成するかをコンテンツ依存性モジュール564に指示する。第一のセグメント2114のデータ部分は、チャネルまたはコンテンツと関連するコンテンツおよびメタデータの双方を含み得る。
セグメントナビゲーションブロック2130は、いかにユーザがそのデータを介してトラベルするかを処理するように適応される。例えば、データがツリーフォーマットであり、ユーザがツリーの第一のブランチに下りていくと、セグメントナビゲーションブロック2130は、プッシュクライアント410に、ユーザがナビゲートしてきたエレメントから到達し得るツリーの他のブランチをパスされ得る。
例えば、ツリーは、会社の構造に沿った従業員名を有する従業員データベースを含み得る。図21に基づき、ユーザが組織の特定の課の中にナビゲートすると、そのセグメンテーションナビゲーションブロック2130は、その課の中のグループに対するグループ断片に転送し得る。次いで、ユーザがその課の特定のグループの中にナビゲートすると、そのセグメンテーションナビゲーションブロック2130は、そのグループの中の従業員に対する情報断片をパスし得る。
それゆえ、上記は、データがロジカルコンポーネントに区分されることを要求する。識別子は、全てのタイプおよびコンテンツに割り当てられ、構造的情報は、プライマを有する情報をパスして生成される。
上記は、それゆえ、システムの構造を変化させることなく、アプリケーションおよびコンテンツを追加され得るジェネリックシステムで使用され得る動的コンテンツ配信に対するアーキテクチャを提供する。コンテンツは、そのコンテンツを受信するアプリケーションに適合するように個別仕上げされ得、上記に従って、断片化され得る。
理解されるように、プッシュクライアントおよびクライアントアプリケーションは、任意の移動デバイスに常駐し得る。一つの例示的な移動デバイスは、図22を参照して以下に記載される。これは、限定することを意味するものでなく、例示的な目的で提供指される。
図22は、本出願の装置および方法の好ましい実施形態で使用されることの多い移動局を示すブロック図である。移動局2200は、少なくとも音声およびデータ通信能力を有する双方向通信デバイスであることが好ましい。移動局2200は、インターネット上の他のコンピュータシステムとの通信能力があることが好ましい。提供される正確な機能性に依存して、この無線機器は、例えば、データメッセージングデバイス、双方向ページャ、データメッセージング能力を有する携帯電話、無線インターネット機器、あるいは、データ通信装置を意味し得る。
移動局2200は、双方向通信が可能なとき、通常、通信サブシステム2211を組み込む。通信サブシステム2211は、受信機2212、送信機2214、1つ以上の(好ましくは内蔵されているか内部の)アンテナエレメント2216および2218などの関連コンポーネント、局部発振器(LO)2213、デジタル信号プロセッサ(DSP)2220などの処理モジュールを含む。通信分野の当業者に明らかなように、通信サブシステム2211の特定の設計は、その機器が動作するように意図される通信ネットワークに依存する。
ネットワークアクセス要求は、また、ネットワーク2219のタイプに依存しても変化する。一部のCDMAネットワークにおいて、ネットワークアクセスは、移動局2200の加入者またはユーザに関連する。CDMA移動局は、CDMAネットワーク上で動作するために、取り外し可能ユーザ識別モジュール(RUIM)または加入者識別モジュール(SIM)カードを要求する。SIM/RUIMインターフェース2244は、通常はカードスロットに似ており、この中に、ディスケットまたはPCMCIAカードのように、SIM/RUIMカードが挿入および排出され得る。SIM/RUIMカードは、約64Kのメモリを有し、多数のキー構成2251と、IDおよび加入者関連情報のような他の情報2253を保持し得る。
要求されるネットワーク登録または活性化手順が完了したとき、移動局2200は、ネットワーク2219を介して、通信信号を送受信し得る。図22に示されるように、ネットワーク2219は、移動デバイスと通信する複数の基地局からなり得る。例えば、ハイブリッドCDMA 1xEVDOシステムにおいて、CDMA基地局およびEVDO基地局は、移動局と通信し、その移動局は同時に両者と接続される。EVDO基地局およびCDMA 1x基地局は、異なるページングスロットを用いて、移動デバイスと通信する。
通信ネットワーク2219を介してアンテナ2216によって受信された信号は受信機2212へ入力され、受信機2212は、信号増幅、周波数下方変換、フィルタリング、チャンネル選択など、および、図22に示される例のシステムにあるアナログデジタル(A/D)変換などの一般的な受信機の機能を実行し得る。受信信号のA/D変換によって、DSP2220において実行される復調および復号化などのより複雑な通信機能が可能になる。同様に、送信されるべき信号は、例えば、DSP2220による変調および符号化を含む処理がされる。これらのDSP処理された信号は、デジタルアナログ変換、周波数上方変換、フィルタリング、増幅、アンテナ2218を介した通信ネットワーク上への送信のために、送信機2214へ入力される。DSP2220は、通信信号を処理するだけでなく、受信機および送信機の制御を提供する。例えば、受信機2212および送信機2214における通信信号に付与されるゲインは、DSP2220内でインプリメントされる自動ゲイン制御アルゴリズムを介して適合するように制御され得る。
移動局2200は、機器の動作全体を制御するマイクロプロセッサ2238を含むことが好ましい。少なくともデータおよび音声通信を含む通信機能は、通信サブシステム2211を介して実行される。また、マイクロプロセッサ2238は、ディスプレイ2222、フラッシュメモリ2224、ランダムアクセスメモリ(RAM)2226、補助入力/出力(I/O)サブシステム2228、シリアルポート2230、2つ以上のキーボードまたはキーパッド2232、スピーカ2234、マイク2236、短距離通信サブシステムのような他の通信サブシステム2240、および、一般的に2242で示される任意の他のデバイスサブシステムなどの追加デバイスサブシステムと相互作用する。シリアルポート2230は、USBポート、または当業者には周知の他のポートを含み得る。
図22に示されるサブシステムの一部は、通信関連の機能を実行するのに対して、他のサブシステムは「常駐の」またはオンデバイス機能を提供し得る。とりわけ、キーボード2232およびディスプレイ2222などの一部のサブシステムは、例えば、通信ネットワークを介する送信のためのテキストメッセージの入力などの通信関連機能と、計算器またはタスクリストのようなデバイス常駐機能との双方のために用いられ得る。
マイクロプロセッサ2238によって用いられるオペレーティングシステムソフトウェアは、フラッシュメモリ2224などの持続性ストアに格納されることが好ましい。フラッシュメモリ2224は、代替として、読み出し専用メモリ(ROM)または同様のストレージエレメント(図示せず)であり得る。オペレーティングシステム、特定のデバイスアプリケーション、またはそのパーツが、RAM2226などのような揮発性メモリの中に一時的にロードされ得ることは、当業者には理解される。また、受信された通信信号は、RAM2226にも格納され得る。
図示されるように、フラッシュメモリ2224は、コンピュータプログラム2258と、プログラムデータストレージ2250、2252、2254および2256との双方の異なるエリアの中に分離され得る。これらの異なるストレージタイプは、これら自身のデータストレージ要求のために、各プログラムがフラッシュメモリ2224の一部分に割り当てられ得ることを示す。マイクロプロセッサ2238は、そのオペレーティングシステム機能に加えて、移動局上でソフトウェアプリケーションの実行を可能にすることが好ましい。例えば、少なくともデータおよび音声の通信アプリケーションを含む基本的な動作を制御する所定のアプリケーションのセットは、通常は製造中に移動局2200にインストールされる。他のアプリケーションも、引き続き、あるいは動的にインストールされ得る。
好ましいソフトウェアアプリケーションは、移動局のユーザに関連するデータ項目を編成および管理する能力を有する個人情報管理(PIM)アプリケーションであり得る。ユーザに関連する項目としては、eメール、カレンダーイベント、音声メール、約束、タスク項目などが挙げられるが、これらに限定されない。当然、1つ以上のメモリストアは、移動局において利用可能であり、PIMデータ項目のストレージを容易にする。このようなPIMアプリケーションは、無線ネットワーク2219を介してデータ項目を送受信する能力を有することが好ましい。好ましい実施形態において、PIMデータ項目は、無線ネットワーク2219を介して、ホストコンピュータシステムに格納または関連付けされた移動局ユーザの対応データ項目を用いて、継続的に統合、同期および更新される。更なるアプリケーションは、また、ネットワーク2219、補助I/Oサブシステム2228、シリアルポート2230、短距離通信サブシステム2240、または任意の他の適切なサブシステム2242を介して移動局2200上にロードされ得て、マイクロプロセッサ2238による実行のためにRAM2226または好ましくは不揮発性ストア(図示せず)内に、ユーザによってインストールされ得る。アプリケーションのインストールにおけるそのような柔軟性は、機器の機能性を高め、オンデバイス機能、通信関連機能、またはその双方の強化を提供し得る。例えば、確実な通信アプリケーションによって、移動局2200を用いて実行される電子商取引機能および他のそのような金融取引が可能となり得る。
データ通信モードにおいて、テキストメッセージまたはウェブページダウンロードのような受信信号は、通信サブシステム2211によって処理され、マイクロプロセッサ2238に入力される。マイクロプロセッサ2238は、ディスプレイ2222または代替として補助I/Oデバイス2228への出力のために、受信信号をさらに処理することが好ましい。プッシュクライアント140および510と同等であり得るプッシュクライアント2260は、また、入力も処理し得る。
移動局2200のユーザは、また、例えば、ディスプレイ2222およびおそらく補助I/Oデバイス2228と連動するキーボード2232を用いてeメールメッセージのようなデータ項目を構成し得る。キーボード2232は、完全な英数字キーボードまたは電話タイプのキーパッドであることが好ましい。このように構成された項目は、通信サブシステム2211を介して通信ネットワークに送信され得る。
音声通信のために、移動局2200の動作全体は、類似している。ただし、受信信号は、好ましくはスピーカ2234への出力であり、送信のための信号はマイク2236によって生成されるという点は除く。サブシステムを記録する音声メッセージのような代替の音声またはオーディオI/Oサブシステムは、また移動局2200においてインプリメントされ得る。音声またはオーディオ信号出力は主にスピーカ2234を介して達成されることが好ましいが、ディスプレイ2222もまた用いられ得て、例えば、呼び出し人のアイデンティティの表示、音声呼び出しの長さ、他の音声呼び出し関連情報を提供する。
図22におけるシリアルポート2230は、通常、携帯情報端末(PDA)タイプの移動局でインプリメントされる。この移動局は、ユーザのデスクトップコンピュータ(図示せず)と同期することが、望ましいことであり得るが、随意の機器コンポーネントである。このようなポート2230によって、ユーザは、外部デバイスまたはソフトウェアプリケーションを介して優先度を設定でき、無線通信ネットワーク以外を介して、移動局2200に情報またはソフトウェアのダウンロードを提供することで、移動局2200の能力を拡張できる。代替のダウンロード経路は、例えば、直接それゆえ確実で信頼性ある接続を介して、機器に暗号化キーをロードし、それによって確実なデバイス通信を提供するために使用され得る。当業者には理解されるように、シリアルポート2230は、移動デバイスをコンピュータに接続して、さらに使用され、モデムとして機能し得る。
短距離通信サブシステムのような他の通信サブシステム2240は、更なる随意のコンポーネントであり、移動局2200と異なるシステムまたはデバイスとの間に通信を提供し得る。このシステムまたはデバイスは、必ずしも同様のデバイスである必要はない。例えば、サブシステム2240は、赤外線デバイス、ならびに、関連回路およびコンポーネント、あるいは、BluetoothTM通信モジュールを含み得て、通信に同様に有効化されたシステムおよびデバイスを提供する。
本明細書に記載された実施形態は、本出願の技術のエレメントに対応するエレメントを有する構造、システムまたは方法の例である。この書面による記載によって、当業者は、本出願の技術のエレメントと同様に対応する代替のエレメントを有する実施形態を実施し、使用することが可能となり得る。本出願の技術で意図される範囲は、したがって、本明細書に記載されたような本出願の技術と異ならない他の構造、システムまたは方法を含み、本明細書に記載されたような本出願の技術と実質的でない差を有する他の構造、システムまたは方法をさらに含む。
本特許出願は、図面を参照して、より良く理解される。
動的コンテンツ配信システムに対する基本的なアーキテクチャのブロック図である。 図1の動的コンテンツ配信システムの代替的なアーキテクチャのブロック図である。 コンピュータおよびメタデータフローを示す図1のブロック図である。 本システムおよび方法と関連して使用され得るプッシュプロキシを示すブロック図である。 本システムおよび方法と関連して使用され得るプッシュクライアントを示すブロック図である。 コンテンツおよびメタデータの多層エンベロープモデルを示すブロック図である。 図6のブロック図であり、各エンベロープに対する動的メタデータの処理ステップを示す。 図6のブロック図であり、静的および動的メタデータを用いる処理を追加的に示す。 アプリケーションが単一の共有プッシュクライアントに登録するプロセスを示すブロック図である。 アプリケーションがプッシュクライアントのプールをマネージするプッシュコンテナに登録するプロセスを示すブロック図である。 アプリケーションがコンテンツプロセッサおよびソケットリスナに登録するのを示すブロック図である。 コンテンツプロバイダが単一の共有プッシュプロキシに登録するのを示すブロック図である。 コンテンツプロバイダがプッシュプロキシのプールをマネージするプッシュコンテナに登録するのを示すブロック図である。 コンテンツプロバイダとクライアントアプリケーションとの間での登録メッセージを示すフロー図である。 プッシュクライアントとプッシュプロキシとの間での登録の間における相互動作を示すブロック図である。 プッシュプロキシとコンテンツプロバイダとの間での登録の間における相互動作を示すブロック図である。 コンテンツプロバイダと処理エレメントとの間でのコンテンツおよびメタデータのフローを示すフロー図である。 コンテンツに対する例示的な変換アプリケーションを示すブロック図である。 コンテンツシンジケート化モデルのブロック図である。 線形断片化プロセスのブロック図である。 非線形断片化プロセスのブロック図である。 本方法およびシステムと関連して使用され得る例示的な移動デバイスのブロック図である。
符号の説明
100 アーキテクチャ
110 コンテンツプロバイダ
120 サービスプロバイダ
122 プッシュプロキシ
130 無線ネットワーク
140 プッシュクライアント
150 クライアントアプリケーション

Claims (20)

  1. ジェネリック動的コンテンツ配信システムにおいて使用するプッシュプロキシであって、
    該プッシュプロキシをコンテンツプロバイダに登録して、該コンテンツプロバイダに対するチャネルメタデータをさらに受信するのに適合した、コンテンツプロバイダ登録サービスプロバイダインターフェースと、
    該コンテンツプロバイダから受信した該チャネルメタデータを格納するのに適合したチャネルメタデータ貯蔵庫と、
    該コンテンツプロバイダから受信したコンテンツ・メタデータエンベロープから、該プッシュプロキシに対するメタデータを抽出するのに適合し、該メタデータを該プッシュプロキシ上でキャッシュ化するのにさらに適合したコンテンツメタデータ抽出器・キャッシュモジュールと、
    コンテンツ・メタデータエンベロープをセグメントに分解するのに適合したコンテンツ断片化モジュールと、
    該コンテンツ断片化モジュールからのコンテンツエンベロープまたは1つ以上のセグメントを格納するのに適合した据え置き検索メッセージストアモジュールと、
    該据え置き検索メッセージストア内に格納されたコンテンツを満了すること、あるいは該据え置き検索メッセージストア内に格納されたコンテンツを置換することに適合した、コンテンツ満了・置換モジュールと、
    プッシュクライアントの選択を提供し、サービスを広告するのに適したコンテンツ依存性モジュールと、
    据え置き検索メッセージストア内に格納されたコンテンツエンベロープのプッシュをスケジューリングするのに適合した、プッシュスケジューラと、
    アプリケーションと該コンテンツプロバイダとの間の加入を維持し、該加入に対するルールのリストを維持するのに適合した、加入・ルールモジュールと
    を備える、プッシュプロキシ。
  2. コンテンツ・メタデータエンベロープをプッシュクライアントにプッシュするプッシュエージェントをさらに備える、請求項1に記載のプッシュプロキシ。
  3. フロー制御メッセージを前記プッシュクライアントから受信し、コンテンツ・メタデータエンベロープのプッシュを開始または中止するのに適合したフロー管理制御モジュールをさらに備える、請求項1または請求項2に記載のプッシュプロキシ。
  4. コンテンツ・メタデータエンベロープを格納し、管理するメッセージブローカ・配信待ち行列をさらに備える、請求項1〜3のいずれか1項に記載のプッシュプロキシ。
  5. 前記プッシュプロキシは、1つのコンテンツプロバイダのみを登録するのに適合した、請求項1〜4のいずれか1項に記載のプッシュプロキシ。
  6. 前記プッシュプロキシは、複数のコンテンツプロバイダを登録するのに適合した、請求項1〜4のいずれか1項に記載のプッシュプロキシ。
  7. コンテンツを格納するコンテンツストレージモジュールをさらに備える、請求項1〜6のいずれか1項に記載のプッシュプロキシ。
  8. 前記プッシュプロキシを統治するサービス統治モジュールをさらに備える、請求項1〜7のいずれか1項に記載のプッシュプロキシ。
  9. 動的コンテンツ配信アーキテクチャにおいて使用するプッシュクライアントであって、
    該プッシュクライアントへのアプリケーションを登録するのに適合し、該アプリケーションに対するアプリケーションマニフェストを受信するのにさらに適合した、アプリケーション登録アプリケーションプロバイダインターフェースであって、該アプリケーションマニフェストは、チャネルメタデータを含む、アプリケーション登録アプリケーションプロバイダインターフェースと、
    該アプリケーションから受信したチャネルメタデータを格納するのに適合したチャネルメタデータ貯蔵庫と、
    コンテンツ・メタデータエンベロープをプッシュプロキシから受信するのに適した通信手段と、
    該コンテンツ・メタデータエンベロープから、該プッシュクライアントに対するメタデータを抽出するのに適合し、該メタデータを該プッシュクライアント上でキャッシュ化するのにさらに適合しているコンテンツメタデータ抽出器・キャッシュモジュールと、
    該プッシュクライアントによってまだ受信されていない該プッシュプロキシからのコンテンツの検索をスケジューリングするのに適合した、据え置き検索マネージャと、
    以前にセグメントに分解されたコンテンツを再構成するのに適合したコンテンツ依存性モジュールと、
    該プッシュクライアント内に格納されたコンテンツを満了すること、あるいは該プッシュクライアント内に格納されたコンテンツを置換することに適合した、コンテンツ満了・置換モジュールと、
    該アプリケーションと協働し、新たなコンテンツが該アプリケーションを待っている旨を該アプリケーションに通知するのに適合した更新通知ブロックと、
    該アプリケーションとコンテンツプロバイダとの間の加入を管理するのに適合した加入管理ブロックと、
    該プッシュクライアントによって要求されたとき、コンテンツをプルするのに適合し、該据え置き検索マネージャによって駆動されるプルブローカと
    を備え、
    該プッシュクライアントは、ジェネリックアプリケーションを登録し、ジェネリックコンテンツタイプを該コンテンツプロバイダから受信するのに適合した、プッシュクライアント。
  10. コンテンツ・メタデータエンベロープを前記プッシュプロキシから受信する、プッシュエージェントをさらに備える、請求項9に記載のプッシュクライアント。
  11. フロー制御メッセージを前記プッシュプロキシに送信し、コンテンツ・メタデータエンベロープのプッシュを開始または中止するのに適合したフロー制御管理モジュールをさらに備える、請求項9または請求項10に記載のプッシュクライアント。
  12. コンテンツ・メタデータエンベロープを格納し、管理するメッセージブローカ・配信待ち行列をさらに備える、請求項9〜11のいずれか1項に記載のプッシュクライアント。
  13. 前記プッシュクライアントは、1つのアプリケーションのみに登録するのに適合した、請求項9〜12のいずれか1項に記載のプッシュクライアント。
  14. 前記プッシュクライアントは、複数のアプリケーションに登録するのに適合した、請求項9〜12のいずれか1項に記載のプッシュクライアント。
  15. コンテンツを格納するコンテンツストレージモジュールをさらに備える、請求項9〜14のいずれか1項に記載のプッシュクライアント。
  16. 前記プッシュクライアントを統治するサービス統治モジュールをさらに備える、請求項9〜15のいずれか1項に記載のプッシュクライアント。
  17. 前記プッシュクライアントは、該プッシュクライアントと接続されていないアプリケーションに対するバックグラウンド更新を実行するのに適合したバックグラウンド更新処理モジュールをさらに備える、請求項9〜16のいずれか1項に記載のプッシュクライアント。
  18. 前記更新通知モジュールは、所定のロケーション内に前記アプリケーションに対するコンテンツを格納するのに適合した、請求項9〜17のいずれか1項に記載のプッシュクライアント。
  19. 前記更新通知は、データが前記所定のロケーション内に格納されたというメッセージを、前記クライアントアプリケーションに送信する、請求項19に記載のプッシュクライアント。
  20. 前記更新通知は、前記コンテンツ・メタデータエンベロープを前記アプリケーションに送信する、請求項9〜17のいずれか1項に記載のプッシュクライアント。
JP2007112402A 2006-05-02 2007-04-20 動的移動コンテンツの配信用プッシュフレームワーク Active JP4635025B2 (ja)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP06113378A EP1853044B1 (en) 2006-05-02 2006-05-02 Push framework for delivery of dynamic mobile content

Publications (3)

Publication Number Publication Date
JP2007299392A true JP2007299392A (ja) 2007-11-15
JP2007299392A5 JP2007299392A5 (ja) 2009-08-06
JP4635025B2 JP4635025B2 (ja) 2011-02-16

Family

ID=36869856

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2007112402A Active JP4635025B2 (ja) 2006-05-02 2007-04-20 動的移動コンテンツの配信用プッシュフレームワーク

Country Status (11)

Country Link
EP (1) EP1853044B1 (ja)
JP (1) JP4635025B2 (ja)
KR (2) KR100879591B1 (ja)
CN (1) CN101110840B (ja)
AT (1) ATE421220T1 (ja)
AU (1) AU2007201897B2 (ja)
BR (2) BRPI0705053A2 (ja)
CA (1) CA2581947C (ja)
DE (1) DE602006004847D1 (ja)
HK (1) HK1110455A1 (ja)
MX (1) MX2007005144A (ja)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013514563A (ja) * 2009-10-16 2013-04-25 リアル イノべーションズ インターナショナル エルエルシー 実時間データを提供するためのシステムおよび方法
US10462206B2 (en) 2009-10-16 2019-10-29 Real Innovations International Llc Bidirectional networked real-time data exchange using a spreadsheet application
US10498796B2 (en) 2009-10-16 2019-12-03 Real Innovations International Llc System and method for providing real-time data
US10558744B2 (en) 2016-11-20 2020-02-11 Real Innovations International Llc Bidirectional networked real-time data exchange using a spreadsheet application

Families Citing this family (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101335765B (zh) * 2008-07-25 2010-12-29 华中科技大学 基于移动缓存的存储服务中间件
KR101297519B1 (ko) 2008-08-08 2013-08-16 삼성전자주식회사 Dcd 서비스에서 사용자 콘텐트 제출 방법 및 시스템
CN101651866A (zh) * 2008-08-14 2010-02-17 国家图书馆 以快讯为主题的移动终端数字内容服务系统
US20100250323A1 (en) * 2009-03-31 2010-09-30 Sony Corporation And Sony Electronics Inc. System and method for dynamically updating a transport structure in an electronic network
US8621520B2 (en) * 2009-05-19 2013-12-31 Qualcomm Incorporated Delivery of selective content to client applications by mobile broadcast device with content filtering capability
CN102014309A (zh) * 2009-09-08 2011-04-13 中兴通讯股份有限公司 一种传输电子业务指南的方法及系统
JP5595503B2 (ja) * 2009-09-09 2014-09-24 テレフオンアクチーボラゲット エル エム エリクソン(パブル) 移動ネットワークにおけるコンテンツ送信の適合化
CN103581312B (zh) * 2010-11-09 2017-01-18 中兴通讯股份有限公司 基于aog的移动互联网业务的实现方法、网关、代理及系统
CN102469124B (zh) * 2010-11-09 2015-08-12 中兴通讯股份有限公司 基于aog的移动互联网业务的实现方法、网关、代理及系统
KR20120058782A (ko) 2010-11-30 2012-06-08 삼성전자주식회사 컨텐츠 중심 네트워킹 환경에서의 단말, 중간 노드 및 이들의 통신 방법
JP5760716B2 (ja) * 2011-03-30 2015-08-12 富士通株式会社 アプリ提供システム、アプリ提供方法、情報処理装置及び情報処理プログラム
KR101287556B1 (ko) * 2011-09-29 2013-07-23 주식회사 엘지씨엔에스 이동 단말기의 푸시 클라이언트 및 이를 이용한 프로바이더 변경방법
GB2504673A (en) * 2012-08-03 2014-02-12 Ibm Publish and subscribe messaging system wherein transmission from broker to subscribers is phased over time
US10122812B2 (en) 2013-06-28 2018-11-06 Nec Corporation Push-type information transmission device, push-type information transmission method, and program
CN105847447B (zh) * 2016-06-01 2022-06-07 腾讯科技(深圳)有限公司 消息推送方法和装置
CN109428923A (zh) * 2017-08-29 2019-03-05 努比亚技术有限公司 消息推送方法、服务器、终端和计算机可读存储介质
CN109151056B (zh) * 2018-09-26 2021-11-19 携程计算机技术(上海)有限公司 基于Canal的消息推送方法和系统
KR102183828B1 (ko) * 2018-11-05 2020-11-27 옴니비스타 주식회사 광고 앱을 이용한 광고 시스템 및 이를 이용한 광고 방법
CN112702259B (zh) * 2020-12-23 2023-05-23 北京焦点新干线信息技术有限公司 延迟消息推送方法、装置及消息中间件
CN114221925B (zh) * 2021-09-30 2024-05-03 北京奇艺世纪科技有限公司 消息推送方法、装置、电子设备及存储介质
CN115150380A (zh) * 2022-06-30 2022-10-04 广发证券股份有限公司 一种适用于多路行情源的行情订阅及发布方法及装置

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000232446A (ja) * 1999-01-13 2000-08-22 Internatl Business Mach Corp <Ibm> データを転送する方法および装置

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1119135A3 (en) * 2000-01-13 2001-09-12 Agilent Technologies Inc. a Delaware Corporation Apparatus and method for a push service
CA2361861A1 (en) * 2001-11-13 2003-05-13 Ibm Canada Limited-Ibm Canada Limitee Wireless messaging services using publish/subscribe systems
US7254614B2 (en) 2001-11-20 2007-08-07 Nokia Corporation Web services push gateway
US20030171990A1 (en) * 2001-12-19 2003-09-11 Sabre Inc. Methods, systems, and articles of manufacture for managing the delivery of content
US7925717B2 (en) 2002-12-20 2011-04-12 Avaya Inc. Secure interaction between a mobile client device and an enterprise application in a communication system
US8856346B2 (en) * 2004-01-15 2014-10-07 Unwired Planet, Llc Stateful push notifications
CN100514941C (zh) * 2004-06-28 2009-07-15 华为技术有限公司 一种阻止垃圾推消息的方法

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000232446A (ja) * 1999-01-13 2000-08-22 Internatl Business Mach Corp <Ibm> データを転送する方法および装置

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013514563A (ja) * 2009-10-16 2013-04-25 リアル イノべーションズ インターナショナル エルエルシー 実時間データを提供するためのシステムおよび方法
US9667689B2 (en) 2009-10-16 2017-05-30 Real Innovations International Llc System and method for providing real-time data
JP2017107572A (ja) * 2009-10-16 2017-06-15 リアル イノべーションズ インターナショナル エルエルシー 実時間データを提供するためのシステムおよび方法
US10462206B2 (en) 2009-10-16 2019-10-29 Real Innovations International Llc Bidirectional networked real-time data exchange using a spreadsheet application
US10498796B2 (en) 2009-10-16 2019-12-03 Real Innovations International Llc System and method for providing real-time data
US10558744B2 (en) 2016-11-20 2020-02-11 Real Innovations International Llc Bidirectional networked real-time data exchange using a spreadsheet application

Also Published As

Publication number Publication date
CA2581947A1 (en) 2007-11-02
KR20070107592A (ko) 2007-11-07
KR20080096493A (ko) 2008-10-30
HK1110455A1 (ja) 2008-07-11
CN101110840B (zh) 2012-11-14
AU2007201897B2 (en) 2009-03-05
BRPI0702004A (pt) 2007-12-18
KR100879591B1 (ko) 2009-01-21
CN101110840A (zh) 2008-01-23
KR100897841B1 (ko) 2009-05-15
MX2007005144A (es) 2008-12-02
CA2581947C (en) 2012-10-30
EP1853044B1 (en) 2009-01-14
AU2007201897A1 (en) 2007-11-22
DE602006004847D1 (de) 2009-03-05
BRPI0705053A2 (pt) 2008-12-09
JP4635025B2 (ja) 2011-02-16
ATE421220T1 (de) 2009-01-15
EP1853044A1 (en) 2007-11-07

Similar Documents

Publication Publication Date Title
JP4635025B2 (ja) 動的移動コンテンツの配信用プッシュフレームワーク
JP4603565B2 (ja) 動的にシンジゲートされたコンテンツ配信のシステムおよび方法
JP5061249B2 (ja) プッシュコンテンツ配信システムを用いるクライアントアプリケーションおよびコンテンツプロバイダの媒介プラグイン登録
JP5183707B2 (ja) プッシュコンテンツ処理プロトコル内をパスするメタデータ最適化方法およびシステム
JP5295998B2 (ja) 移動コンテンツを断片化するシステムおよび方法
JP4731518B2 (ja) 移動コンテンツを断片化するシステムおよび方法
JP5183710B2 (ja) プッシュコンテンツメタデータに対する多層化エンベロープされた方法およびシステム

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20090623

RD02 Notification of acceptance of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7422

Effective date: 20090623

RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20090623

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20090724

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20091217

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20100316

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20100319

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20100416

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20101109

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20101119

R150 Certificate of patent or registration of utility model

Ref document number: 4635025

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20131126

Year of fee payment: 3

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

S531 Written request for registration of change of domicile

Free format text: JAPANESE INTERMEDIATE CODE: R313531

S533 Written request for registration of change of name

Free format text: JAPANESE INTERMEDIATE CODE: R313533

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250