(57)【要約】【課題】利用者にニュースを配信するニュース配信システムにおいて、利用者に以前配信した記事に関連する関連記事（訂正記事等）を、当該利用者に確実に配信する。【解決手段】記事ＤＢ１０は、記事と、当該記事が以前の記事に関連する関連記事か否かを示す属性情報と、関連記事である場合における元記事の記事ＩＤとを含む一以上の記事情報を取得して格納する。配信履歴ＤＢ２２は、利用者に配信済みの記事の記事ＩＤが記録された配信履歴情報を格納する。記事選択部３０は、記事ＤＢ１０に格納されている各記事情報に含まれる属性情報および元記事の記事ＩＤと、配信履歴ＤＢ２２に格納されている配信履歴情報とに基づいて、各記事情報に含まれる各記事が利用者に配信済みの記事に関連する関連記事であるか否かを判断し、そのような関連記事であると判断された記事を配信すべき記事として選択する。【選択図】図２
2005242758.tif 000002
【特許請求の範囲】
【請求項１】
一以上の記事の中から利用者に配信すべき記事を選択する記事選択装置であって、
記事と、当該記事が以前の記事に関連する関連記事か否かを示す属性情報と、関連記事である場合における元記事の識別情報とを含む一以上の記事情報を取得する記事情報取得手段と、
当該記事情報取得手段により取得された各記事情報に含まれる属性情報および元記事の識別情報と、前記利用者に配信済みの記事の識別情報が記録された配信履歴情報とに基づいて、前記各記事情報に含まれる各記事が前記利用者に配信済みの記事に関連する関連記事であるか否かを判断し、関連記事であると判断された記事を配信すべき記事として選択する第１の記事選択手段と、
を有することを特徴とする記事選択装置。
【請求項２】
請求項１に記載の記事選択装置であって、
前記関連記事は、以前の記事に対する訂正記事または続報記事であることを特徴とする記事選択装置。
【請求項３】
請求項１または２に記載の記事選択装置であって、
前記記事情報取得手段により取得された一以上の記事の中から、予め設定された検索条件に基づいて、配信すべき記事を検索して選択する第２の記事選択手段をさらに有することを特徴とする記事選択装置。
【請求項４】
請求項３に記載の記事選択装置であって、
前記第２の記事選択手段は、前記第１の記事選択手段が訂正記事を選択する場合、訂正記事以外の記事の中から配信すべき記事を選択することを特徴とする記事選択装置。
【請求項５】
請求項１〜４のいずれか１項に記載の記事選択装置であって、
前記第１の記事選択手段は、利用者毎の配信履歴情報に基づいて、配信すべき記事を利用者毎に選択することを特徴とする記事選択装置。
【請求項６】
請求項１〜５のいずれか１項に記載の記事選択装置であって、
前記第２の記事選択手段は、利用者毎に設定された検索条件に基づいて、配信すべき記事を利用者毎に選択することを特徴とする記事選択装置。
【請求項７】
請求項１〜６のいずれか１項に記載の記事選択装置であって、
前記配信履歴情報に記録された配信済みの記事の識別情報について、その履歴保持期限を、当該記事の属性または利用者の希望に基づいて決定する履歴保持期限決定手段と、
前記配信履歴情報に記録された配信済みの記事の識別情報を、前記履歴保持期限決定手段により決定された履歴保持期限が切れた場合に、前記配信履歴情報から削除する削除手段と、をさらに有することを特徴とする記事選択装置。
【請求項８】
請求項１〜７のいずれか１項に記載の記事選択装置と、
当該記事選択装置により選択された記事を用いて、一以上の記事を含むニュースを作成するニュース作成手段と、
を有することを特徴とするニュース作成装置。
【請求項９】
請求項８に記載のニュース作成装置であって、
前記ニュース作成手段は、予め設定された所定ページ数内に、前記選択された記事をレイアウトすることを特徴とするニュース作成装置。
【請求項１０】
請求項８または９に記載のニュース作成装置であって、
前記ニュース作成手段は、前記関連記事を他の記事とは異なる表示形態でレイアウトすることを特徴とするニュース作成装置。
【請求項１１】
請求項８〜１０のいずれか１項に記載のニュース作成装置であって、
前記ニュース作成手段は、ニュースに関連記事を掲載する場合、当該関連記事に対応する配信済みの記事が配信された時期あるいは場所に関する情報、または、当該記事あるいは当該記事が掲載されたニュースのサムネイル画像を付加することを特徴とするニュース作成装置。
【請求項１２】
請求項８〜１１のいずれか１項に記載のニュース作成装置と、
当該ニュース作成装置により作成されたニュースを利用者に配信するニュース配信手段と、
を有することを特徴とするニュース配信装置。
【請求項１３】
請求項１２に記載のニュース配信装置であって、
利用者に配信された記事について、課金対象から訂正記事を除外して課金処理を行う課金処理手段をさらに有することを特徴とするニュース配信装置。
【請求項１４】
一以上の記事の中から利用者に配信すべき記事を選択する記事選択装置が実行する記事選択方法であって、
記事と、当該記事が以前の記事に関連する関連記事か否かを示す属性情報と、関連記事である場合における元記事の識別情報とを含む一以上の記事情報を取得する記事情報取得ステップと、
当該記事情報取得ステップで取得された各記事情報に含まれる属性情報および元記事の識別情報と、前記利用者に配信済みの記事の識別情報が記録された配信履歴情報とに基づいて、前記各記事情報に含まれる各記事が前記利用者に配信済みの記事に関連する関連記事であるか否かを判断し、関連記事であると判断された記事を配信すべき記事として選択する記事選択ステップと、
を有することを特徴とする記事選択方法。
【請求項１５】
一以上の記事の中から利用者に配信すべき記事を選択するための記事選択プログラムであって、コンピュータに、
記事と、当該記事が以前の記事に関連する関連記事か否かを示す属性情報と、関連記事である場合における元記事の識別情報とを含む一以上の記事情報を取得する記事情報取得ステップと、
当該記事情報取得ステップで取得された各記事情報に含まれる属性情報および元記事の識別情報と、前記利用者に配信済みの記事の識別情報が記録された配信履歴情報とに基づいて、前記各記事情報に含まれる各記事が前記利用者に配信済みの記事に関連する関連記事であるか否かを判断し、関連記事であると判断された記事を配信すべき記事として選択する記事選択ステップと、
を実行させることを特徴とする記事選択プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一以上の記事の中から利用者に配信すべき記事を選択する記事選択装置、および利用者にニュースを配信するニュース配信装置に関する。
【背景技術】
【０００２】
ニュース記事をネットワークを介して利用者に配信するニュース配信サービスが知られている。このニュース配信サービスに関する技術としては、例えば、次のようなものが提案されている。
【０００３】
特許文献１には、記事と共に記事識別コードを新聞紙に印刷して購読者に販売し、購読者の電子端末から記事識別コードに基づいて記事データの検索の依頼を受けると、記事識別コードに対応する記事を検索して、検索された記事を依頼元の電子端末に通知する方法が開示されている。
【０００４】
また、特許文献２には、購読者から購読希望記事の選択を受信すると、購読希望記事を購読者端末に送信し、購読履歴をもとに料金を決定するシステムが開示されている。
【０００５】
【特許文献１】特開２００２−１８９７１９号公報
【特許文献２】特開２００２−１０９２５０号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
ところで、通常の新聞、雑誌等において、誤報の訂正記事等が後日掲載されることがある。このような訂正記事は、定期購読の場合でも見落とされがちであるが、上記特許文献１、２に記載された記事提供方法においては利用者に提供されない可能性が高い。
【０００７】
また、利用者に対しては、訂正記事に限らず、以前配信した記事に関連する続報記事等の関連記事が配信されることが望ましい。しかし、上記特許文献１、２に記載された記事提供方法においては、このような関連記事は利用者に提供されない場合が多い。
【０００８】
そこで、本発明は、一以上の記事の中から、利用者に以前配信した記事に関連する関連記事を、当該利用者に配信すべき記事として確実に選択することができる記事選択装置を提供する。
【０００９】
また、本発明は、利用者に以前配信した記事に関連する関連記事を、当該利用者に確実に配信することができるニュース配信装置を提供する。
【課題を解決するための手段】
【００１０】
本発明は、一以上の記事の中から利用者に配信すべき記事を選択する記事選択装置であって、記事と、当該記事が以前の記事に関連する関連記事か否かを示す属性情報と、関連記事である場合における元記事の識別情報とを含む一以上の記事情報を取得する記事情報取得手段と、当該記事情報取得手段により取得された各記事情報に含まれる属性情報および元記事の識別情報と、前記利用者に配信済みの記事の識別情報が記録された配信履歴情報とに基づいて、前記各記事情報に含まれる各記事が前記利用者に配信済みの記事に関連する関連記事であるか否かを判断し、関連記事であると判断された記事を配信すべき記事として選択する第１の記事選択手段と、を有することを特徴とする。
【００１１】
本発明の好適な一実施形態では、前記関連記事は、以前の記事に対する訂正記事または続報記事である。
【００１２】
また、本発明の好適な一実施形態では、前記記事情報取得手段により取得された一以上の記事の中から、予め設定された検索条件に基づいて、配信すべき記事を検索して選択する第２の記事選択手段をさらに有する。
【００１３】
本発明では、前記第２の記事選択手段は、前記第１の記事選択手段が訂正記事を選択する場合、訂正記事以外の記事の中から配信すべき記事を選択することが望ましい。
【００１４】
また、本発明では、前記第１の記事選択手段は、利用者毎の配信履歴情報に基づいて、配信すべき記事を利用者毎に選択することが望ましい。
【００１５】
また、本発明では、前記第２の記事選択手段は、利用者毎に設定された検索条件に基づいて、配信すべき記事を利用者毎に選択することが望ましい。
【００１６】
また、本発明では、前記配信履歴情報に記録された配信済みの記事の識別情報について、その履歴保持期限を、当該記事の属性または利用者の希望に基づいて決定する履歴保持期限決定手段と、前記配信履歴情報に記録された配信済みの記事の識別情報を、前記履歴保持期限決定手段により決定された履歴保持期限が切れた場合に、前記配信履歴情報から削除する削除手段と、をさらに有することが望ましい。
【００１７】
本発明に係るニュース作成装置は、上記のうちいずれかの記事選択装置と、当該記事選択装置により選択された記事を用いて、一以上の記事を含むニュースを作成するニュース作成手段と、を有する。
【００１８】
本発明では、前記ニュース作成手段は、予め設定された所定ページ数内に、前記選択された記事をレイアウトすることが望ましい。
【００１９】
また、本発明では、前記ニュース作成手段は、前記関連記事を他の記事とは異なる表示形態でレイアウトすることが望ましい。
【００２０】
また、本発明では、前記ニュース作成手段は、ニュースに関連記事を掲載する場合、当該関連記事に対応する配信済みの記事が配信された時期あるいは場所に関する情報、または、当該記事あるいは当該記事が掲載されたニュースのサムネイル画像を付加することが望ましい。
【００２１】
本発明に係るニュース配信装置は、上記のうちいずれかのニュース作成装置と、当該ニュース作成装置により作成されたニュースを利用者に配信するニュース配信手段と、を有する。
【００２２】
本発明では、利用者に配信された記事について、課金対象から訂正記事を除外して課金処理を行う課金処理手段をさらに有することが望ましい。
【００２３】
本発明は、一以上の記事の中から利用者に配信すべき記事を選択する記事選択装置が実行する記事選択方法であって、記事と、当該記事が以前の記事に関連する関連記事か否かを示す属性情報と、関連記事である場合における元記事の識別情報とを含む一以上の記事情報を取得する記事情報取得ステップと、当該記事情報取得ステップで取得された各記事情報に含まれる属性情報および元記事の識別情報と、前記利用者に配信済みの記事の識別情報が記録された配信履歴情報とに基づいて、前記各記事情報に含まれる各記事が前記利用者に配信済みの記事に関連する関連記事であるか否かを判断し、関連記事であると判断された記事を配信すべき記事として選択する記事選択ステップと、を有することを特徴とする。
【００２４】
また、本発明は、一以上の記事の中から利用者に配信すべき記事を選択するための記事選択プログラムであって、コンピュータに、記事と、当該記事が以前の記事に関連する関連記事か否かを示す属性情報と、関連記事である場合における元記事の識別情報とを含む一以上の記事情報を取得する記事情報取得ステップと、当該記事情報取得ステップで取得された各記事情報に含まれる属性情報および元記事の識別情報と、前記利用者に配信済みの記事の識別情報が記録された配信履歴情報とに基づいて、前記各記事情報に含まれる各記事が前記利用者に配信済みの記事に関連する関連記事であるか否かを判断し、関連記事であると判断された記事を配信すべき記事として選択する記事選択ステップと、を実行させることを特徴とする。
【発明の効果】
【００２５】
本発明によれば、一以上の記事の中から、利用者に以前配信した記事に関連する関連記事を、当該利用者に配信すべき記事として確実に選択することができる。
【００２６】
また、本発明によれば、利用者に以前配信した記事に関連する関連記事を、当該利用者に確実に配信することができる。
【発明を実施するための最良の形態】
【００２７】
以下、本発明の実施の形態を図面に従って説明する。
【００２８】
図１は、実施の形態に係るニュース配信装置１を含むニュース配信システムの全体構成を示すブロック図である。このニュース配信システムでは、ニュース提供者が管理するニュース配信装置１と、利用者が使用してニュースを取得する一以上の利用者端末２とが、インターネット等のネットワーク３を介して互いに接続されている。利用者端末２の一例として、店舗等に設置され、ユーザインタフェースを備えたプリンタ複合機がある。ただし、利用者端末２は、パーソナルコンピュータ、携帯電話等の他の情報通信端末であってもよい。
【００２９】
図２は、ニュース配信装置１の機能構成を示すブロック図である。このニュース配信装置１は、一以上の記事の中から、利用者に配信すべき記事を選択し、選択された記事を用いて一以上の記事が掲載されたニュースを作成し、作成されたニュースを利用者（具体的には利用者端末２）に配信するものである。本件明細書では、一以上の記事が掲載されたもの、特に一以上の記事が紙面上、画面上等にレイアウトされたものをニュースと称す。
【００３０】
本実施の形態では、記事の選択やニュースの作成は、利用者毎に行われる。すなわち、ニュース配信装置１は、利用者毎にカスタマイズされたニュースを各利用者に配信する。ただし、ニュースは必ずしもカスタマイズされる必要はなく、記事の選択やニュースの作成は、全利用者について一律に行われてもかまわない。
【００３１】
図２において、ニュース配信装置１は、記事データベース１０（以下、記事ＤＢと称す）、利用者情報データベース２０（以下、利用者情報ＤＢと称す）、記事選択部３０、ニュース作成部４０、ニュース配信部５０、配信履歴更新部６０、および課金処理部７０を有する。
【００３２】
記事ＤＢ１０は、記事とその属性情報とが対応付けられた記事情報を取得して格納する。この記事ＤＢ１０に登録される記事には、大きく分けて、当該記事以前の記事（既出記事ともいう）に関連しない新規記事と、既出記事に関連する関連記事との二種類がある。そして、ここでは、関連記事には、一連の記事報道等において既出記事の続きとなる続報記事と、既出記事の誤りを訂正する訂正記事との二種類がある。記事の属性情報は、少なくとも、当該記事が関連記事であるか否かを示す情報を含み、関連記事である場合には元記事の識別情報を含む。記事ＤＢ１０に格納されているデータの構成については、後に図３を参照して詳細に説明する。
【００３３】
なお、記事情報は、適宜の手段により記事ＤＢ１０に供給される。例えば、新聞社等の記事供給元からネットワークを介して供給される場合もあるし、ニュース配信サービスの提供者によりユーザインタフェースを介して入力される場合もある。
【００３４】
また、記事の属性情報は、ニュース配信サービスの提供者または記事供給元により予め設定されるものである。
【００３５】
利用者情報ＤＢ２０は、ニュースの配信を受ける個々の利用者に関する情報を格納する。この利用者情報ＤＢ２０は、配信すべき記事の検索に用いられる検索条件を含む利用者毎のプロファイル情報を格納するプロファイルＤＢ２１と、配信済みの記事の識別情報を含む利用者毎の配信履歴情報を格納する配信履歴ＤＢ２２とから構成される。ここで、利用者毎のプロファイル情報は、ニュース配信サービスの提供に先立って各利用者から受け付けた利用者登録情報に基づいて生成される。なお、利用者情報ＤＢ２０に格納されているデータの構成については、後に図４、５を参照して詳細に説明する。
【００３６】
記事選択部３０は、記事ＤＢ１０に格納されている複数の記事の中から利用者に配信すべき記事を選択するものである。記事選択部３０は、第１の記事選択部３１と第２の記事選択部３２とから構成される。
【００３７】
第１の記事選択部３１は、記事ＤＢ１０に格納されている各記事情報に含まれる属性情報と、配信履歴ＤＢ２２に格納されている配信履歴情報とに基づいて、各記事情報に含まれる各記事が利用者に配信済みの記事に関連する関連記事であるか否かを判断し、関連記事であると判断された記事を配信すべき記事として選択する。なお、本実施の形態では、第１の記事選択部３１は、利用者毎の配信履歴情報に基づいて、配信すべき関連記事を利用者毎に選択する。
【００３８】
第２の記事選択部３２は、記事ＤＢ１０に格納されている一以上の記事の中から、プロファイルＤＢ２１に格納されているプロファイル情報中の検索条件に基づいて、配信すべき記事を検索して選択する。本実施の形態では、第２の記事選択部３２は、利用者毎に設定された検索条件に基づいて、配信すべき記事を利用者毎に選択する。また、本実施の形態では、第２の記事選択部３２は、訂正記事以外の記事の中から配信すべき記事を選択する。
【００３９】
ニュース作成部４０は、記事選択部３０により選択された記事を用いて、一以上の記事を含むニュースを作成する。本実施の形態では、ニュース作成部４０は、予め設定されたページ数内に、選択された記事をレイアウトする。また、関連記事を他の記事とは異なる表示形態でレイアウトする。また、ニュースに関連記事を掲載する場合、当該関連記事に対応する配信済みの記事に関する元記事配信情報を付加する。ここで、配信済みの記事に関する元記事配信情報としては、例えば、当該記事が配信された時期あるいは場所に関する情報や、当該記事あるいは当該記事が掲載されたニュースのサムネイル画像等が挙げられる。
【００４０】
ニュース配信部５０は、ニュース作成部４０により作成されたニュースをネットワーク３を介して利用者に配信する。
【００４１】
配信履歴更新部６０は、配信履歴ＤＢ２２に格納されている配信履歴情報を更新する。具体的には、ニュース配信部５０により利用者にニュースが配信された場合には、当該利用者の配信履歴情報に、当該ニュースに掲載された各記事の識別情報を含む配信履歴を追加する。また、配信履歴情報に記録された各配信履歴を、それぞれの配信履歴について予め設定された履歴保持期限が切れた場合に、配信履歴情報から削除する。本実施の形態では、履歴保持期限は、配信履歴更新部６０により記事の属性または利用者の希望に基づいて決定される。ただし、履歴保持期限は、どのように決定されてもよいし、すべての記事について一律であってもよい。
【００４２】
課金処理部７０は、利用者に配信された記事について、課金対象から訂正記事を除外して課金処理を行う。
【００４３】
本実施の形態では、上記構成を有するニュース配信装置１は、一般的なコンピュータにより実現される。また、上記各部１０〜７０は、それぞれの機能に応じたプログラムが、ＣＰＵ、ＲＯＭ、ＲＡＭ、ハードディスクドライブ等のコンピュータハードウェア資源により実行されることによって実現される。例えば、記事選択部３０は、記憶媒体に記憶された本実施の形態に係る記事選択プログラムがＣＰＵにより実行されることによって実現される。ただし、ニュース配信装置１の実現態様は、特に限定されない。
【００４４】
次に、記事ＤＢ１０、プロファイルＤＢ２１、配信履歴ＤＢ２２に格納されているデータの構成について説明する。
【００４５】
図３は、記事ＤＢ１０に格納されているデータの構成例を示す図である。図３に示されるとおり、記事ＤＢ１０のデータは、一以上の「記事情報」レコードから構成される。そして、「記事情報」レコードは、「記事ＩＤ」、「記事ジャンル」、「登録日」、「記事種別」、「配信種別」、「元記事ＩＤ」、「キーワード」、「見出し」、および「記事」等の複数のフィールドから構成される。
【００４６】
「記事ＩＤ」フィールドは、記事を識別するための識別情報である記事ＩＤを保持する。「記事ジャンル」フィールドは、政治、社会、スポーツ等の記事のジャンルを保持する。「登録日」フィールドは、記事が記事ＤＢ１０に登録された年月日を保持する。
【００４７】
「記事種別」フィールドは、例えば、一般記事、事件記事、スポーツ記事等の記事の分類を示す情報を保持する。この「記事種別」フィールドのデータは、後述（図１４）する履歴保持期限の決定に使用される。
【００４８】
「配信種別」フィールドは、記事が、新規記事、続報記事、または訂正記事のうちのいずれであるかを示す情報を保持する。そして、「元記事ＩＤ」フィールドは、記事が関連記事（続報記事または訂正記事）である場合における元記事の記事ＩＤを保持する。
【００４９】
「見出し」フィールドは、記事の見出し（タイトル）を保持する。「記事」フィールドは、記事そのもの、すなわち記事本文を保持する。なお、記事には、静止画、動画、音声等も含まれうる。
【００５０】
上記のとおり、「記事情報」レコードを構成する複数のフィールドのうち、「記事」フィールド以外のフィールドには、記事の属性情報が登録される。
【００５１】
図４は、プロファイルＤＢ２１に格納されているデータの構成例を示す図である。この図４には、ある一人の利用者のプロファイル情報が示されているが、このプロファイル情報は、利用者毎に作成されて格納される。
【００５２】
図４（Ａ）に示されるとおり、各利用者のプロファイル情報は、「利用者認証情報」、「個人情報」、「選択条件」、および「配信方法」のぞれぞれのフィールドから構成される。
【００５３】
「利用者認証情報」フィールドは、個々の利用者を識別するために使用される利用者ＩＤおよびパスワードを保持する。「個人情報」フィールドは、利用者の住所や電話番号等を保持する。「選択条件」フィールドは、利用者に配信すべき記事を検索するための検索条件や、配信時の枚数等を保持する。「配信方法」フィールドは、利用者にどのように配信するかという情報を保持する。この例では、利用者からの配信要求を受けて、その際に指定されるプリンタ複合機に配信することを示している。
【００５４】
図４（Ｂ）は、利用者に配信すべき記事を検索するための検索条件の一例を示す図である。この例では、検索条件は、「キーワード」、「種別」、「重要度」の３フィールドにより構成されている。「種別」フィールドが記事ジャンルとなっているレコードのキーワードは、図３に示される記事ＤＢ１０の「記事ジャンル」フィールドに対する検索キーとして扱われる。「種別」フィールドが記事本文となっているレコードのキーワードは、図３に示される記事ＤＢ１０の「記事」フィールドに対する検索キー、すなわち本文全体に対する検索キーとして扱われる。「重要度」フィールドは、利用者にとっての各キーワードの重要度を保持する。この重要度は、後述（図１６）する履歴保持期限の決定に使用される。
【００５５】
図５は、配信履歴ＤＢ２２に格納されているデータの構成例を示す図である。図５には、ある一人の利用者の配信履歴情報が示されているが、この配信履歴情報は、利用者毎に作成されて格納される。
【００５６】
図５に示されるとおり、各利用者の配信履歴情報は、一以上の「配信履歴」レコードから構成される。そして、「配信履歴」レコードは、「記事ＩＤ」、「配信日」、「配信方法」、「配信コメント」、「サムネイル」、および「履歴保持期限」等の複数のフィールドから構成される。
【００５７】
「記事ＩＤ」フィールドは、配信済みの記事の記事ＩＤを保持する。「配信日」フィールドは、記事が配信された年月日を保持する。「配信方法」フィールドは、記事の配信方法を保持する。「配信コメント」フィールドは、記事がどのようにどの場所に配信されたかを示す情報を保持する。「サムネイル」フィールドは、配信済みの記事あるいは当該記事が掲載されたニュースの、大まかなレイアウトを表す画像または縮小画像を保持する。「履歴保持期限」フィールドは、ある記事の配信履歴をいつまで保持するかを示す情報を保持する。
【００５８】
以下、上記構成を有するニュース配信装置１の動作について詳細に説明する。
【００５９】
［ニュース配信処理全体］
ここでは、ニュース配信処理の全体の流れについて簡単に説明する。
【００６０】
図６は、ニュース配信処理の動作手順を示すフローチャートである。ニュース配信装置１は、ニュースの配信を希望する利用者（以下、利用者Ａとする）から当該利用者Ａの利用者ＩＤやパスワードの入力を受け付け、当該利用者Ａを特定する（Ｓ６０１）。ついで、利用者情報ＤＢ２０に格納されている利用者Ａのプロファイル情報および配信履歴情報に基づいて、記事ＤＢ１０に格納されている記事の中から、利用者Ａに配信すべき記事を選択する（Ｓ６０２）。ついで、選択された記事をレイアウトしてニュースを作成し（Ｓ６０３）、作成されたニュースを利用者Ａが使用している利用者端末２に配信する（Ｓ６０４）。そして、利用者Ａの配信履歴情報を更新する（Ｓ６０５）。
【００６１】
なお、この例では、ステップＳ６０３においてニュース配信装置１で記事のレイアウトを行っているが、記事のレイアウトは、利用者端末２側で行われてもよい。
【００６２】
図７は、配信されたニュース（記事レイアウト）の一例を示す図である。図７に示されるとおり、印刷された用紙７００に、記事の見出しや配信日等の情報と、一以上の記事がレイアウトされている。
【００６３】
［記事選択処理］
図８は、図６のステップＳ６０２における記事選択処理の一例を示すフローチャートである。この記事選択処理は、記事選択部３０により行われる。
【００６４】
記事選択部３０は、利用者Ａの配信履歴情報をもとに記事ＤＢ１０の記事情報を参照し、利用者Ａに配信済みの記事に対する訂正記事を選択して取得する（Ｓ８０１）。次に、利用者Ａのプロファイル情報に登録された検索キーをもとに記事ＤＢ１０から配信候補となる記事を検索する（Ｓ８０２）。このステップＳ８０２では、訂正記事は、検索対象から除外される。これは、利用者Ａに配信済みの記事に対応する訂正記事はステップＳ８０１で既に選択されており、それ以外の訂正記事は利用者Ａにとって不要だからである。以下、このステップＳ８０２で検索された記事を通常記事と称す。
【００６５】
以降では、利用者Ａのプロファイル情報の「選択条件」フィールドに登録されている配信量（例えば、Ａ４サイズで５ページ分）に収まるように記事を選択する（Ｓ８０３〜８０８）。まず、ステップＳ８０１で取得した訂正記事の分量を算出する（Ｓ８０３）。ここでの分量とは、印刷した際に必要とされる紙面上でのサイズを意味する。記事の分量は、例えば、記事を固定ピッチのフォントでレイアウトすることを前提にすれば、記事の文字数をもとに算出することができる。例えば、１行が全角８０文字で、１ページが３０行といった変換をすればよい。次に、ステップＳ８０２で検索された通常記事を、記事の累積分量が上記の配信量に達するまで追加する（Ｓ８０４〜８０８）。まず、一つの通常記事を選択し（Ｓ８０４）、ステップＳ８０３と同様にして当該通常記事の分量を算出し（Ｓ８０５）、これを加えた記事の累積分量を求める（Ｓ８０６）。この累積分量が配信量以下であれば（Ｓ８０７：ＹＥＳ）、当該通常記事を利用者Ａに配信すべき記事として追加する（Ｓ８０８）。一方、そうでなければ（Ｓ８０７：ＮＯ）、累積分量が配信量に達したと判断して処理を終了する。
【００６６】
なお、上記の例では、ステップＳ８０１で訂正記事を選択し、ステップＳ８０２で訂正記事以外の記事を選択することとしたが、ステップＳ８０１で関連記事（訂正記事および続報記事）を選択し、ステップＳ８０２で関連記事以外の記事を選択することとしてもよい。
【００６７】
また、ステップＳ８０４における通常記事の選択の順番は、どのような規則に従って決められてもよいが、例えば、記事の重要度、緊急度、ジャンル等の属性や利用者の希望に基づいて決められる。
【００６８】
図９は、図８のステップＳ８０１における訂正記事の取得処理の一例を示すフローチャートである。この訂正記事の取得処理は、第１の記事選択部３１により行われる。
【００６９】
第１の記事選択部３１は、利用者Ａの配信履歴情報から「配信履歴」レコードを一つ取得し（Ｓ９０１）、その記事ＩＤを取得する（Ｓ９０２）。記事ＤＢ１０からこの記事ＩＤを「元記事ＩＤ」フィールドに持つ記事、すなわち利用者Ａに配信済みの記事に関連する関連記事を検索する（Ｓ９０３）。そして、関連記事が見つかったか否かを判断する（Ｓ９０４）。
【００７０】
関連記事が見つからなかった場合（Ｓ９０４：ＮＯ）、後述するステップＳ９０７に移行する。一方、関連記事が見つかった場合（Ｓ９０４：ＹＥＳ）、検索された記事の「配信種別」フィールドを参照して訂正記事であるかどうか判断する（Ｓ９０５）。
【００７１】
訂正記事でないと判断された場合（Ｓ９０５：ＮＯ）、後述するステップＳ９０７に移行する。一方、訂正記事であると判断された場合（Ｓ９０５：ＹＥＳ）、当該記事を利用者Ａに配信すべき記事に追加する（Ｓ９０６）。
【００７２】
ついで、ステップＳ９０７では、未処理の「配信履歴」レコードがあるか否かを判断する。そして、未処理の「配信履歴」レコードがある場合（Ｓ９０７：ＹＥＳ）、ステップＳ９０１に戻り、ない場合は（Ｓ９０７：ＮＯ）、処理を終わらせる。すなわち、ステップＳ９０１からＳ９０６までの処理を、利用者Ａの配信履歴情報が保持するすべての「配信履歴」レコードに対して繰り返し行う。
【００７３】
図１０は、図８のステップＳ８０１における訂正記事の取得処理の他の一例を示すフローチャートである。この訂正記事の取得処理も、第１の記事選択部３１により行われる。
【００７４】
第１の記事選択部３１は、記事ＤＢ１０から「記事情報」レコードを一つ取得し（Ｓ１００１）、その「配信種別」フィールドを参照して訂正記事か否かを判断する（Ｓ１００２）。
【００７５】
訂正記事でない場合（Ｓ１００２：ＮＯ）、後述するステップＳ１００７に移行する。一方、訂正記事である場合（Ｓ１００２：ＹＥＳ）、「元記事ＩＤ」フィールドに保持されている元記事ＩＤを取得する（Ｓ１００３）。そして、利用者Ａの配信履歴情報において、取得された元記事ＩＤを「記事ＩＤ」フィールドに持つ「配信履歴」レコードを検索する。すなわち、利用者Ａの配信履歴情報において、訂正記事に対応する元記事を検索する（Ｓ１００４）。
【００７６】
検索の結果、訂正記事に対応する元記事が見つからなかった場合、すなわち訂正記事に対応する元記事が配信済みでなかった場合（Ｓ１００５：ＮＯ）、後述するステップＳ１００７に移行する。一方、元記事が見つかった場合、すなわち訂正記事に対応する元記事が利用者Ａに配信済みであった場合（Ｓ１００５：ＹＥＳ）、当該記事を利用者Ａに配信すべき記事に追加する（Ｓ１００６）。
【００７７】
ついで、ステップＳ１００７では、記事ＤＢ１０に未確認の「記事情報」レコードがあるか否かを判断する。そして、未確認のレコードがある場合（Ｓ１００７：ＹＥＳ）、ステップＳ１００１に戻り、未確認のレコードがない場合（Ｓ１００７：ＮＯ）、処理を終わらせる。すなわち、ステップＳ１００１からステップＳ１００６までの処理を、記事ＤＢ１０に格納されているすべての「記事情報」レコードに対して繰り返し行う。
【００７８】
［ニュース作成処理］
図１１は、図６のステップＳ６０３におけるニュース作成処理の一例を示すフローチャートである。このニュース作成処理は、ニュース作成部４０により行われる。
【００７９】
ニュース作成部４０は、まず、記事選択部３０により選択された記事の中からレイアウトが完了していない記事を一つ選択する（Ｓ１１０１）。そして、この記事に対するレイアウト（ページ上への割り付け）処理を行う（Ｓ１１０２）。
【００８０】
当該記事が訂正記事でない場合（Ｓ１１０３：ＮＯ）、後述するステップＳ１１０７に移行する。一方、当該記事が訂正記事である場合（Ｓ１１０３：ＹＥＳ）、当該訂正記事に対応する元記事の「配信履歴」レコードの「配信コメント」フィールドの値を取得し、これを元記事配信情報としてレイアウトする（Ｓ１１０４）。ついで、「配信履歴」レコードの「サムネイル」フィールドにサムネイル画像が登録されているか否かを判断する（Ｓ１１０５）。
【００８１】
サムネイル画像が登録されていない場合（Ｓ１１０５：ＮＯ）、後述するステップＳ１１０７に移行する。一方、サムネイル画像が登録されている場合（Ｓ１１０５：ＹＥＳ）、このサムネイル画像もレイアウトする（Ｓ１１０６）。この処理の後、該当する訂正記事部分に囲み線をレイアウトしてもよい。
【００８２】
ついで、ステップＳ１１０７では、未レイアウトの記事があるか否かを判断する。そして、未レイアウトの記事がある場合（Ｓ１１０７：ＹＥＳ）、ステップＳ１１０１に戻り、未レイアウトの記事がない場合（Ｓ１１０７：ＮＯ）、処理を終わらせる。すなわち、ステップＳ１１０１からＳ１１０６までの処理を、記事選択部３０により選択された全記事に対して行う（Ｓ１１０７）。
【００８３】
図１２は、このようにして生成された、訂正記事を含むニュース（記事レイアウト）の一例を示す図である。図１２において、用紙１２００には、枠で囲まれた訂正記事１２０１が、サムネイル画像１２０２と併せてレイアウトされている。
【００８４】
図１１に示されるニュース作成処理で作成されたニュースは、ニュース作成部４０からニュース配信部５０に渡され、ニュース配信部５０により利用者Ａの利用者端末２に配信される。
【００８５】
［配信履歴更新処理］
図１３は、図６のステップＳ６０５における配信履歴更新処理の一例を示すフローチャートである。この配信履歴更新処理は、配信履歴更新部６０により行われる。ここでは、利用者Ａの配信履歴情報を更新する場合について説明する。
【００８６】
配信履歴更新部６０は、まず、各「配信履歴」レコードの「履歴保持期限」フィールドを参照して、履歴保持期限が経過した配信履歴を検索する（Ｓ１３０１）。そして、履歴保持期限が経過した配信履歴が検索されなかった場合（Ｓ１３０２：ＮＯ）、後述するステップＳ１３０４に移行する。一方、検索された場合（Ｓ１３０２：ＹＥＳ）、履歴保持期限が経過した「配信履歴」レコードをすべて削除する（Ｓ１３０３）。
【００８７】
つぎのステップＳ１３０４以降は、新規登録処理である。すなわち、図６のステップＳ６０４で配信されたニュースに含まれる一以上の記事の各々について、「配信履歴」レコードを生成して登録する。
【００８８】
まず、未処理の記事を一つ選択し、当該記事のサムネイル画像を生成し（Ｓ１３０４）、当該記事の履歴保持期限を算出する（Ｓ１３０５）。そして、利用者Ａの配信履歴情報に、当該記事についての「配信履歴」レコードを追加する（Ｓ１３０６）。この際、ステップＳ１３０４で生成されたサムネイル画像も併せて登録される。
【００８９】
ついで、未処理の記事があるかどうかを判断し（Ｓ１３０７）、未処理の記事がある場合（Ｓ１３０７：ＹＥＳ）、ステップＳ１３０１に戻り、未処理の記事がない場合（Ｓ１３０７：ＮＯ）、処理を終了させる。すなわち、ステップＳ１３０４からＳ１３０６までの処理を、配信済みの各記事に対して行う。
【００９０】
図１４は、図１３のステップＳ１３０５における履歴保持期限決定処理の一例を示すフローチャートである。図１５は、記事種別と履歴保持期限とが対応付けられた変換テーブルを示す図である。
【００９１】
まず、配信履歴更新部６０は、配信された記事の「記事情報」レコードの「記事種別」フィールドから記事種別を取得する（Ｓ１４０１）。次に、図１５に示される変換テーブルを参照して、取得した記事種別に対応する履歴保持期間を取得し（Ｓ１４０２）、これを配信日に加算し、当該記事の履歴保持期限を算出する（Ｓ１４０３）。
【００９２】
このような履歴保持期限決定処理は、記事の種別により推定された、訂正記事が出されうる期間を自動設定するような利用に適する。例えば、一般の記事は２週間程度であるが、事故や事件等の事実データが主となる記事はあまり時間が経過してから訂正される可能性が少ないので３日間と設定される。さらに、試合結果等が主となるスポーツ記事では１日間、といった設定がなされる。
【００９３】
図１６は、図１３のステップＳ１３０５における履歴保持期限決定処理の他の一例を示すフローチャートである。図１７は、重要度と履歴保持期限とが対応付けられた変換テーブルを示す図である。
【００９４】
まず、配信履歴更新部６０は、利用者Ａの検索条件（図４参照）に含まれる一以上のキーワードのうち、配信された記事においてヒットしたすべてのキーワードを取得する（Ｓ１６０１）。そして、これらのキーワードに対応する「重要度」フィールドを参照して、重要度の最大値を取得する（Ｓ１６０２）。次に、図１７に示される変換テーブルを参照して、取得した最大値に対応する履歴保持期間を取得し（Ｓ１６０３）、これを配信日に加算し、当該記事の履歴保持期限を算出する（Ｓ１６０４）。
【００９５】
このような履歴保持期限決定処理は、利用者の嗜好を履歴保持期限に反映させる際に好適に利用される。この例では、利用者は、重要と考える分野やキーワードについて、その重要度を大きくすることで、ある程度時間が経過しても訂正記事の配信を受けることができる。また、利用者は、関心が極端に低い、あるいは天気予報等のようにたとえ訂正記事が出ても不要な分野やキーワードについて、その重要度を小さくすることで、履歴保持期間を短く、あるいは配信履歴情報に保持しないようにすることができる。
【００９６】
なお、上記の例では、記事種別やキーワードに基づいて履歴保持期限を決定しているが、他の記事属性に基づいて決定することとしてもよい。
【００９７】
［課金処理］
図１８は、課金処理の一例を示すフローチャートである。この課金処理は、課金処理部７０により行われる。
【００９８】
課金処理部７０は、まず、未処理の配信済み記事を取得する（Ｓ１８０１）。そして、この記事の「配信種別」フィールドを参照し、当該記事が訂正記事であるか否かを判断する（Ｓ１８０２）。訂正記事である場合（Ｓ１８０２：ＹＥＳ）、当該記事については課金処理を行わず、ステップＳ１８０４に移行する。一方、訂正記事である場合（Ｓ１８０２：ＮＯ）、当該記事について課金処理を行う（Ｓ１８０３）。
【００９９】
ついで、ステップＳ１８０４では、未処理の配信済み記事があるかどうかを判断し、未処理の配信済み記事がある場合は（Ｓ１８０４：ＹＥＳ）、ステップＳ１８０１に戻り、ない場合は（Ｓ１８０４：ＮＯ）、処理を終了させる。
【０１００】
以上説明した本実施の形態によれば、以下の効果が得られる。
【０１０１】
（１）本実施の形態では、記事情報として、記事と、当該記事が以前の記事に関連する関連記事か否かを示す属性情報と、関連記事である場合における元記事の属性情報とが対応付けられたものを取得する。そして、各記事情報に含まれる属性情報および元記事の識別情報と、利用者の配信履歴情報とに基づいて、各記事が利用者に配信済みの記事に関連する関連記事であるか否かを判断し、そのような関連記事であると判断された記事を配信すべき記事として選択する。このため、本実施の形態によれば、一以上の記事の中から、利用者に以前配信した記事に関連する関連記事を、当該利用者に配信すべき記事として確実に選択することができる。この結果、利用者に以前配信した記事に関連する関連記事が出された場合、配信を受けた利用者に確実にこの関連記事を配信することが可能となる。特に、訂正記事は確実に利用者に配信されるべきものであるので、関連記事を訂正記事とした場合、非常に大きな効果が得られる。
【０１０２】
（２）利用者に配信すべき記事をキーワード検索等により選択する第２の記事選択部３２は、訂正記事以外の記事の中から配信すべき記事を選択するので、訂正記事が重複して選択されることや、利用者にとって不要な訂正記事が選択されてしまうことを回避することができる。
【０１０３】
（３）記事の配信履歴の履歴保持期限を、当該記事の属性や利用者の希望に基づいて決定し、決定された履歴保持期限が切れた場合に、当該記事の配信履歴を削除するので、配信履歴の量を適切に削減することができる。これにより、記事選択処理の負荷の軽減や記憶容量の削減を図ることができ、また、利用者への不要な訂正記事の配信を避けることができる。
【０１０４】
（４）関連記事を他の記事とは異なる表示形態でレイアウトするので、利用者は、他の記事と関連記事とを容易に識別することができる。特に、訂正記事の見落としを減らすことができる。
【０１０５】
（５）関連記事の元記事についての情報、例えば、元記事がいつ、どこで、どのように配信されたか、を付加するので、利用者の関連記事に対する理解を促進することが可能となる。
【０１０６】
（６）本来課金されるべきでない訂正記事を、課金対象から除外して課金額を算出するので、適切な課金処理を行うことができる。
【０１０７】
以上、本発明の実施の形態について説明したが、本発明が上記の実施の形態に限定されないことは言うまでもない。例えば、記事の属性情報は、記事本文に埋め込まれていてもよい。また、記事の属性情報について、関連記事である場合における元記事の識別情報の有無を、当該記事が以前の記事に関連する関連記事であるか否かを示す属性情報としてもよい。また、本発明に係る記事選択装置、方法、およびプログラムは、上記実施の形態に示されたニュース記事に限られず、雑誌等の他の記事についても適用可能である。
【図面の簡単な説明】
【０１０８】
【図１】実施の形態に係るニュース配信装置を含むニュース配信システムの全体構成を示すブロック図である。
【図２】ニュース配信装置の機能構成を示すブロック図である。
【図３】記事ＤＢに格納されているデータの構成例を示す図である。
【図４】プロファイルＤＢに格納されているデータの構成例を示す図である。
【図５】配信履歴ＤＢに格納されているデータの構成例を示す図である。
【図６】ニュース配信処理の動作手順を示すフローチャートである。
【図７】配信されたニュースの一例を示す図である。
【図８】図６のステップＳ６０２における記事選択処理の一例を示すフローチャートである。
【図９】図８のステップＳ８０１における訂正記事の取得処理の一例を示すフローチャートである。
【図１０】図８のステップＳ８０１における訂正記事の取得処理の他の一例を示すフローチャートである。
【図１１】図６のステップＳ６０３におけるニュース作成処理の一例を示すフローチャートである。
【図１２】訂正記事を含むニュースの一例を示す図である。
【図１３】図６のステップＳ６０５における配信履歴更新処理の一例を示すフローチャートである。
【図１４】図１３のステップＳ１３０５における履歴保持期限決定処理の一例を示すフローチャートである。
【図１５】記事種別と履歴保持期間とが対応付けられた変換テーブルを示す図である。
【図１６】図１３のステップＳ１３０５における履歴保持期限決定処理の他の一例を示すフローチャートである。
【図１７】重要度と履歴保持期間とが対応付けられた変換テーブルを示す図である。
【図１８】課金処理の一例を示すフローチャートである。
【符号の説明】
【０１０９】
１  ニュース配信装置、２  利用者端末、３  ネットワーク、１０  記事ＤＢ、２０  利用者情報ＤＢ、２１  プロファイルＤＢ、２２  配信履歴ＤＢ、３０  記事選択部、３１  第１の記事選択部、３２  第２の記事選択部、４０  ニュース作成部、５０  ニュース配信部、６０  配信履歴更新部、７０  課金処理部。
【図１】
2005242758.tif 000003
【図２】
2005242758.tif 000004
【図３】
2005242758.tif 000005
【図４】
2005242758.tif 000006
【図５】
2005242758.tif 000007
【図６】
2005242758.tif 000008
【図７】
2005242758.tif 000009
【図８】
2005242758.tif 000010
【図９】
2005242758.tif 000011
【図１０】
2005242758.tif 000012
【図１１】
2005242758.tif 000013
【図１２】
2005242758.tif 000014
【図１３】
2005242758.tif 000015
【図１４】
2005242758.tif 000016
【図１５】
2005242758.tif 000017
【図１６】
2005242758.tif 000018
【図１７】
2005242758.tif 000019
【図１８】
2005242758.tif 000020