(57)【要約】【課題】ウェブ・コンテンツ配信プラットフォームのような、コンテンツ配信プラットフォームが、インターネット、イントラネット、個人ネットワーク、またはその他の計算機、あるいはそれ以外というようなソースから取得したコンテンツを管理し、編成し、消費に利用可能にする。【解決手段】実施形態の一部では、このプラットフォームは、多くの異なる種類のアプリケーションによって、ウェブ・コンテンツを取得および編成し、このようなコンテンツを消費のために利用可能にすることができる。これらのアプリケーションは、必ずしも特定の配信フォーマットを理解できてもできなくてもよい。アプリケーション・プログラム・インターフェース（ＡＰＩ）がオブジェクト・モデルを露出し、これによってアプリケーションおよびユーザは、フィードの作成、読み取り、更新、削除等というような、多くの異なるタスクを容易に遂行することが可能となる。【選択図】      図２
2008547117.tif 000002
【特許請求の範囲】
【請求項１】
１つ以上のコンピュータ読み取り可能媒体と、
前記１つ以上のコンピュータ読み取り可能媒体上にあるコンピュータ読み取り可能命令であって、実行されると、
１つ以上のフォーマットでＲＳＳデータを受信し処理するように構成されたＲＳＳプラットフォームと、
異なるタイプのアプリケーションが、前記ＲＳＳプラットフォームが受信し処理したＲＳＳデータにアクセスすることを可能にするように構成されたコード手段と、
を実施する、コンピュータ読み取り可能命令と、
を備えた、システム。
【請求項２】
請求項１記載のシステムにおいて、前記ＲＳＳプラットフォームは、複数の異なるフォーマットでＲＳＳデータを受信し処理するように構成された、システム。
【請求項３】
請求項１記載のシステムにおいて、前記ＲＳＳプラットフォームは、複数の異なるフォーマットでＲＳＳデータを受信し処理するように構成されており、前記ＲＳＳプラットフォームは、前記複数の異なるフォーマットを共通フォーマットに変換するように構成された、システム。
【請求項４】
請求項１記載のシステムにおいて、前記異なるタイプのアプリケーションは、ＲＳＳリーダ以外のアプリケーションを含む、システム。
【請求項５】
請求項１記載のシステムにおいて、前記異なるタイプのアプリケーションは、前記プラットフォームが前記ＲＳＳデータを受信するフォーマットを理解しないアプリケーションを含む、システム。
【請求項６】
請求項１記載のシステムにおいて、前記異なるタイプのアプリケーションは、前記プラットフォームが前記ＲＳＳデータを受信するフォーマットを理解しないアプリケーションを含み、前記異なるタイプのアプリケーションは、ウェブ・ブラウザ・アプリケーション、電子メール・アプリケーション、またはメディア・プレーヤ・アプリケーションのうちの１つ以上を含む、システム。
【請求項７】
請求項１記載のシステムにおいて、前記異なるタイプのアプリケーションは、ウェブ・ブラウザ・アプリケーション、電子メール・アプリケーション、またはメディア・プレーヤ・アプリケーションのうちの１つ以上を含む、システム。
【請求項８】
請求項１記載のシステムにおいて、前記コード手段は、フィード加入がフォルダの階層としてモデル化されたオブジェクト・モデルを露出し、前記オブジェクト・モデルは、フィード加入の共有リストへのアクセスを与える、システム。
【請求項９】
請求項１記載のシステムにおいて、前記コード手段は、フィードに加入されていない１つ以上のアプリケーションが、前記ＲＳＳプラットフォームが受信し処理する関連ＲＳＳデータにアクセスすることを可能にするように構成された、システム。
【請求項１０】
１つ以上のコンピュータ読み取り可能媒体と、
前記コンピュータ読み取り可能媒体上に具体化されたＡＰＩ集合であって、処理されフィード・ストアに格納されたＲＳＳデータに、少なくとも１つのアプリケーションがアクセスすることを可能にする１つ以上のメソッドを備えた、ＡＰＩ集合と、
を備えており、前記少なくとも１つのアプリケーションは、前記ＲＳＳデータが最初に具体化されたＲＳＳフォーマットを理解しない、システム。
【請求項１１】
請求項１０記載のシステムにおいて、前記１つ以上のメソッドは、１つ以上のエンクロージャを格納するデータ・ストアへのアクセスを与えるメソッドと、エンクロージャとそれに関連するフィード項目との間の関係を発見するために用いることができるメソッドとを備えた、システム。
【請求項１２】
請求項１０記載のシステムにおいて、前記１つ以上のメソッドは、複数の異なるタイプのアプリケーションのためにアクセスを与えるメソッドを備えた、システム。
【請求項１３】
請求項１０記載のシステムにおいて、前記１つ以上のメソッドは、複数の異なるタイプのアプリケーションのためにアクセスを与えるメソッドを備えており、前記複数の異なるタイプのアプリケーションのうち少なくとも１つは、前記ＲＳＳデータが最初に具体化されたＲＳＳフォーマットを理解しない、システム。
【請求項１４】
請求項１０記載のシステムにおいて、前記１つ以上のメソッドは、複数の異なるタイプのアプリケーションのためにアクセスを与えるメソッドを備えており、前記複数の異なるタイプのアプリケーションのうち少なくとも１つは、前記ＲＳＳデータが最初に具体化されたＲＳＳフォーマットを理解し、ＲＳＳリーダを備えた、システム。
【請求項１５】
請求項１０記載のシステムにおいて、前記１つ以上のメソッドは、複数の異なるタイプのアプリケーションのためにアクセスを与えるメソッドを備えており、前記複数の異なるタイプのアプリケーションのうち少なくとも１つは、前記ＲＳＳデータが最初に具体化されたＲＳＳフォーマットを理解し、ウェブ・ブラウザ・アプリケーションを備えた、システム。
【請求項１６】
請求項１０記載のシステムにおいて、前記１つ以上のメソッドは、アプリケーションが加入されていないウェブ・フィードと関連のあるデータに、アプリケーションがアクセスすることを可能にするメソッドを備えた、システム。
【請求項１７】
請求項１０記載のシステムにおいて、前記１つ以上のメソッドは、フィード加入をフォルダの階層としてモデル化するメソッドを備えた、システム。
【請求項１８】
請求項１０記載のシステムにおいて、前記少なくとも１つのアプリケーションは、電子メール・アプリケーションを備えた、システム。
【請求項１９】
請求項１０記載のシステムにおいて、前記少なくとも１つのアプリケーションは、ウェブ・ブラウザ・アプリケーションを備えた、システム。
【請求項２０】
請求項１０記載のシステムにおいて、前記少なくとも１つのアプリケーションは、メディア・プレーヤ・アプリケーションを備えた、システム。
【発明の詳細な説明】
【背景技術】
【０００１】
ＲＳＳは、本当に簡単な配信(Really Simple Syndication)を表し、ウェブ・コンテンツ配信フォーマットの一種である。ＲＳＳウェブ・フィード(web feed)は、ウェブ上では増々普及しつつあり、ＲＳＳをサポートした多数のソフトウェアが開発されている。これら多数のアプリケーションは、機構(feature)が様々であり、いくつかの異なるＲＳＳ対応アプリケーション(RSS-enabled application)を、ユーザがインストールしなければならないこともあり得る。各ＲＳＳアプリケーションは、通例、それ自体の加入(subscription)リストを有する。加入リストが小さいときは、異なるアプリケーションに跨ってこれらの加入を入力し管理することは、ユーザにとって非常に簡単である。しかしながら、加入リストが増大するに連れて、これら異なるＲＳＳ対応アプリケーションの各々と関連付けて加入の管理を行うのは非常に困難になる。つまり、加入リストが非同期に非常になりやすくなる。
【０００２】
加えて、ウェブ・フィードは数種類の異なるファイル・フォーマットで送られ、その中で普及しているのはＲＳＳ０．９１、０．９２、１．０、２．０、およびＡｔｏｍである。各ＲＳＳ対応アプリケーションは、これらのフォーマットの殆ど、そして恐らく今後はそれら以外もサポートしなければならない。何らかのアプリケーションのためにＲＳＳ環境(RSS context)において用いるためにパーザを実装することは、他の場合よりも困難である。アプリケーション開発者の全てが、各フォーマットの複雑さに関して経験および知識を有するＲＳＳの専門家ではないことから、全てのアプリケーション開発者がパーザを正しく実装することは可能性が低い。したがって、潤沢な数のファイル・フォーマットがあるとすると、一部のアプリケーション開発者はこの空間においてアプリケーションを開発しないことを選択し、あるいはそうする場合、異なるファイル・フォーマットを跨って利用可能な機構の全てを最大限利用するようにアプリケーションが構成されない可能性が高い。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
ＲＳＳおよびウェブ・フィードの別の形態はコンテンツの公開(publishing)に関する。例えば、ブログ（ウェブログ）を有するユーザ数は増加している。無料のブログ・サービスを提供する数多くのサービスが公に利用可能となっている。しかしながら、コンテンツをブログ・サービスに公開することは、むしろ厄介となり得る。何故なら、これには、ブラウザを開き、ブログ・サービスにナビゲートし、署名し、更にエントリをタイプ入力してそれを提出しなければならない場合もあるからである。多くのアプリケーション開発者は、ウェブ・サイトに行かなければならないことによってユーザ・フローを断ち切ることなく、彼ら自身のアプリケーションから公開できれば、それを優先するであろう。加えて、クライアント・デバイスと個々のサービスとの間で通信を行うために用いることができる多くの異なるタイプのプロトコルがある。これを想定すると、アプリケーション開発者が全てのプロトコルを実装することは、可能性が低い。つまり、ユーザの体験はそれが可能な全てではない。
【課題を解決するための手段】
【０００４】
ウェブ・コンテンツ配信プラットフォームのような、コンテンツ配信プラットフォームが、インターネット、イントラネット、個人ネットワーク、またはその他の計算機、あるいはそれ以外というようなソースから取得したコンテンツを管理し、編成し、消費に利用可能にする。実施形態の一部では、このプラットフォームは、多くの異なる種類のアプリケーションによって、ウェブ・コンテンツを取得および編成し、このようなコンテンツを消費のために利用可能にすることができる。これらのアプリケーションは、必ずしも特定の配信フォーマットを理解できてもできなくてもよい。アプリケーション・プログラム・インターフェース（ＡＰＩ）がオブジェクト・モデルを露出し、これによってアプリケーションおよびユーザは、フィードの作成、読み取り、更新、削除等というような、多くの異なるタスクを容易に遂行することが可能となる。
【０００５】
加えて、このプラットフォームは、個々のフィード・フォーマットを抽象化し、共通のフォーマットを設けて、プラットフォームに入ってくるフィード・データの使用可能性を促進することができる。更に、このプラットフォームは、エンクロージャを処理し管理する。エンクロージャは、配信了解(syndication-aware)アプリケーションおよび配信了解でないアプリケーション双方に、消費のためにエンクロージャを利用可能とするように、ウェブ・フィードを通じて受信することができる。
【発明を実施するための最良の形態】
【０００６】
全体像
ウェブ・コンテンツ配信プラットフォームのような、コンテンツ配信プラットフォームが、インターネット、イントラネット、個人ネットワーク、またはその他の計算機、あるいはそれ以外というようなソースから取得したコンテンツを管理し、編成し、消費に利用可能にする。この文書の文脈では、ＲＳＳウェブ・フィードの関連で用いられるように設計したＲＳＳプラットフォームに関して、プラットフォームを説明する。尚、ＲＳＳ関連は一例を構成するに過ぎず、特許請求する主題の摘要をＲＳＳ関連のみの限定することを意図しているのではないことは認められよう。以下の説明は、読み手側が程度のＲＳＳに精通していることを仮定している。ＲＳＳの背景については、読み手に関心があると思われる情報を提供する明細書が多数公に入手可能である。
【０００７】
本文書では、記載するＲＳＳの実施形態の文脈においてある種の用語を用いる。項目(item)とはフィードの基本単位である。通例、項目は、ブログの入口、またはニュース記事／要約を表し、ウェブサイト上にある実際の記事へのリンクを有する。エンクロージャとは、電子メールの添付ファイルと同様であるが、実際のコンテンツへのリンクがあることを除く。フィードとは、リソースにおける項目のリストであり、通常は最も新しく追加された項目である。システム・フィード・リストとは、ユーザを加入させるフィードのリストである。加入とは、新しいフィード項目の通知を受信するために署名する行為を言う。
【０００８】
本文書に記載する種々の実施形態では、プラットフォームは、ウェブ・コンテンツを取得および編成し、このようなコンテンツを多くの異なるタイプのアプリケーションによる消費に利用可能にすることができる。これらのアプリケーションは、特定の配信フォーマットを必ずしも理解できてもできなくてもよい。つまり、実現例では、ＲＳＳフォーマットを理解しないアプリケーションでも、本プラットフォームを通じて、当該プラットフォームがＲＳＳフィードを通じて取得した、エンクロージャのようなコンテンツを取得し消費することができる。
【０００９】
本プラットフォームは、アプリケーション・プログラム・インターフェース（ＡＰＩ）を備えており、アプリケーション・プログラム・インターフェースがオブジェクト・モデルを露出し、これによってアプリケーションおよびユーザは、フィードの作成、読み取り、更新、削除等というような、多くの異なるタスクを容易に遂行することが可能となる。
【００１０】
少なくとも１つの実施形態では、本プラットフォームは、複数の異なるフィード・パーザを備えており、その各々が、ウェブ・フィードを受信することができる個々のフォーマットを解析することができる。解析されたフォーマットは、次に、共通フォーマットに変換され、これをアプリケーションおよびユーザが利用することができる。共通フォーマットは、いずれの１つの特定のフォーマットによって具体化された特定の観念(notion)であっても、より普遍的にそして理解し易いフォーマットに抽象化するために利用される。
【００１１】
更に、本フォーマットは、プラットフォームは、エンクロージャを処理し管理する。エンクロージャは、配信了解(syndication-aware)アプリケーションおよび配信了解でないアプリケーション双方に、消費のためにエンクロージャを利用可能とするように、ウェブ・フィードを通じて受信することができる。少なくとも一部の実施形態では、ＡＰＩは、エンクロージャおよびそれに関連があるフィード項目との間の関係の発見に対処する。
【００１２】
以下に続く論述では、最初に、「ウェブ・コンテンツ配信プラットフォーム」という見出しの下で、プラットフォームの一例およびそのコンポーネントについて説明する。この論述に続いて、実現例（「実現例」という見出しの下で）を提供し、アプリケーションおよびユーザが有意かつロバストな方法でプラットフォームと双方向処理を行うことを可能にするオブジェクト・モデルを露出するＡＰＩ集合について説明する。
ウェブ・コンテンツ配信プラットフォーム
図１は、一実施形態によるシステム例を示し、全体的に１００を付している。システム１００の形態は、適したハードウェア、ソフトウェア、ファームウェア、またはその組み合わせであればいずれとでも実施することができる。少なくとも１つの実施形態では、本システムの形態は、ある種のコンピュータ読み取り可能媒体上に常駐するコンピュータ読み取り可能命令として実施する。
【００１３】
この例では、システム１００は、コンテンツ配信プラットフォーム１０２とアプリケーション１０４の集合体とを備えている。個々のアプリケーションは、異なる方法で本プラットフォームを利用するように構成することができる。これについては、以下で明らかとなろう。少なくとも一部の実施形態では、コンテンツ配信プラットフォームは、ウェブ・コンテンツ配信プラットフォームを備えている。以下に続く論述では、プラットフォーム１０２をＲＳＳプラットフォームに関して説明する。尚、これは、一例に過ぎないことを意図しており、特許請求する主題の摘要をＲＳＳ環境のみに限定することは意図していないことは認められよう。逆に、説明する実施形態の原理は、特許請求する主題の主旨および範囲から逸脱することなく、他の配信環境でも利用することができる。
【００１４】
この例では、プラットフォーム１０２は、オブジェクト・モデル１０６を備えており、オブジェクト・モデル１０６は、アプリケーション１０４がプラットフォームと双方向処理を行うことを可能にするために、ＡＰＩ集合によって露出されている。配信エンジン１０８が設けられており、とりわけ、ウェブ・コンテンツを取得し、少なくとも一部の実施形態では、このウェブ・コンテンツをいわゆる共通フォーマットに変換するように構成されている。これについては、以下で更に詳しく説明する。
【００１５】
公開エンジン１１０は、ユーザが、ブログのようなコンテンツを、公開することを許容する。その際、ユーザのアプリケーションまたは計算機とサーバまたはコンテンツを受信する宛先ソフトウェアとの間で通信を行うために利用される通信プロトコルを、ＡＰＩによって抽象化する。
【００１６】
加えて、少なくとも一部の実施形態では、プラットフォーム１０２は、フィード・リスト１１４およびフィード・データ１１６双方を格納するフィード・ストア１１２を含む。更に、プラットフォーム１０２は、少なくとも一部の実施形態では、エンクロージャ１２０を格納し維持するためにファイル・システム１１８を利用する。ファイル・システムを用いることにより、利点が得られ、その中には、必ずしも配信フォーマットを理解することのないアプリケーションであっても、対象となり得るエンクロージャを消費することを可能にすることが含まれる。更に、プラットフォーム１０２は、ポスト・データ１２４を保持するポスト・キュー１２２も含み、特定のウェブアクセス可能な場所に貼り付けられる。
【００１７】
先に記したように、プラットフォーム１０２は、アプリケーションがウェブ・コンテンツにアクセスし、これを消費し公開することを可能にすることができる。したがって、アプリケーション１０４の集合体は、多くの異なるタイプのアプリケーションを含むことができる。少なくとも一部の実施形態では、アプリケーションのタイプは、配信了解のものと、配信了解でないものとを含むことができる。「配信了解」が意味するのは、アプリケーションが、少なくとも多少は、利用される配信フォーマットを熟知しているということである。つまり、ＲＳＳの関連では、配信了解アプリケーションとは、データを処理する、またはそれ以外でＲＳＳフォーマットで表されているコンテンツと双方向処理を行うように構成することができるアプリケーションである。これは、ＲＳＳフォーマット・データを解析しこれと有意に双方向処理することができることを含むことができる。同様に、配信了解でないアプリケーションは、通例、配信フォーマットを理解するように構成されていない。とは言え、本プラットフォームを通じることにより、配信了解でないアプリケーションであっても、配信フォーマットでプラットフォームに到達するコンテンツにアクセスしこれを消費することができる。これは、以下で明らかとなろう。
【００１８】
本プラットフォームと双方向処理を行うことができる異なるタイプのアプリケーションを更に具体的に見ていくと、集合体１０４は、ウェブ・ブラウザ・アプリケーション１２２、ＲＳＳリーダ・アプリケーション１２４、ディジタル画像ライブラリ・アプリケーション１２６、メディア・プレーヤ・アプリケーション１２８、およびブログ・サービス１３０を含む。この例では、ＲＳＳリーダ・アプリケーション１２４は、配信了解アプリケーションであり、一方メディア・プレーヤ１２８は必ずしも配信了解アプリケーションでなくてもよい。更に、ウェブ・ブラウザ・アプリケーション１２２も配信了解アプリケーションであってもなくてもよい。勿論、これらのアプリケーションは、本プラットフォームと双方向処理が可能な異なるタイプのアプリケーションの例を構成するに過ぎない。したがって、例示したアプリケーションと同一または異なる、その他のタイプのアプリケーションも、特許請求する主題の主旨および範囲から逸脱することなく、利用することができる。限定ではない一例として、これらその他のタイプのアプリケーションは、イベントのフィード用カレンダ・アプリケーション、ソーシャル・ネットワーク、連絡先フィード用電子メール・アプリケーション、ピクチャ・フィード用スクリーン・セイバー・アプリケーション、文書フィード用ＣＲＭ等を含むことができる。
【００１９】
以下に続く論述では、プラットフォーム１０２の個々のコンポーネントの形態について、更に詳しく、各々それ自体の見出しの下で説明する。
オブジェクト・モデル
図２は、一実施形態によるオブジェクト・モデル１０６の個々のオブジェクトを示す。説明しようとしているオブジェクト・モデルは、利用することができるオブジェクト・モデルの一例を構成するに過ぎず、特許請求する主題の摘要を、以下に説明するオブジェクト・モデルのみに限定することは意図していない。先に記したように、オブジェクト・モデルはＡＰＩによって露出される。その一例について以下に説明する。
【００２０】
この特定的なオブジェクト・モデルでは、フィードと呼ばれる最上位オブジェクト２００を設ける。フィード・オブジェクト２００は、タイプ・フォルダの加入(subscription)と呼ばれるプロパティを有する。加入またはフォルダ・オブジェクト２０２は、フォルダの階層としてモデル化されている。つまり、この特定的な例では、加入またはフォルダ・オブジェクトが有するプロパティは、タイプ・フォルダのサブフォルダ２０４と、タイプ・フィードのフィード２０６とを含む。フィード・オブジェクト２０６の直下には、タイプ項目の項目オブジェクト２０８があり、項目オブジェクト２０６の直下には、タイプ・オブジェクトのエンクロージャ・オブジェクト２１０がある。
【００２１】
オブジェクト・モデルの個々のオブジェクトは、プロパティ、メソッド、そして場合によっては、イベントを有し、これらは、本プラットフォームによって受信されたウェブ・コンテンツを管理するために利用することができる。前述のオブジェクト・モデルによって、階層構造を利用して、フィードリストの管理等のようなことを行うことが可能となる。例えば、フォルダ構造を用いると、プラットフォームはフィード集合に対して実行することができる。当業者には認められようが、これはアプリケーション開発者によって、それを容易にする。例えば、フィード集合に対して実行することにより、ニュース・フォルダ内にある「ニュース」(news)フィード全てをリフレッシュすることが可能になる。
【００２２】
一例として、以下のことを検討する。ユーザが、実際には加入していないフィードと関連のあるデータと双方向処理を行う、または消費したいと仮定する。加入していないフィード、即ち、ルート・レベルの加入フォルダの内部で表されていないフィードについて、同期エンジン１０８（図１）はフィードを選出し、しかるべき間隔で、このフィードと関連のあるデータを取り出し始める。しかしながら、本プラットフォームを使用するアプリケーションが特定のフィードに加入されることを望まない場合がある。むしろ、アプリケーションは、単に、フィードからのデータにアクセスするためにプラットフォームの機能性を使用したいだけである。この場合、この特定的な実施形態では、加入オブジェクト２０２は、フィードに加入することなく、フィードをダウンロードさせるメソッドをサポートする。この特定的な例では、アプリケーションはメソッドをコールし、フィードと関連のあるＵＲＬをそれに供給する。次いで、プラットフォームはＵＲＬを利用して、対象のデータをアプリケーションに引き渡す。このように、アプリケーションは、フィードに加入することさえ必要とせずに、その場で、フィードと関連のあるデータを取得することができる。
【００２３】
更にオブジェクト・モデルについて検討するために、項目およびエンクロージャ・オブジェクト２０８、２１０についてそれぞれ検討する。ここでは、これらのオブジェクトは、ＲＳＳ自体がどのような構造となっているかを非常に良く反映する。つまり、各ＲＳＳフィードは、個々の項目を有し、その内側では、エンクロージャが任意に現れることができる。このように、オブジェクト・モデルの構造は、配信フォーマットの構造を反映するように構成されている。
【００２４】
オブジェクト・モデルの観点からは、基本的に、項目には２つの異なるタイプのメソッドおよびプロパティがある。第１のタイプのメソッド／プロパティは読み出しのみのデータに関し、第２のタイプのメソッド／プロパティは読み出しおよび書き込み双方が可能なデータに関する。
【００２５】
第１のタイプのメソッド・プロパティの一例として、以下のことを検討する。各フィードには、ＸＬＭ構造で表されているデータを関連付けることができる。このデータは、タイトル、著作者、言語等というようなことを含む。このようなデータは、オブジェクト・モデルによって読み出し専用として扱われる。例えば、フィードによって受信され個々の項目と関連付けられているデータは、通例、読み出し専用として扱われる。これによって、アプリケーションがこのデータを操作するのを防止する。ＸＭＬ構造を用いてフィードを表すことによっても、以下のような利点が得られる。同期エンジンが、追加された新しいＸＭＬエレメントを理解しないと仮定する。しかしながら、同期エンジンは、それでも、このエレメントおよびそれに関連のあるデータを、フィード項目データの一部として格納することができる。このエレメントを理解しないアプリケーションにも、このエレメントおよびそれに関連するデータは、発見および消費のためにアプリケーションに利用可能である。
【００２６】
一方、個々のフィードの名称のように、リード／ライト・データとして扱われるデータがある。即ち、ユーザは個々のフィードを彼ら自身のユーザ・インターフェースに合わせて本人専用にしたい場合がある。この場合、オブジェクト・モデルはリード／来とであるプロパティを有する。例えば、ユーザが"New York Times"からのフィードの名称を「ＮＹＴ」に変更したい場合がある。この状況では、名称プロパティは、読み取り可能および書き込み可能とすることができる。
フィード同期エンジン
図示し説明した実施形態では、フィード同期エンジン１０８（図１）は、ソースからＲＳＳフィードをダウンロードすることを責務とする。ソースは、ウェブ・サイト、フィード公開サイト等のように、適したフィード・ソースであればいずれでも備えることができる。少なくとも一部の実施形態では、適した有効なＵＲＬまたはリソース識別子であればいずれでもフィードのソースを構成することができる。同期エンジンは、フィードを受信し、種々のフィード・フォーマットを処理し、スケジューリングの世話をし、コンテンツおよびエンクロージャのダウンロードを処理し、保管活動を編成する。
【００２７】
図３は、一実施形態によるフィード同期エンジン１０８の一例を更に多少詳しく示す。この実施形態では、同期エンジンは、フィード・フォーマット・モジュール３００、フィード・スケジュール・モジュール３０２、フィード・コンテンツ・ダウンロード・モジュール３０４、エンクロージャ・ダウンロード・モジュール３０６、および保管モジュール３０８を含む。尚、これらのモジュールは、これらの個々の機能性を明確に記述することを目的に、論理的に別個のモジュールとして示すことは認められ、理解されよう。論理的に別個のモジュールは、特許請求する主題を、ここに記載する特定の構造やアーキテクチャのみに限定することを意図するのではない。
フィード・フォーマット・モジュール−−３００
図示し説明した実施形態では、複数の異なるフィード・フォーマットでフィードを受信することができる。限定ではない一例として、これらのフィード・フォーマットは、ＲＳＳ１．０、１．１、．９ｘ、２．０、Ａｔｏｍ．３等を含むことができる。同期エンジンは、フィード・フォーマット・モジュールを通じて、これらのフィードを種々のフォーマットで受信し、フォーマットを解析し、共通フォーマットと呼ぶ、正規化フォーマットにそのフォーマットを変換する。共通フォーマットは、本質的に、全てのサポートするフォーマットの上位集合(superset)である。共通フォーマットを用いることの便益の１つは、フォーマット了解(format-aware)のアプリケーションは、１つのフォーマット、即ち、共通フォーマットのみを知っていればよいことである。加えて、共通フォーマットに変換されたコンテンツを管理することは、プラットフォームは数個ではなく１つのフォーマットだけに関与すればよいので、遥かに容易である。更に、今後追加の配信フォーマットが開発されるに連れて、フィード・フォーマット・モジュールを、そのフォーマットを処理するように改造することができ、同時に、新たなフォーマットを全く分からないアプリケーションであっても、新たなフォーマットでプラットフォームに到達したコンテンツを利用し用いることが可能となる。
【００２８】
共通フォーマットに関して、以下のことを検討する。フォーマットの観点からは、共通フォーマットは、異なるフォーマット間で共通であるＸＭＬ方式によって表される。異なるフォーマットでは、ある種のエレメントは異なる名称、ＸＭＬフォーマットの階層における異なる場所等を有する場合がある。これに応じて、共通フォーマットは、可能な異なるフォーマットの全てから集合的に導出した共通の構造およびシンタックスを呈示することを目的とする。
【００２９】
フィード・スケジュール・モジュール  −−３０２
各フィードは、利用可能な新たなコンテンツがあるか否か確認するために同期エンジン１０８がチェックすべきについて、それ自体のスケジュールを有することができる。これに応じて、同期エンジンは、フィード・スケジュール・モジュール３０２を通じて、このようなスケジュールを管理し、サイトならびにユーザおよびシステムの要件や制限を侵さないようにする。
【００３０】
一例として、以下のことを検討する。フィードを最初にダウンロードするとき（即ち、フィードをいつ更新するかというスケジュール）、更新モジュールをフィードのヘッダに含ませることができる。この場合、フィード・スケジュール・モジュール３０２は、この特定のフィードのために更新スケジュールを維持し、更新スケジュールに応じて新しいコンテンツをチェックする。しかしながら、スケジュール情報が含まれていない場合、フィード・スケジュール・モジュールは、デフォルトのスケジュールを利用して、新しいコンテンツをチェックすることができる。例えば、２４時間毎にフィード・コンテンツを再度ダウンロードするというように、適したデフォルトのスケジュールであればいずれでも用いることができる。少なくとも一部の実施形態では、ユーザは異なるデフォルトのワーク・スケジュールを指定することができる。
【００３１】
加えて、少なくとも一部の実施形態では、フィード・スケジュール・モジュールは、最少スケジュールと呼ばれるものをサポートすることができる。最少スケジュールとは、更新の合間の期間を定める最少更新時間のことを指す。即ち、プラットフォームは最少スケジュールが定めるよりも頻繁にフィードを更新することはない。少なくとも一部の実施形態では、ユーザは最少時間を変更することができる。加えて、ユーザはいずれの、または全てのフィードバックの手作業によるリフレッシュを開始することもできる。
【００３２】
デフォルトおよび最少スケジュールをサポートすることに加えて、少なくとも一部の実施形態では、フィード・スケジュール・モジュールは、公開者指定スケジュール(publisher-specified schedule)もサポートすることができる。この名称が暗示するように、公開者指定スケジュールとは、個々の公開者が指定するスケジュールである。例えば、公開者指定スケジュールは、通例、クライアントが次回フィードを更新するまでの分数を指定することができる。これは、ＲＳＳ０．９ｘ／２．０「ｔｔｌ」エレメントを用いて指定することができる。同期エンジンは、少なくともその分数が過ぎるまでは、フィードの新しいコピーを取り出さない方がよい。公開者指定スケジュールは、時間、日、週等のような異なる粒度で指定することもできる。
【００３３】
尚、フィード文書の各コピーは異なる公開者指定スケジュールを有することができることを記しておく。例えば、１日の間に、公開者は１５分のスケジュールを規定し、次いで夜間には、１時間のスケジュールを規定することもできる。この場合、同期エンジンは、フィードがダウンロードされる毎に、その挙動を更新する。
【００３４】
加えて、少なくとも一部の実施形態では、同期エンジンは、フィード・スケジュール・モジュール３０２を通じて、飛ばし時間および／または日の観念をサポートする。具体的には、ＲＳＳ０．９および２．０では、サーバがある日数または時間数拒否し、その間クライアントが更新を行ってはならないようにすることがきる。この場合、同期エンジンは、この設定がサーバによって規定された場合、これらを守り、その時間中フィードを更新しない。
【００３５】
デフォルト、最少、および公開者指定スケジュールに加えて、少なくとも一部の実施形態では、同期エンジンは、ユーザ指定スケジュールおよび手作業の更新の観念をサポートする。更に具体的には、フィード毎に、ユーザはその選択のスケジュールを指定することができる。プラットフォームの観点からは、ユーザ指定スケジュールは、サーバが指定するとの同じ位複雑となる可能性がある。この場合、プラットフォームは、フィード・スケジュール・モジュールを通じて、フィードから抽出した最新のスケジュール、およびユーザ・スケジュールを維持する。少なくとも一部の実施形態では、ユーザ・スケジュールは常に公開者のスケジュールよりも優位に立つ。加えて、いずれの時点でも、アプリケーションは全てのフィードまたは個々のフィードの強制更新を開始することができる。
【００３６】
帯域幅およびサーバの問題点(consideration)に関して、以下のことを検討する。一実施形態によれば、同期エンジンは、２つの関係がある問題に鑑みて設計することができる。第１に、同期はユーザの帯域幅およびＣＰＵについて考えなければならない。第２に、ＲＳＳプラットフォームが広く用いられているために、同期エンジンはサーバに対するその影響を考えなければならない。これら２つの問題は、いつそしてどのようにフィードをダウンロードするか双方に影響を及ぼす。
【００３７】
いつフィードをダウンロードするかという視点からは、同期エンジンは、以下の考慮点を念頭に入れて設計することができる。サーバからのスケジュールや、ユーザからのその他のいずれの命令もない場合、同期エンジンは、どれだけ頻繁に更新するかについては、非常に控えめにした方がよい。したがって、少なくとも一部の実施形態では、デフォルトのスケジュールを２４時間に設定する。更に、非効率的なサーバがユーザのリソースに悪影響を及ぼすことから保護するために、最少スケジュールは、サーバがどのように指定しても、同期エンジンに過度に頻繁に更新させないように施行することができる。加えて、ログイン時（そして、共通の間隔、例えば、起動時点から１時間毎）における更新は、注意深く管理しなければならない。フィードの更新は、ユーザのログインが完了した後指定の時間期間まで遅らせるとよく、各時間に複数の更新がかち合うのを回避するために、時間を多少ずらすとよい。これは、全ての更新を一度に行わせたいというユーザの要望に対してバランスを取ることができる。更に、先に述べた多飛び越し時間(skip hours)または飛び越し日(skip days)をサーバが用いる場合、クライアントは、猶予期間が終了するやいなや直ちに更新を取り込まない方がよい。代わりに、クライアントは、１５分までの範囲でランダムな間隔だけ待ってからコンテンツを取り込むとよい。
【００３８】
これに関して同期エンジンを補助するために、フィード・スケジュール・モジュール３０２は、フレッシュまたはステール(stale)のような状態をフィード毎に維持することができる。「フレッシュ」状態とは、公開者のスケジュールに基づいて、フィードがフレッシュであることを意味する。「ステール」状態は、公開者のスケジュールが更新を指示しているが、同期エンジンは未だ更新を完了していないことを意味する。最も新鮮なコンテンツに関心があるクライアントは、即座の更新を要求し、それが利用可能になったときに通知を受けることができる。この期待を設定すると、同期エンジンは、コンテンツを更新する際に、ユーザおよびサーバに不利になるようにスケジュールに厳格に従うのではなく、任意の遅延を実施することができる。
【００３９】
どのようにフィードをダウンロードするかに関して、以下のことを検討する。一実施形態では、同期エンジンは、タスク・スケジューラを用いて既定の時点に同期エンジン・プロセスを起動(launch)することができる。同期エンジンが完了した後、次に同期エンジンを再度起動するときにタスク・スケジュールを更新する（即ち、NextSynEngineLauchTime)。
【００４０】
同期エンジンが起動すると、NextUpdateTimeがCurrentTime以下である「保留中の」フィード全てを整列させ、次いで以下のようにこれらを処理する。フィード毎に、以下のプロパティを追跡する。LastUpdatTime, NextUpdateTime、間隔（分単位で指定する）、およびLastErrorInterval。
【００４１】
フィードの同期に成功した終了時に、フィードのLastUpdateTimeを現在の時刻に設定し、NextUpdateTimeをLastUpdateTimeと間隔とランダム性（間隔の１／１０）の和に設定する。即ち、
【００４２】
【表１】
2008547117.tif 000003
Random(argument)は、０とその引数との間の正の値であると定める。例えば、Random(10)は０、１０間の浮動数を返す。
【００４３】
フィードの同期が以下の理由の１つのために失敗した場合、
【００４４】
【表２】
2008547117.tif 000004
以下のように指数後退アルゴリズム(exponential back off algorithm)を適用する。
【００４５】
【表３】
2008547117.tif 000005
全ての「保留中」のフィードの同期が完了した後、同期エンジンは、NextUpdateTimeが(NextUpdateTime<=currenTime)を過ぎているフィードがないか判定を行う。ある場合、これらの「保留中」のフィードを整列させ、同期エンジンが丁度起動したかのように処理する。
【００４６】
未処理の「保留中」のフィードがない場合、同期エンジンはNextUpdateTimeが現在時刻の２分以内となっている（currentTime+２分>=NextUpdateTime)「即座同期」フィードが１つでもないか判定を行う。「即座同期」フィードが１つでもあった場合、同期エンジン・プロセスは走り続け、NextUpdateTimeに「起動し」、「保留中」のフィードを処理するようにタイマを設定する。
【００４７】
「即座同期」フィードがない場合、NextSyncEngineLaunchを、NextUpdateTimeが最も早いフィードのNextUpdateTimeに設定する。次いで、タスク・スケジューラをNextSyncEngineLaunchTimeに設定し、同期エンジン・プロセスは終了する。
【００４８】
一実施形態によれば、キュー内にいくつかの「保留中」のフィードがある場合、同期エンジンは複数のフィードを並行して同期させることができる。しかしながら、並列同期の数は制限されているはずであり、ネットワーク帯域幅およびプロセッサ利用を飽和させないために、ある時間期間において同期を行う回数も制限されているはずである。一実施形態によれば、フィード同期整形(shaping)が、トークン・バケット(token-bucket)によって設けられる。概念的には、トークン・バケットは以下のように動作する。
【００４９】
・ｌ／ｒ秒毎にトークンをバケットに追加する。
【００５０】
・バケットは、多くてもｂ個のバケットを保持できるに過ぎない。バケットが満杯のときにトークンが到達した場合、これを破棄する。
【００５１】
・フィードを同期させる必要がある場合、バケットからトークンを除去し、フィードを同期させる。
【００５２】
・得られるトークンがない場合、フィードはキュー内に留まり、トークンが得られるようになるまで待つ。
【００５３】
この手法により、ｂ回のフィードまで一括してフィード同期が可能となる。しかしながら、長期の場合、同期は一定レートｒに制限される。実現例の一例では、同期エンジンは、ｂおよびｒに次の値を用いる。ｂ＝４およびｒ＝２。
フィード・コンテンツ・ダウンロード・モジュール−−３０４
一実施形態によれば、フィード・コンテンツ・モジュール３０４は、フィードをダウンロードし、新しいフィード項目を既存のフィード・データと併合するプロセスを処理する。
【００５４】
フィード・コンテンツ・ダウンロード・モジュールをどのように実施できるかの一例として、以下のことを検討する。しかるべき時点において、同期エンジンは、フィード・コンテンツ・ダウンロード・モジュールを通じて、サーバに接続し、該当するコンテンツをダウンロードする。
【００５５】
一実施形態によれば、本プラットフォームは、コンテンツをダウンロードするための異なるプロトコルをサポートするように構成されている。例えば、同期エンジンは、ＨＴＴＰを通じてフィード文書をダウンロードすることをサポートすることができる。加えて、同期エンジンは暗号化ＨＴＴＰ  ＵＲＬ（例えば、ＳＳＬ、ｈｔｔｐｓ等）をサポートすることができる。同様に、同期エンジンはＨＴＴＰ  ｇｚｐｉサポートを用いた圧縮もサポートすることができ、更に万国命名規則（ＵＮＣ：Universal Naming Convention）シェアからのフィード・ダウンロードもサポートすることができる。
【００５６】
加えて、同期エンジンは、フィード・コンテンツ・ダウンロード・モジュールを通じて、種々の形式の認証もサポートすることができる。例えば、同期エンジンはフィード毎にユーザ名／パスワードを格納することができ、フィード文書を検索するためのＨＴＴＰ基本認証に、このユーザ名／パスワードを用いることができる。
【００５７】
フィードの更新に関して、以下のことを検討する。フィードが新しいコンテンツを有するか否か判定を行うために、同期エンジンは、フィード毎に次の情報群を保持する。
【００５８】
・ＨＴＴＰ応答において最後に修正されたヘッダによって報告された、最後にフィードが更新されたとき。
【００５９】
・最後のＨＴＴＰ応答におけるEtagヘッダの値。
【００６０】
・フィードについての最新のpubDate値（即ち、フィード・レベル公開日時）。
【００６１】
サイトがEtagまたは最終修正をサポートする場合、同期エンジンはこれらを用いて新しいコンテンツがあるか否かチェックすることができる。サイトは、新しいコンテンツがないことを示すために、ＨＴＴＰ応答コード３０４で応答することができる。それ以外の場合、コンテンツをダウンロードする。例えば、サイトがRFC 3229-for-feedsをサポートする場合、サイトは、クライアントによって受け渡されたEtagに基づいて、新しいコンテンツのみを返すことができる。いずれの方法でも、クライアントは新しいコンテンツを、格納されているコンテンツと併合する。
【００６２】
フィード・コンテンツをどのようにダウンロードすることができるかについての更に詳細な説明として、一実現例においてではあるが、以下のことを検討する。特定のサイトが変化したか否か判定を行うために、同期エンジンは、
・If-None-Matchヘッダ、クライアントがEtagを保存しているか否か。
【００６３】
・値、feed, gzpi（RFC 3229-for-feedsに用いる）を有するヘッダＡ−ＩＭ。
【００６４】
・If-Modified-Sinceヘッダ。クライアントがLast-modified値を保存している場合。
と共に要求を提出する。
【００６５】
サーバがＨＴＴＰ応答コード３０４で応答した場合、コンテンツは変化しておらず、プロセスはここで終了することができる。サーバがコンテンツ（即ち、ＨＴＴＰコード２００または２０６）で応答した場合、ダウンロードしたコンテンツを内部のコンテンツ（注：コード２０６はサーバがRFC3992-for-feedsをサポートすること、およびダウンロードしたコンテンツは新しいコンテンツのみであることを意味する）と併合する。
【００６６】
入手可能なコンテンツがあり、同期エンジンがpubDateを格納しており、ダウンロードしたフィード文書がチャネル・レベルのpubDateエレメントを収容している場合、２つの日付を比較する。内部のpubDateがダウンロードしたpubDateと同じである場合、コンテンツは更新されていない。したがって、ダウンロードしたフィード文書を破棄することができる。
【００６７】
同期エンジンが一度に１つずつ項目を処理する場合、各項目のpubDateを、同期エンジンが格納しているpubDate（ある場合）と比較し、古い方の項目を破棄する。次いで、各項目をストア内にある項目と比較する。比較は、guidがある場合にはこれを用いればよく、あるいはguidがない場合には、リンク・エレメントを用いればよい。一致が生じた場合、新しい項目の内容を古い項目の内容と入れ替える（双方がpubDateを有する場合、これを用いてどちらの方が新しいか判断するが、それ以外では、最後にダウンロードしたものが新しい）。一致が生じない場合、新しいコンテンツを格納されているフィード・コンテンツ（「最上位にある最新」セマンティックを維持する）の前に付加する。内部フィードにおいていずれかの項目を追加または更新した場合、フィードは更新されたと見なされ、ＲＳＳプラットフォームのクライアントに通知する。
【００６８】
エラーの場合について、以下のことを検討する。サーバがコード５００または殆ど４００エラー(most 400 errors)で応答した場合、同期スケジュールをリセットし、サーバは後に再度試す。しかしながら、ＨＴＴＰエラー４１０は、更新スケジュールを「これ以上更新なし」にリセットする指示として扱わなければならない。
【００６９】
ＨＴＴＰ−レベルの方向転換(redirect)に従わなければならないが、クライアント構成を変更してはならない（方向転換が偶発的に与えられるといういくつかの異常な場面がある）。
【００７０】
サーバがＸＭＬ方向転換で応答した場合、フィードを方向転換し、フィードに対して格納されているＵＲＬを自動的に更新しなければならない。これは、クライアントがフィードＵＲＬを自動的に更新した場合だけである。
【００７１】
フィードのダウンロードに関して、ユーザが他の作業に取り掛かっているときに、機械（例えば、帯域幅またはＣＰＵ）の通常の使用をダウンロードが中断してはならない。加えて、ユーザは、コンテンツを拠り所とする双方向アプリケーションにおける場合、できるだけ速くコンテンツを得られるようにしなければならない。
エンクロージャ・ダウンロード・モジュール−−３０６
一実施形態によれば、エンクロージャ・ダウンロード・モジュール３０６は、フィードに対してエンクロージャ・ファイルをダウンロードし、しかるべきセキュリティ・ゾーンを適用することを責務とする。フィード・コンテンツをダウンロードする時点において、エンクロージャもダウンロードする。
【００７２】
エンクロージャのダウンロードは、１対の異なる方法で処理することができる。最初に、基本的エンクロージャをＲＳＳ２．０−様式のエンクロージャであると見なす。基本的なエンクロージャでは、同期エンジンは、エンクロージャ・ダウンロード・モジュール３０６を通じて、ダウンロードしたフィードを自動的に解析して、エンクロージャ・リンクを求める。同期エンジンは、複数の基本的エンクロージャをサポートするように構成されている。エンクロージャ・リンクを用いて、エンクロージャ・ダウンロード・モジュールはエンクロージャをダウンロードすることができる。前述のオブジェクト・モデルを露出するＡＰＩを用いて、クライアントはこのようなことを、例えば、常にエンクロージャをダウンロードするため、または特定のフィードにおける特定の項目の特定のエンクロージャのダウンロードを強制するために、フィード毎に挙動を変化させるように行うことができる。
【００７３】
前述の共通フォーマットの使用により、エンクロージャの処理を改良して設けることができる。具体的には、少なくとも一実施形態では、共通フォーマットはエンクロージャに追加の機能を定める。具体的には、共通フォーマットは、個々のコンテンツの複数の表現を可能にする。これは、例えば、プレビュー・コンテンツおよびデフォルト・コンテンツと標準的な定義を含むこと、およびエンクロージャをダウンロードするかまたは流すか指示できることを含む。加えて、共通フォーマットによって、エンクロージャ、およびコンテンツの表現に関する任意のメタデータが許される。いずれの新しいフィードについても、デフォルトの行為(action)は、いずれのエンクロージャでもその「プレビュー」バージョンをダウンロードし、例えば、項目毎に１０ｋというデフォルトのサイズ制限を課すことである。
【００７４】
ＡＰＩを用いると、クライアントは、このようなことを、フィード毎の挙動変更のように行うことができる。例えば、フィードにおいて「デフォルト」バージョンの項目を常にダウンロードするように、または特定の値のメタデータ・エレメントを有する特定のバージョンのみを常にダウンロードするように、挙動を変更することができる。これは、例えば、クライアントのコールバック(callback)によって、エンクロージャ毎に「これをダウンロードするの？」ロジックを与えることによって行うことができる。加えて、ＡＰＩを用いると、クライアントは、指定したフィードにおけるいずれの特定の項目（または全ての項目）のいずれの特定のエンクロージャのいずれの特定の表現の即座のダウンロードでも強制することができる。
【００７５】
エンクロージャ・ダウンロード・プロセスにおいてセキュリティを設けることに関して、以下のことを検討する。
【００７６】
一実施形態によれば、ダウンロードしたエンクロージャは、Windows XP SP2 Attachment Execution Service （ＳＰ２  ＡＥＳ）機能性を用いる。この機能性は、ファイル・タイプおよびゾーンに基づくセキュリティを設けることができる。例えば、ファイル名およびゾーン情報（即ち、どこからエンクロージャが来たか）を供給されると、ＡＥＳは拒否、許容、または催促すべきか示すことができる。
【００７７】
ゾーン持続(persistence)に関して、ファイルを保存するとき、ＡＥＳはゾーン情報を持ち続けて、後にそれを開くときに、ユーザに促すことができる。
【００７８】
以下の表は、ＡＥＳリスク・レベル／ゾーン対行為のマッピングを記述する。
【００７９】
【表４】
2008547117.tif 000006
図示し説明した実施形態では、同期エンジンは、それがダウンロードするエンクロージャ毎に、メソッド、例えば、::CheckPolicyをコールする。応答に基づいて、同期エンジンは以下の内の１つを行うことができる。
【００８０】
・拒否。保存しない（フィード・ファイルにおいてそれに不良の印を付ける）。
【００８１】
・許容。エンクロージャを保存する。
【００８２】
・催促(prompt)。保存するが、ゾーン情報を持ち続けない。これは、ユーザがファイル上でダブル・クリックした場合、「実行／実行せず」の催促を得ることを意味する。
【００８３】
一実施形態によれば、同期エンジンは最初にエンクロージャをディスクに保存し、エンクロージャをメモリにダウンロードしない。ディスクに保存することにより、フィルタに基づくビールス防止アプリケーションを誘起し、選択した場合に、これらのアプリケーションにエンクロージャを隔離する機会を与える。
保管モジュール−−３０８
一実施形態によれば、保管モジュール３０８は、古いフィード・データに対処することを責務とする。デフォルトでは、フィードは最大２００項目を保持する。フィードが指定の最大値を超過した場合、古い方のフィード項目が保管モジュールによって削除される。しかしながら、関連するエンクロージャは削除されない。
フィード・ストア
一実施形態によれば、フィード・ストア１１２（図１）は、２種類の情報、フィード・リスト１１４およびフィード・データ１１６を保持する。一例として、図４を検討する。ここでは、フィード・リスト１１４は、フィードのリストの階層的ツリー構造４００として具体化されている。フィード・データ１１６は、個々のフィードに伴うデータから成る。この例では、フィード・データは、フィード毎に配列され、項目およびエンクロージャの集合体４０２を含む。
【００８４】
フィード・ストアを実施することができる数多くの異なる方法がある。この特定的な実施形態では、フィード・ストアはファイル・システムの一部から成る。この理由の１つは、簡素さに関連する。即ち、この実施形態では、フィード・リストを単に通常のディレクトリとして表し、その下にサブディレクトリやファイルを置くことができる。階層は、正規のファイル・システム階層として反映される。つまり、「ニュース」や「ブログ」のような各フォルダは、本質的に、サブディレクトリおよびファイルを有するファイル・システムにおける正規のディレクトリである。
【００８５】
この特定的な例では、フィード加入を表す特殊なファイル・タイプがある。一例としてのみ、このファイル・タイプは以下のフォーマット「xyz.stg」を有すると見なす。.stgファイルは、フィードについてのデータ全てを格納する。したがって、ツリー構造４００に具体化したリストのようなフィード・リストを有し、各フィード（またはファイル）の内側には、フィード・データがある。
【００８６】
図示し説明した実施形態では、.stgファイルを実装するには、構造化記憶技術を用いる。構造記憶技術は周知であり、当業者には分かっているはずである。しかしながら、端的な背景として、以下のことを検討する。
【００８７】
構造化記憶は、１つのファイルを、ストレージおよびストリームとして知られているオブジェクトの構造化集合体として処理することにより、ＣＯＭにおいてファイルおよびデータの持続性を備える。構造化記憶の目的は、別個のオブジェクト・パーツを異なるファイルに格納することに伴う性能悪化およびオーバーヘッドを低減することである。構造化記憶は、複合ファイルと呼ばれる標準的な実現例によって、２タイプのオブジェクト、即ち、ストレージおよびストリームの構造化集合体として、１つのファイル実体をどのように処理するか定めることによって、解決策を提供する。これによって、ユーザは、複合ファイルが１つのファイルであり、別個のオブジェクトのネスト状階層ではないかのように、複合ファイルと双方向処理し、管理することが可能となる。ストレージ・オブジェクトおよびストリーム・オブジェクトはファイル内では、ファイル・システムとして機能する。これは、当業者には認められよう。構造化記憶は、新たなオブジェクトを複合ファイルに追加するとき、または既存のオブジェクトのサイズが増大したときにはいつでも全体的にファイルをストレージに再書き込みしなければならない必要性を排除することによって、性能の問題を解決する。新しいデータは永続ストレージにおいて次に利用可能な一に書き込まれ、ストレージ・オブジェクトは、そのストレージ・オブジェクトおよびストリーム・オブジェクトの一を追跡するために維持しているポインタの表を更新する。
【００８８】
このように、図示し説明した実施形態では、.stgファイルを実装する際に、構造化記憶技法を用い、フィード・ストアの上位にあるＡＰＩが異なるストリームおよびストレージへのアクセスを可能にする。この特定的な例では、各ＲＳＳ項目を１つのストリームに書き込む。加えて、ヘッダ・ストリームが、名称、加入、フィードＵＲＬ等のような、個々のフィードに関連する情報を収容する。更に、別のストリームがインデックス型メタデータを格納し、何かに読み出し／非読み出しの印を素早く付けること、項目を削除すること等を含む目的のために、ファイル内にあるコンテンツへの素早く効率的なアクセスを可能にする。
ファイル・システム  −  エンクロージャ
図示し説明した実施形態では、エンクロージャは図１に示したように、構造化ストレージ、またはフィード・データの一部として格納されない。逆に、エンクロージャは、他のアプリケーションまたはユーザがアクセスし操作したいこともある１つまたは複数の写真のような項目として認識される。
【００８９】
つまり、図示し説明した実施形態では、エンクロージャをユーザの特定のプロファイルに書き込む。しかしながら、エンクロージャと関連するフィード項目との間のリンクは、維持している。
【００９０】
一例として図５を検討する。一旦ユーザがフィードに加入し始めると、フィード・コンテンツがユーザのプロファイルの下でローカルに、アプリケーション・データまたはKwonfolder「フィード」のいずれかに格納される。
【００９１】
フィードリストおよびフィードをアプリケーション・データに格納するのは、フィードリストおよびフィードのフォーマットを制御し易くすることができるからである。ＡＰＩを露出し（以下で説明する）、アプリケーションがフィードにアクセスしこれを管理することができるようにする。
【００９２】
フィードリストは、ユーザが加入しているフィードの集合である。この例では、フィードリストを備えているファイルは次のところに位置する。
【００９３】
【表５】
2008547117.tif 000007
ファイルは、フィードのプロパティや、項目およびエンクロージャのプロパティ（当該項目と関連のあるファイルへのＵＲＬ）も収容する。例えば、フィード「ＮＹＴ」のファイルは、次のところに位置する。
【００９４】
【表６】
2008547117.tif 000008
この例では、フィードによってエンクロージャを類別し、Knownfolder「フィード」に格納する。これによって、ユーザおよびその他のアプリケーションはダウンロードしたファイルに容易にアクセスしこれらを用いることが可能となる。
【００９５】
例えば、ユーザがＮＰＲに加入し、彼らのメディア・プレーヤ・アプリケーションが自動的にこれらのファイルを追加できることを確認したいとする。これをKnowfolderにすることにより、ユーザはメディア・プレーヤからそれを閲覧し、それを監視対象フォルダとして設定することが可能になる。エンクロージャは、フィードおよびポストの該当するメタデータを有しアプリケーションが該当するポストおよびフィードにアクセスすることができるようになっている。エンクロージャは以下のように位置付けられる。
【００９６】
【表７】
2008547117.tif 000009
ユーザのハード・ディスクに書き込まれた各エンクロージャは、このエンクロージャについてのメタデータを収容する補助ストリーム（例えば、ＮＴＦＳストリーム）を有する。メタデータは、限定ではない一例として、エンクロージャの発生元であるフィード、著作者、フィード項目へのリンク、記述、名称、公開日、およびダウンロード日、ならびに適宜その他のメタデータを含むことができる。
公開エンジン／ポスト・キュー
正規のブロック・ポストを書き込む多くの場合、本質的に書き込まれているのはＲＳＳ項目である。このＲＳＳ項目は、通例、何らかの形式のサーバに送られ、このサーバがアカウント情報を、ブログの位置等を維持する。この文脈では、公開エンジン１１０（図１）は、アプリケーションがポスティングを行うか、またはコンテンツを公開しつつ、同時にサーバと通信するために利用する通信プロトコルをアプリケーションから抽象化することを可能にするように構成されている。したがって、アプリケーションは、ポストするデータまたはコンテンツを提供しさえすればよく、公開エンジンが、コンテンツをフォーマットし該当するサーバに伝達するという残りの作業を処理する。
【００９７】
いくつかの異なるプロトコルが用いられる可能性があるので、プロトコルをアプリケーションから抽象化することによって、多くの異なるタイプのアプリケーションが公開機能性を利用することを可能にすることについては、柔軟性を著しく高めることができる。図示し説明した実施形態では、公開エンジンの機能性は、サーバと通信するために用いられるプロトコルの知識を得られることを必要とせずに、アプリケーションがブログをポストすることを可能にするＡＰＩとして実施されている。
【００９８】
したがって、この例では、ＡＰＩは、新しいポストを作成するメソッドを有し、このメソッドをコールすると、RSSItemオブジェクトを作成する。このRSSItemオブジェクトは、ポスト・メソッドを有し、このメソッドをコールすると、コンテンツ、この場合はブログを、一時的ストア、即ち、ポスト・キュー１２２（図１）に格納する。コンテンツを一時的ストアに格納するのは、ブログが作成されるときにユーザがオンラインにない場合もあるからである。次いで、ユーザがオンライン接続を行うと、公開エンジン１１０がしかるべきサーバに接続し、サーバに適したプロトコルを用いてブログをサーバにアップロードする。
実現例
以下に続く説明では、ＡＰＩ集合の一例について説明し、前述の機能性を実施するためにはどのようにＡＰＩを実装し構造を作ればいいか示すが、これは一例である。尚、特許請求する主題の主旨および範囲から逸脱することなく、他のＡＰＩも利用可能であることは、認められ理解されよう。説明するＡＰＩは、通例、何らかの形式のコンピュータ読み取り可能媒体上に常駐するコンピュータ読み取り可能命令およびデータとして具体化される。
【００９９】
以下に説明するＡＰＩは、ユーザが加入しているフィード集合（システム・フィード・リスト）、およびフィードに関するプロパティを操作するために用いることができる。加えて、フィード・データＡＰＩ（即ち、項目およびエンクロージャ）が、フィード・ストアに格納されているフィード、およびフィードのその場限りのダウンロードへのアクセスを与える。フィードＡＰＩを用いると、ウェブ・ブラウザ、メディア・プレーヤ、ディジタル画像ライブラリ・アプリケーションなどのようなアプリケーションが、フィード・データをそれらの操作(experience)の中で露出することが可能となる。
【０１００】
説明しようとしている例では、ＡＰＩはＣＯＭ二重インターフェースとして実装され、スクリプティング言語、被管理コード、およびネーティブなWin32(C++)コードからのＡＰＩを利用可能にする。
【０１０１】
図６は、一実施形態による上位のオブジェクトまたはインターフェースIFeedsおよびIFeedFolderオブジェクトまたはインターフェースを、それらに関連するプロパティ、メソッド、およびイベントと共に示す。
【０１０２】
この例では、IFeedsは１つのプロパティ、即ち、IfeedFolderである加入(subscriptions)を有する。これは、全ての加入にとってルート・フォルダである。ルート・オブジェクト上には、DeleteFeed()、DeleteFeedByGuid()、DeleteFolder()等のような、多くのメソッドがある。
【０１０３】
この例において興味深いのは、GetFeedByGuid()メソッドである。このメソッドは、アプリケーションが、例えば、フィードのＧＵＩＤによって特定のフィードにアクセスするためにコールすることができる。つまり、アプリケーションは、フィードの階層的順位について知る必要がない。逆に、プラットフォームがフィードを取り込むことを可能にするために、アプリケーションがフィードのＧＵＩＤを用いることができる。
【０１０４】
加えて、ExisFeed()メソッドは、名称によってフィードの存在をチェックし、ExistFeedByGuid()はＧＵＩＤによってフィードの存在をチェックする。GetFeed()メソッドは、名称またはＧＵＩＤによってフィードを得る。IsSubscribed()メソッドは、アプリケーションまたはコール元が、特定のフィードに加入されているか否か確認することを可能にする。
【０１０５】
加えて、IFeedsオブジェクトもSubscriptionsNotificationsイベントを有し、システム・フィード・リスト上の変更の通知のための登録が可能になる。
【０１０６】
先に記したように、加入はタイプIfeedFolderである。IFeedFolderオブジェクトまたはインターフェースは、本質的に、ディレクトリを規定し、名称、親、パス(path)などのような、同様の種類のプロパティを有する。加えて、IFeedFolderオブジェクトは、タイプIFeedのフィード・プロパティと、タイプIFeedFolderのサブフォルダ・プロパティとを有する。サブフォルダ・プロパティは、本フォルダ（例えば、これは階層的構造が派生するところである）の直下にあるフォルダの集合体に関連があり、フィード・プロパティは個々のフォルダにおける実際のフィードに関連がある。加えて、IFeedFolderは、LastWriteTimeプロパティを有し、このプロパティは、フォルダの内側に何かが書き込まれた最後のときを示す。このプロパティは、暫く走らせていないアプリケーションがあるが、必要であれば同期できるように、フィード・プラットフォームを監視してその状態を確認しておく必要がある場合に有用である。
【０１０７】
IFeedFolder上には複数のメソッドがあり、その一部は、フィードの作成（システムが有しておらず特定のフォルダに追加するフィードを作成する）、サブフォルダの作成、フォルダまたはサブフォルダの削除などに関する。
【０１０８】
図７は、一実施形態による追加のオブジェクトおよびそれらに関連するメソッドを示す。具体的に示すのは、IFeed、ItemおよびIEnclosureオブジェクトである。
【０１０９】
最初にIFeedオブジェクトから始めて、以下のことを検討する。このオブジェクトに関連するプロパティの多くは、ＲＳＳフィード自体から来るものであり、当業者には認められようが、例えば、タイトル、Url、ウェブマスタ、SkipHours、SkipDays、ManagingEditor、Homepage、ImageURL等がある。加えて、興味深い別のプロパティの集合がある。即ち、フィードの一部である項目の全てを有する集合体である項目プロパティと、エンクロージャの全てを書き込む実際のディレクトリを規定するLocalEnclosurePathプロパティである。このため、アプリケーションにとって、後者のプロパティは、アプリケーションがエンクロージャにアクセスするのを非常に簡単にする。
【０１１０】
加えて、このオブジェクトは、個々のフィードを管理するために用いられるDelete()およびDownload()のようなメソッドの小集合をサポートする。更に、このオブジェクトは、メソッドXML()をサポートする。このメソッドは共通フォーマットでフィードのＸＭＬを返す。ＸＭＬデータは、フィードを新聞の外観で作成するというようなことに用いることができる。Clone()は、加入されていないフィードのコピーを返す。
【０１１１】
項目オブジェクトに移り、このオブジェクトは、規定のＲＳＳエレメントを表すプロパティ集合、例えば、記述、Url、タイトル、著作者などを有する。加えて、関連のある実際のフィードを逆に指し示すペアレント・プロパティ、およびアプリケーションが全ての項目にわたって繰り返す必要なくＩｄを操作することができるようにするＩｄプロパティがある。加えて、タイプIEnclosureの項目のエンクロージャの集合体であるエンクロージャ・プロパティがある。更に、IsReadプロパティは、特定の項目が読み出されたか否かをアプリケーションが示すことを可能にする。
【０１１２】
エンクロージャ・オブジェクトに移り、以下のことを検討する。このオブジェクトは、タイプ・プロパティ（例えば、ｍｐ３）、および個々のエンクロージャの長さを記述する長さプロパティを含むプロパティを有する。また、個々のエンクロージャに対するLocalAbsolutePathもある。Download()メソッドは、アプリケーションによって個々のエンクロージャをダウンロードし使用することを可能にする。
結論
以上説明したウェブ・コンテンツ配信プラットフォームは、インターネットから取得するコンテンツを管理し、編成し、消費のために利用するために利用することができる。このプラットフォームは、ウェブ・コンテンツを取得し編成し、このようなコンテンツを、多くの異なるタイプのアプリケーションによる消費に利用可能にする。これらのアプリケーションは個々の配信フォーマットを必ずしも理解できてもできなくてもよい。アプリケーション・プログラム・インターフェース（ＡＰＩ）がオブジェクト・モデルを露出し、これによってアプリケーションおよびユーザは、フィードの作成、読み取り、更新、削除等というような、多くの異なるタスクを容易に遂行することが可能となる。
【０１１３】
加えて、このプラットフォームは、個々のフィード・フォーマットを抽象化し、共通のフォーマットを設けて、プラットフォームに入ってくるフィード・データの使用可能性を促進することができる。更に、このプラットフォームは、エンクロージャを処理し管理する。エンクロージャは、配信了解(syndication-aware)アプリケーションおよび配信了解でないアプリケーション双方に、消費のためにエンクロージャを利用可能とするように、ウェブ・フィードを通じて受信することができる。
【０１１４】
以上、構造的特徴および／または方法論的ステップに対して特定的なことばで本発明について説明したが、添付した特許請求の範囲に定めた発明は、必ずしも記載した具体的な特徴やステップには限定されないことは言うまでもない。むしろ、これら特定の特徴やステップは、特許請求する発明を実施する好適な形態として開示したのである。
【図面の簡単な説明】
【０１１５】
【図１】図１は、一実施形態によるウェブ・コンテンツ配信プラットフォームを含むシステムを示す上位ブロック図である。
【図２】図２は、一実施形態によるオブジェクト・モデルの形態を示すブロック図である。
【図３】図３は、一実施形態によるフィード配信エンジンを示すブロック図である。
【図４】図４は、一実施形態によるフィード・ストアの一例を示す。
【図５】図５は、一実施形態によるユーザ・プロファイルの一例を示す。
【図６】図６は、一実施形態によるオブジェクト例を示す。
【図７】図７は、一実施形態によるオブジェクト例を示す。
【図１】
2008547117.tif 000010
【図２】
2008547117.tif 000011
【図３】
2008547117.tif 000012
【図４】
2008547117.tif 000013
【図５】
2008547117.tif 000014
【図６】
2008547117.tif 000015
【図７】
2008547117.tif 000016
【国際調査報告】
2008547117.tif 000017