JP6338909B2 - コンテンツ制御システム - Google Patents

コンテンツ制御システム Download PDF

Info

Publication number
JP6338909B2
JP6338909B2 JP2014066487A JP2014066487A JP6338909B2 JP 6338909 B2 JP6338909 B2 JP 6338909B2 JP 2014066487 A JP2014066487 A JP 2014066487A JP 2014066487 A JP2014066487 A JP 2014066487A JP 6338909 B2 JP6338909 B2 JP 6338909B2
Authority
JP
Japan
Prior art keywords
content
information
user
identification information
tenant
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.)
Active
Application number
JP2014066487A
Other languages
English (en)
Other versions
JP2015191305A (ja
Inventor
樋口　清志
清志 樋口
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.)
Information Services International Dentsu Ltd
Original Assignee
Information Services International Dentsu 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 Information Services International Dentsu Ltd filed Critical Information Services International Dentsu Ltd
Priority to JP2014066487A priority Critical patent/JP6338909B2/ja
Publication of JP2015191305A publication Critical patent/JP2015191305A/ja
Application granted granted Critical
Publication of JP6338909B2 publication Critical patent/JP6338909B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Description

本件は、コンテンツの提供を制御する技術に関する。
近年、ウェブサイトで提供する画像や動画、音楽、文書、プログラム等のコンテンツを特定のユーザにしか提供しない、或いは、そのコンテンツを購入したユーザにしか提供しない、といった制御が行われることがある。
例えば、大手新聞社のウェブサイトでは、有料会員には記事全文の閲覧を許可し、有料会員以外には記事の一部しか閲覧を許可しないといった制御が行われているところもある。
特開２０１１−２２１６００号公報 特開２００９−２０５３１９号公報 特開２００７−２１３４４６号公報 特開２００５−１０７８３１号公報
上記のようにコンテンツの提供を制御する場合、例えば、静的なhtmlページでウェブサイトを構築しただけでは実現できない。この場合、ユーザの権限を確認し、権限に応じてコンテンツ提供の可否を動的に判断する機能を実現するため、例えばウェブサーバにＣＭＳ（Contents Management System）といったシステムを導入するか、そのような制御機能を独自に開発する必要がある。
しかし、これらのシステムの導入や開発には、多大なコストや高い技術力を必要とするため、コンテンツ提供の制御を実現するのは難しいという問題があった。従って、コンテンツを取り扱う規模に比べて初期投資が高くなってしまうような中小の事業者にとっては、有料でコンテンツを提供する事業への参入が困難な状況となっている。
更に、ブログなど個人ベースの情報メディアについても、コンテンツを有料化したいという潜在的なニーズがあると思われるが、小規模であってもコンテンツを制御する機能は上記と同じシステムが必要となるため、個人ベースの情報メディアにおいてコンテンツを制御するシステムの導入は現実的でなかった。
そこで本発明は、コンテンツの提供を制御するシステムの導入を容易に可能とする技術を提供する。
本発明に係るコンテンツ制御システムは、
ユーザ端末に対してコンテンツを提供する複数のコンテンツサーバと、ネットワークを介して前記複数のコンテンツサーバと接続して前記コンテンツの提供を制御する制御装置とを有し、
前記コンテンツサーバが、
前記ユーザ端末からコンテンツの提供の要求を受信する要求受信部と、
前記要求と対応するコンテンツを前記ユーザ端末へ送信するコンテンツ送信部と、
前記ユーザを識別するユーザ識別情報、及び前記コンテンツサーバを運営する事業者を識別する事業者識別情報を含む問い合わせ情報を前記制御装置へ送信する問い合わせ部と、
前記制御装置から前記問い合わせの回答として制御情報を受信し、前記制御情報に基づいて前記コンテンツの提供が不可の場合には前記要求に対して前記コンテンツの送信を行わせない制御情報処理部と、
を備え、
前記制御装置が、
前記コンテンツサーバから問い合わせ情報を受信する問い合わせ受信部と、
前記事業者をテナントとして、複数のテナントで物理テーブルを共有し、前記テナント毎に定義される論理テーブルのカラムと前記物理テーブルのカラムとの対応付けを前記テナント毎に定義するマッピング情報に基づいて、前記事業者識別情報、前記ユーザ識別情報、及びユーザ情報を対応付けて記憶するマルチテナントデータベースから、前記マッピング情報に基づいて前記問い合わせ情報の前記事業者識別情報及び前記ユーザ識別情報と対応する前記ユーザ情報を抽出する抽出部と、
前記ユーザ情報に基づく制御情報を問い合わせ元の前記コンテンツサーバへ送信する回答送信部と、を備える。
前記コンテンツ制御システムは、
前記問い合わせ部が、前記問い合わせ情報として、前記ユーザ識別情報及び前記事業者識別情報に加えて、要求する前記コンテンツを識別するコンテンツ識別情報を送信し、
前記制御装置が、前記コンテンツ識別情報に応じたコンテンツの提供条件を前記ユーザ情報が満たすか否かを判定し、少なくとも当該判定の結果を前記制御情報とする判定部を更に備えても良い。
また、本発明に係るコンテンツ制御システムは、
ユーザ端末に対してコンテンツを提供する複数のコンテンツサーバと、ネットワークを介して前記複数のコンテンツサーバと接続して前記コンテンツの提供を制御する制御装置とを有し、
前記制御装置が、
ユーザ端末に対してコンテンツを提供する複数のコンテンツサーバと、ネットワークを介して接続して前記コンテンツの提供を制御する制御装置であって、
前記ユーザ端末からコンテンツの提供の要求を受信し、前記要求に基づいて、前記コンテンツを識別するコンテンツ識別情報、前記ユーザを識別するユーザ識別情報、及び要求された前記コンテンツを提供する前記コンテンツサーバの事業者を識別する事業者識別情報を取得する要求受信部と、
前記事業者をテナントとして、複数のテナントで物理テーブルを共有し、前記テナント毎に定義される論理テーブルのカラムと前記物理テーブルのカラムとの対応付けを前記テナント毎に定義するマッピング情報に基づいて、前記事業者識別情報、前記ユーザ識別情報、及びユーザ情報を対応付けて記憶するマルチテナントデータベースから、前記マッピング情報に基づいて前記問い合わせ情報の前記事業者識別情報及び前記ユーザ識別情報と対応する前記ユーザ情報を抽出する抽出部と、
前記ユーザ情報に基づいて前記コンテンツの提供の可否を判定する判定部と、
前記判定の結果に基づいて前記コンテンツを前記コンテンツサーバから取得して要求元の前記ユーザ端末へ送信するコンテンツ送信部と、
を備える。
前記コンテンツ制御システムは、
前記制御装置が、前記マッピング情報に基づき、前記論理テーブルにおけるレコードを
、前記物理テーブルにおける第１のレコード及び第２のレコードに分解し、当該第１のレコードと当該第２のレコードとの接続関係を示す情報を付与して登録する登録部を備え、
前記抽出部が、前記マッピング情報及び前記接続関係を示す情報に基づき、前記第１のレコード及び前記第２のレコードを前記物理テーブルから読み出し、結合して出力しても良い。
本発明に係るコンテンツ制御方法は、
ユーザ端末に対してコンテンツを提供する複数のコンテンツサーバと、ネットワークを介して前記複数のコンテンツサーバと接続して前記コンテンツの提供を制御する制御装置とが実行するコンテンツ制御方法であって、
前記コンテンツサーバが、
前記ユーザ端末からコンテンツの提供の要求を受信するステップと、
前記要求と対応するコンテンツを前記ユーザ端末へ送信するステップと、
前記ユーザを識別するユーザ識別情報、及び前記コンテンツサーバを運営する事業者を識別する事業者識別情報を含む問い合わせ情報を前記制御装置へ送信するステップと、
前記制御装置から前記問い合わせの回答として制御情報を受信し、前記制御情報に基づいて前記コンテンツの提供が不可の場合には前記要求に対して前記コンテンツの送信を行わせないステップと、を実行し、
前記制御装置が、
前記コンテンツサーバから問い合わせ情報を受信するステップと、
前記事業者をテナントとして、複数のテナントで物理テーブルを共有し、前記テナント毎に定義される論理テーブルのカラムと前記物理テーブルのカラムとの対応付けを前記テナント毎に定義するマッピング情報に基づいて、前記事業者識別情報、前記ユーザ識別情報、及びユーザ情報を対応付けて記憶するマルチテナントデータベースから、前記マッピング情報に基づいて前記問い合わせ情報の前記事業者識別情報及び前記ユーザ識別情報と対応する前記ユーザ情報を抽出するステップと、
前記ユーザ情報に基づく制御情報を問い合わせ元の前記コンテンツサーバへ送信するステップと、
を実行する。
前記コンテンツ制御方法において、
前記コンテンツサーバが、前記問い合わせ情報として、前記ユーザ識別情報及び前記事業者識別情報に加えて、要求する前記コンテンツを識別するコンテンツ識別情報を送信し、
前記制御装置が、前記コンテンツ識別情報に応じたコンテンツの提供条件を前記ユーザ情報が満たすか否かを判定し、少なくとも当該判定の結果を前記制御情報としても良い。
また、本発明に係る制御方法は、
ユーザ端末に対してコンテンツを提供する複数のコンテンツサーバとネットワークを介して接続して前記コンテンツの提供を制御する制御装置が実行するコンテンツ制御方法であって、
前記ユーザ端末からコンテンツの提供の要求を受信し、前記要求に基づいて、前記コンテンツを識別するコンテンツ識別情報、前記ユーザを識別するユーザ識別情報、及び要求された前記コンテンツを提供する前記コンテンツサーバの事業者を識別する事業者識別情報を取得するステップと、
前記事業者をテナントとして、複数のテナントで物理テーブルを共有し、前記テナント毎に定義される論理テーブルのカラムと前記物理テーブルのカラムとの対応付けを前記テナント毎に定義するマッピング情報に基づいて、前記事業者識別情報、前記ユーザ識別情報、及びユーザ情報を対応付けて記憶するマルチテナントデータベースから、前記マッピング情報に基づいて前記問い合わせ情報の前記事業者識別情報及び前記ユーザ識別情報と
対応する前記ユーザ情報を抽出するステップと、
前記ユーザ情報に基づいて前記コンテンツの提供の可否を判定する判定部と、
前記判定の結果に基づいて前記コンテンツを前記コンテンツサーバから取得して要求元の前記ユーザ端末へ送信するステップと、
を実行する。
前記コンテンツ制御方法において、
前記制御装置が、前記マッピング情報に基づき、前記論理テーブルにおけるレコードを、前記物理テーブルにおける第１のレコード及び第２のレコードに分解し、当該第１のレコードと当該第２のレコードとの接続関係を示す情報を付与して登録し、
前記マッピング情報及び前記接続関係を示す情報に基づき、前記第１のレコード及び前記第２のレコードを前記物理テーブルから読み出し、結合して出力しても良い。
上記課題を解決するための手段の内容は、本発明の課題や技術的思想を逸脱しない範囲で可能な限り組み合わせることができる。また、本発明は、方法をコンピュータに実行させるためのプログラムであってもよい。プログラムは、コンピュータが読み取り可能な記録媒体に記録して提供するようにしてもよい。コンピュータが読み取り可能な記録媒体とは、情報を電気的、磁気的、光学的、機械的、又は化学的作用によって蓄積し、コンピュータによって読み取ることができる記録媒体をいう。このような記録媒体のうち、コンピュータから取り外し可能なものとしては、例えば光ディスク、光磁気ディスク、フレキシブルディスク、磁気テープ、メモリカード等がある。また、コンピュータに固定された記録媒体としてＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）、ＲＯＭ（Read
Only Memory）等がある。
本発明によれば、コンテンツの提供を制御するシステムの導入を容易に可能とする技術を提供できる。
図１は、コンテンツ制御システムの概略構成の一例を示す図である。 図２は、コンテンツサーバの一例を示す機能ブロック図である。 図３は、制御装置の一例を示す機能ブロック図である。 図４は、コンピュータの一例を示す装置構成図である。 図５は、テナントＡが管理する「user」テーブルの一例を示す表である。 図６は、テナントＢが管理する「社員」テーブルの一例を示す表である。 図７は、テナントＣが管理する「購入履歴」テーブルの一例を示す表である。 図８は、物理テーブルのデータ構造と格納データの一例である。 図９は、メタデータとして登録される内容の一例を示す表である。 図１０は、コンテンツの提供条件の一例を示す表である。 図１１は、料金情報として料金記憶部に登録される内容の一例を示す表である。 図１２は、ユーザ情報を登録する処理の一例を示す図である。 図１３は、コンテンツサーバが提供するウェブサイトのトップページの一例を示す図である。 図１４は、入会用のウェブページの一例を示す図である。 図１５は、ユーザを認証する処理の一例を示す図である。 図１６は、コンテンツを提供する処理の一例を示す図である。 図１７は、ユーザ端末３に提供されるコンテンツの一例を示す図である。 図１８は、コンテンツの提供が不可である旨を示すウェブページの一例を示す図である。 図１９は、設定処理の一例を示す処理フロー図である。 図２０は、メタデータ等の設定を行う設定処理の一例を示す処理フロー図である。 図２１は、データ型の対応関係を説明するための図である。 図２２は、インデックステーブルの一例を示す表である。 図２３は、テーブルスペースを説明するための図である。 図２４は、実施形態２のコンテンツ制御システムの概略構成を示す図である。 図２５は、実施形態２におけるコンテンツの提供方法を示す図である。
以下、図面を参照して本発明を実施するための形態について説明する。以下の実施の形態の構成は例示であり、本発明は実施の形態の構成に限定されない。
《実施形態１》
＜システム構成＞
図１は、本発明に係るコンテンツ制御システム１００の概略構成の一例を示す図である。図１において、コンテンツ制御システム１００は、ユーザ端末３に対してコンテンツを提供する複数のコンテンツサーバ２と、ネットワークＮを介して複数のコンテンツサーバ２と接続して前記コンテンツの提供を制御する制御装置１とを有している。
コンテンツサーバ２は、ウェブサイト上で、画像や動画、音楽、文書、プログラム等のコンテンツを提供する所謂ウェブサーバである。コンテンツサーバ２は、例えば、静的なＨＴＭＬファイルで構成されたシンプルなウェブサイトを提供する。また、コンテンツサーバ２は、会員管理機能や閲覧制御機能を持たない簡易的なＣＭＳ（Contents Management System）を有するものでも良い。
ユーザ端末３は、ユーザの操作によって、ネットワークＮを介してコンテンツサーバ２にアクセスし、コンテンツサーバ２にコンテンツの提供を要求する。例えば、コンテンツサーバ２に対してユーザがウェブブラウザを起動させ、リンクを選択する等して、閲覧するウェブページを指定すると、ユーザ端末３は、当該ウェブページのＵＲＬと当該ウェブページを要求するメソッドをコンテンツサーバ２に送信する。ここで本実施形態１のコンテンツ制御システム１００は、コンテンツサーバ２が受信した要求をフックし、制御装置１がコンテンツの提供、即ち当該ウェブページ提供の可否を判定して制御情報をコンテンツサーバ２に送信する。コンテンツサーバ２は、この制御情報に基づき、提供可であれば当該ウェブページをユーザ端末３に送信し、提供不可であれば当該ウェブページをユーザ端末３に提供しない。このように本実施形態１のコンテンツ制御システム１００は、閲覧制御機能を持たないコンテンツサーバ２に対するコンテンツの要求に対し、このコンテンツの提供の可否を制御装置１が制御するシステムである。即ち、本実施形態１のコンテンツ制御システム１００は、制御装置１がコンテンツサーバ２に対して閲覧制御機能を所謂ＳａａＳ（Software as a Service）として提供する。
＜コンテンツサーバ＞
図２は、コンテンツサーバ２の一例を示す機能ブロック図である。図２のコンテンツサーバ２は、要求受信部２１と、コンテンツ送信部２２と、問い合わせ部２３と、制御情報処理部２４とを有する。このうち、問い合わせ部２３と制御情報処理部２４は、後述のように本実施形態用のプラグインモジュールＰＭによって提供される。
要求受信部２１は、ユーザ端末３からコンテンツの提供の要求を受信する。要求受信部２１は、受信した要求に基づき、要求されたコンテンツを示す情報、例えばＵＲＬをメモ
リに格納する。
コンテンツ送信部２２は、要求受信部２１で受信した要求に応じたコンテンツをユーザ端末３へ送信する。
問い合わせ部２３は、要求したユーザを識別するユーザ識別情報、及びコンテンツサーバを運営する事業者を識別する事業者識別情報を含む問い合わせ情報を制御装置１へ送信する。ここで事業者は、例えばコンテンツサーバ２を用いてコンテンツを提供する個人や組織である。
制御情報処理部２４は、制御装置１から前記問い合わせの回答として制御情報を受信し、当該制御情報に基づいてコンテンツの提供が不可の場合には前記要求に対して前記コンテンツの送信を行わせない。例えば、要求されたコンテンツの替りに、エラーの内容を示すウェブページ（エラーページ）を出力するようにする。具体的には、コンテンツ送信部２２が、要求されたコンテンツのＵＲＬを所定のメモリ領域から取得する場合に、制御情報処理部２４は、このメモリ領域のＵＲＬを置き換えることで要求を無効にする。このように制御情報処理部２４がＵＲＬを置き換えることで、コンテンツ送信部２２にコンテンツを取得させず、コンテンツの送信を行わせないようにする。また、制御情報処理部２４がＵＲＬを置き換えることで、コンテンツ送信部２２は、エラーメッセージ等を示す別のウェブページを送信する、即ち要求されたコンテンツの送信を行わせないようにしても良い。
一方、制御情報処理部２４は、コンテンツの提供が可の場合には前記要求に対して、通常通り要求されたコンテンツの送信を行わせる。
要求受信部２１及びコンテンツ送信部２２は、一般的なウェブサーバと同じ機能である。即ち、情報処理装置にアパッチソフトウェアファウンデーションのApache HTTP Serverやマイクロソフト社のIIS（Internet Information Service）といったウェブサーバソウ
トウェアを実行させることで構成される既存のウェブサーバにおいて、ユーザ端末からリクエストを受信し、このリクエストに応じたコンテンツを配信する機能が、要求受信部２１及びコンテンツ送信部２２に相当する。
そして、この既存のウェブサーバに、各ウェブサーバ固有のモジュール形式やＪＡＶＡ（登録商標）のServletFilter等のプログラムモジュールＰＭ（以下、単にプラグインモ
ジュールとも称す）を提供し、実行させることによって、問い合わせ部２３や制御情報処理部２４を備えたコンテンツサーバ２を構成できる。即ち、既存のウェブサーバに、本実施形態用のプラグインモジュールを追加するだけで、本実施形態１におけるコンテンツサーバ２を構成できる。
＜制御装置＞
図３は、制御装置１の一例を示す機能ブロック図である。図３の制御装置１は、データ操作部１０と、物理テーブル１１と、メタデータ記憶部１２と、設定部１３と、要求受付部１４と、変換部１５と、結果応答部１６と、判定部１７、条件記憶部１８、決済部１９、料金記憶部９１とを有する。
物理テーブル１１は、所定のデータ構造（スキーマ）で物理的なファイルとしてデータレコードを格納する記憶装置である。本実施形態１では、データ構造が同一の物理テーブル１１を、複数のテナントが共有する。すなわち、異なるテナントのデータを同一の物理テーブル１１に保持する。
また、データ操作部１０は、レコードの挿入（登録）、レコードの選択（検索）、レコードの更新、レコードの削除等の操作を物理テーブル１１に対して行う。
また、メタデータ記憶部１２は、各テナントが業務等に応じて定義する論理テーブルのデータ構造と物理テーブル１１のデータ構造との対応付けを示すメタデータを記憶する。本実施形態１では、物理テーブル１１は各テナントに共通であり、汎用的なデータ構造を有している。そして、メタデータにおいて、論理テーブルの１カラム（「列」、「項目」、「フィールド」とも呼ぶ）に対し、物理テーブル１１の１カラムを割り当てる。このとき、対応するデータ型のカラムを割り当てるものとする。なお、メタデータを「マッピング情報」とも呼ぶ。
ここで、各テナントが定義する論理テーブルの１レコードは、物理テーブル１１の１レコードで保持できない場合がある。例えば、物理テーブル１１のカラム数の方が論理テーブルのカラム数よりも少ない場合は論理テーブルのレコードを物理テーブルの１レコードでは保持することができない。また、あるデータ型のカラムが、物理テーブル１１に予め用意された数の方が論理テーブルに定義された数よりも少ない場合も、論理テーブルのレコードを物理テーブルの１レコードで保持することができない。このような場合、論理テーブルにおける１レコードを、物理テーブル１１における２以上のレコードに分解して保持する。このため、物理テーブル１１は、複数のレコードの接続関係（「ページ」とも呼ぶ）を示すカラムを含む。そして、メタデータは、論理テーブルのカラムと、物理テーブル１１のカラム及びページとを対応付けることで、値を１対１に対応付けるものとする。
設定部１３は、ネットワークＮを介して各事業者の管理者端末４からメタデータを設定するための命令を受け付け、メタデータ記憶部１２に記憶させる。なお、管理者端末４は、メタデータを設定するための命令を入力できる情報処理装置であれば良く、例えばコンテンツサーバ２であっても良い。また、制御装置１の操作者が、事業者側から設定の内容を聞き取り、メタデータを設定するための命令を制御装置１に直接入力しても良い。また、設定部１３は、ネットワークＮを介して各事業者の管理者端末４からコンテンツの提供条件を設定するための命令を受け付け、条件記憶部１８に記憶させる。
要求受付部１４は、ネットワークＮを介してコンテンツサーバ２や管理者端末４、ユーザ端末３等の他の装置からデータ操作を行うための要求を受け付け、変換部１５に渡す。従って、要求受付部１４は、本実施形態１において、コンテンツサーバ２から問い合わせ情報を受信する問い合わせ受信部でもある。
変換部１５は、メタデータ記憶部１２が記憶するメタデータに基づいて、テナント端末から受け付けたデータ操作要求を、物理テーブル１１に対するデータ操作命令（「クエリ」、「問合せ」とも呼ぶ）に変換し、データ操作部１０に伝送する。例えば、他の装置から事業者識別情報や、ユーザ識別情報、及びユーザ情報の登録を要求された場合、変換部１５は、これらの情報をメタデータに基づいて対応付けてデータ操作部１０へ渡し、物理テーブル１１に記憶させる。
また、変換部１５は、データ操作部１０から取得したデータ操作の結果を受け取り、各テナントの論理テーブルにおける項目に変換して結果応答部１６や判定部１７に渡す。従って、変換部１５は、本実施形態１において、物理テーブル１０から、マッピング情報に基づいて問い合わせ情報の事業者識別情報及びユーザ識別情報と対応するユーザ情報を抽出する抽出部でもある。
判定部１７は、条件記憶部１８から事業者識別情報に応じたコンテンツの提供条件を読出し、変換部１５から渡されたユーザ情報が、コンテンツの提供条件を満たすか否かを判定し、少なくとも当該判定の結果を制御情報として結果応答部１６へ渡す。また、コンテンツの提供条件がコンテンツ毎に設定されている場合、判定部１７は、条件記憶部１８か
ら事業者識別情報及びコンテンツ識別情報に応じたコンテンツの提供条件を読出し、変換部１５から渡されたユーザ情報が、コンテンツの提供条件を満たすか否かを判定し、当該判定の結果を制御情報として結果応答部１６へ渡しても良い。
結果応答部１６は、コンテンツサーバ２や管理者端末４、ユーザ端末３等の装置から受け付けたデータ操作要求の結果を、要求元の装置へ送信する。従って、結果応答部１６は、本実施形態１において、ユーザ情報に基づく制御情報を問い合わせ元の前記コンテンツサーバ２へ送信する回答送信部でもある。
決済部１９は、ユーザが入会する際の会費やコンテンツを購入する費用を受領して、決済するための処理を行う。例えば、ユーザ端末３からクレジットカードの情報を受信し、ネットワークを介してカード会社のサーバ（不図示）にアクセスし、クレジットカードの情報と金額を通知してクレジットカードの利用を要求し、クレジットカードの利用が可能、即ち支払いが可能であれば、ユーザ情報をマルチテナントデータベースに登録させてコンテンツの提供を可能とする。
これに限らず決済部１９は、ユーザ端末３からプレペイドカード（システム）や電子マネーの情報を受信し、ネットワークを介してプレペイドカード（システム）や電子マネーを運営する会社のサーバ（不図示）にアクセスし、プレペイドカード（システム）や電子マネーの情報と金額を通知して利用を要求し、この利用が可能、即ち支払いが可能であれば、ユーザ情報をマルチテナントデータベースに登録させてコンテンツの提供を可能としても良い。
また、決済部１９は、コンビニ払いや銀行振り込み等で後払いするための番号等をユーザ端末３に送信して表示させ、ユーザ情報をマルチテナントデータベースに仮登録させておき、後日支払先の口座を管理するサーバ等にアクセスして、支払いが確認できた場合にユーザ情報を本登録させても良い。
＜装置構成＞
図４は、コンピュータの一例を示す装置構成図である。制御装置１、コンテンツサーバ２、ユーザ端末３、及び管理者端末４は、図４に示すようなコンピュータである。図４に示すコンピュータ１０００は、ＣＰＵ（Central Processing Unit）１００１、主記憶装
置１００２、補助記憶装置１００３、通信ＩＦ（Interface）１００４、入出力ＩＦ（Interface）１００５、ドライブ装置１００６、通信バス１００７を備えている。ＣＰＵ１００１は、プログラム（「ソフトウェア」又は「アプリケーション」とも呼ぶ）を実行することにより本実施の形態に係る処理を行う。主記憶装置１００２は、ＣＰＵ１００１が読み出したプログラムやデータをキャッシュしたり、ＣＰＵの作業領域を展開したりする。
主記憶装置は、具体的には、ＲＡＭ（Random Access Memory）やＲＯＭ（Read Only Memory）等である。補助記憶装置１００３は、ＣＰＵ１００１により実行されるプログラムや、本実施の形態で用いる設定情報などを記憶する。補助記憶装置１００３は、具体的には、ＨＤＤ（Hard-disk Drive）やＳＳＤ（Solid State Drive）、フラッシュメモリ等である。主記憶装置１００２や補助記憶装置１００３は、制御装置１の物理テーブル１１やメタデータ記憶部１２、その他の一時データを記憶する手段として働く。通信ＩＦ１００４は、他のコンピュータとの間でデータを送受信する。通信ＩＦ１００４は、具体的には、有線又は無線のネットワークカード等である。制御装置１及びコンテンツサーバ２は、通信ＩＦ１００４を介してインターネット等のネットワークＮに接続されている。
入出力ＩＦ１００５は、入出力装置と接続され、ユーザから操作を受け付けたり、ユーザへ情報を提示したりする。入出力装置は、具体的には、キーボード、マウス、ディスプ
レイ、タッチパネル等である。ドライブ装置１００６は、磁気ディスク、光磁気ディスク、光ディスク等の記憶媒体に記録されたデータを読み出したり、記憶媒体にデータを書き込んだりする。以上のような構成要素が、通信バス１００７で接続されている。なお、これらの構成要素はそれぞれ複数設けられていてもよいし、一部の構成要素（例えば、ドライブ装置１００６等）を設けないようにしてもよい。また、入出力装置がコンピュータと一体に構成されていてもよい。また、ドライブ装置１００６で読み取り可能な可搬性の記憶媒体や、フラッシュメモリのような可搬性の補助記憶装置１００３、通信ＩＦ１００４などを介して、本実施の形態で実行されるプログラムが提供されるようにしてもよい。そして、ＣＰＵ１００１が所定のプログラムを実行することにより、図４に示したコンピュータを前述の制御装置１や、コンテンツサーバ２、ユーザ端末３、管理者端末４等として動作させる。
＜データ構造＞
次に、物理テーブル１１のデータ構造と論理テーブルのデータ構造との対応関係の一例を説明する。図５〜図７に示す表は、テナントＡ〜Ｃが制御装置１において保持している論理テーブルと格納データの一例である。図５は、テナントＡが管理する「user」テーブルのカラム名と登録されたレコードの一例を示す表である。図５に示す「user」テーブルは、「名前」、「性別」、「ユーザＩＤ」、「会員種別」及び「入会日」の各カラムを有する。なお、データ型は、例えば、「名前」及び「性別」が文字列型、「ユーザＩＤ」及び「会員種別」が数値型、「入会日」が日付型である。「user」テーブルにおいて、「ユーザＩＤ」は、ユーザを一意に識別するユーザ識別情報である。
図６は、テナントＢが管理する「社員」テーブルに登録されたデータの一例を示す表である。図６に示す「社員」テーブルは、「社員番号」「部署名」及び「役職」の各カラムを有する。なお、データ型は、例えば、「部署名」及び「役職」が文字列型、「社員番号」が数値型である。「社員」テーブルにおいて、「社員番号」は、ユーザを一意に識別するユーザ識別情報である。
図７は、テナントＣが管理する「購入履歴」テーブルに登録されたデータの一例を示す表である。図７に示す「購入履歴」テーブルは、「カスタマＩＤ」、「コンテンツ名」、「コンテンツ種別」、「ＵＲＬ」、「価格」、「発売日」及び「購入日」の各カラムを有する。なお、データ型は、例えば、「コンテンツ名」、「コンテンツ種別」、「ＵＲＬ」が文字列型、「カスタマＩＤ」及び「価格」が数値型、「発売日」及び「購入日」が日付型である。「購入履歴」テーブルにおいて、「カスタマＩＤ」は、ユーザを一意に識別するユーザ識別情報である。
図５〜図７に示すように、本実施形態１では、テナント単位で、保持する情報や、制御の条件等を異ならせることができるので、さまざまな閲覧制御方法に対応することができる。
例えば、テナントＡの「user」テーブルでは、属性として会員種別を定義しておき、その会員種別に応じて参照可能なコンテンツの範囲を制御する。
テナントＢの「社員」テーブルでは、属性として部署名、役職を定義しておき、その部署名や役職に応じて参照可能なコンテンツの範囲を制御する。
また、テナントＣの「購入履歴」テーブルでは、属性として購入日等の情報を定義しておき、その購入日等に応じて参照可能なコンテンツの範囲を制御する。
図８に示す表は、物理テーブル１１のデータ構造と格納データの一例である。図８の物理テーブルは、「TenantID」、「TypeID」、「DataID」、「PageID」、「Char1」、「Char2」、「Num1」、「Num2」、「Date1」、「Date2」等のカラムを有する。なお、データ型
は、例えば、「TenantID」、「TypeID」、「Char1」及び「Char2」が文字列型、「Num1」及び「Num2」が数値型、「Date1」及び「Date2」が日付型である。なお、各カラムのデータサイズ（「データ長」とも呼ぶ）は、可変長としても固定長としてもよい。図８には明示していないが、データ型は同一であってデータサイズが異なる複数のカラムを設けてもよい。
「TenantID」のカラムには、制御装置１のユーザであるテナントを識別するための識別情報、即ち事業者識別情報が登録される。本実施形態１では、ユーザ端末３や管理者端末４等からデータを入力する際、まず、テナントの識別情報（例えば「TenantID」）を入力して事業者を特定する。なお、「TenantID」は、ユーザや管理者が直接入力することに限らず、例えば、ユーザ端末３や管理者端末４から制御装置１にアクセスする際のＵＲＬ内に「TenantID」が判別可能な情報を組み込んでおく。
例えば、以下のように、tenant_a、tenant_bといった「TenantID」をドメインのサーバ名やパス情報として組み込んでおき、これを抽出して事業者を特定しても良い。
ドメインのサーバ名: https://tenant_a.domain.co.jp/hoge/...
パス情報： https://wwww.domain.co.jp/tenant_b /hoge/...
そして、基本的に各テナントに係るデータの操作は物理テーブル１１に登録されたレコードのうち、「TenantID」のカラムに当該テナントの識別情報が登録されたレコードに対して行われる。また、各テナントのデータが物理テーブル１１に新たなレコードとして挿入される場合、「TenantID」のカラムに当該テナントの識別情報が登録される。このようにすることで、ハードウェアリソースからアプリケーション及びデータベース構造までを共有したＳａａＳを実現することができる。
「TypeID」のカラムには、各テナントにおいて論理テーブルを識別するための識別情報が登録される。また、「DataID」のカラムには、各論理テーブルにおいてレコードを一意に特定するための識別情報が登録される。各論理テーブルにおいてレコードを一意に特定できるように「DataID」の値を付与（採番）すれば、「TenantID」、「TypeID」及び「DataID」の複合キーによって各テナントの論理テーブルにおけるレコードを一意に特定できるようになる。なお、図８に示すように、全ての論理テーブルにおいてレコードを一意に特定できるように「DataID」の値を付与するようにしてもよい。
「PageID」のカラムには、論理テーブルにおける１レコードが物理テーブル１１において複数のレコードに分解されて登録される場合の接続関係（接続順序）を表す情報が登録される。なお、図８の例では、接続関係を表す情報として、通し番号を登録している。図８の例では、「DataID」及び「PageID」によって、論理テーブルのカラムを特定することができるため、物理テーブル１１の複数のレコードから論理テーブルにおける１レコードを復元できるようになる。なお、「TenantID」、「TypeID」、「DataID」及び「PageID」のカラムを複合キーとして物理テーブル１１のレコードを一意に特定できるようにしてもよい。
また、「Char1」、「Char2」、「Num1」、「Num2」、「Date1」、「Date2」・・・のカラムには、論理テーブルの各カラムの値が登録される。すなわち、これらは、論理テーブルの複数のカラムに保持される値をそれぞれ独立に保持するカラムである。例えば、「Char1」及び「Char2」は、文字列型のカラムである。また、「Num1」及び「Num2」は、数値型のカラムである。「Date1」及び「Date2」は、日付型のカラムである。なお、図８はカラムの構成を簡略化した例であり、物理テーブル１１は、他のデータ型のカラムをさらに有していてもよいし、各データ型のカラムを３列以上有していてもよい。また、物理テーブル１１に設けられる各データ型のカラム数は、同数でなくてもよい。例えば、物理テー
ブル１１は、文字列型のカラムを３０列、数値型のカラムを１０列、日付型のカラムを５列設けるといった定義が可能である。ただし、マルチテナントシステムにおいては汎用性が求められるため、平均的に各データ型のカラム数を決定したり、テナントのニーズや使用実績等に基づいて各データ型のカラム数を決定してもよい。なお、論理テーブルのデータ構造と物理テーブル１１のデータ構造との対応付けは、テナント毎に予めメタデータに定義される。
図９は、メタデータとして登録される内容の一例を示す表である。図９（ａ）は、テナントＡのuserテーブルに係るメタデータを示し、図９（ｂ）は、テナントＢの社員テーブルに係るメタデータを示し、図９（ｃ）は、テナントＣの購入履歴テーブルに係るメタデータを示す。
メタデータは、例えばテナントごとにＤＢＭＳ上のテーブル又はファイルシステム上のファイルとして保持される。本実施形態１では、テナント（例えば「テナントＡ」、「テナントＢ」、「テナントＣ」等）及び論理テーブル（例えば「user」テーブル、「社員」テーブル、「購入履歴」テーブル等）の組合せに対して、物理テーブル１１の「TypeID」が一意に割り当てられる。さらに、メタデータは、図５〜図７に示した論理テーブルのカラムと図８に示した物理テーブルのカラムとの対応付けを示している。
また、本実施形態１では、論理テーブルの１レコードを物理テーブル１１において複数のレコードに分解して登録する場合がある。よって、論理テーブルの「カラム名」に対し、物理テーブル１１の「対応カラム名」及び分解された各レコードを一意に特定するための「PageID」が対応付けられている。図８の「DataID」の値が「００１」〜「００４」のレコードのように、ある「DataID」に対し「PageID」が１のみである場合、論理テーブルのレコードは分解されずに物理テーブル１１に格納されていることがわかる。一方、図８の「DataID」の値が「００５」及び「００６」のレコードのように、「DataID」の値が同一であって「PageID」の値が２以上のレコードが存在する場合、論理テーブルのレコードは複数に分解されて物理テーブル１１に格納されていることがわかる。このように、「PageID」のカラムは、物理テーブル１１における複数のレコード間の接続関係を示すデータともいえる。
本実施形態１では、基本的にテナント毎に論理テーブルやメタデータが定義される。ただし、各テナントが共通に利用するマスターデータを用意するようにしてもよい。例えば、郵便番号と住所の一部を対応付けて記憶する郵便番号マスタを、各テナントに共通のメタデータで保持するようにしてもよい。このような郵便番号マスタの内容は郵便制度の規格によって決まるため、各テナントが共通に利用する方が効率的である。共通のメタデータはファイルシステム上のファイルとして制御装置１の管理者が一元管理し、各テナントのメタデータはＤＢＭＳ上のレコードとして「TenantID」と関連付けて管理するようにしてもよい。
図１０は、コンテンツの提供条件として条件記憶部１８に登録される内容の一例を示す表である。図１０（ａ）は、テナントＡのuserテーブルに係る提供条件を示し、図１０（ｂ）は、テナントＢの社員テーブルに係る提供条件を示し、図１０（ｃ）は、テナントＣの購入履歴テーブルに係る提供条件を示す。
図１０（ａ）〜図１０（ｃ）の例では、コンテンツＩＤ、即ちコンテンツ識別情報と提供条件とが対応付けられて登録されている。本実施形態１において、コンテンツ識別情報は、コンテンツのＵＲＬを用いている。なお、コンテンツ識別情報は、ＵＲＬに限らず、ウェブサイト内で一意にコンテンツを特定できる情報であれば、ファイル名やシリアル番号、任意の記号等であっても良い。
制御装置１の判定部１７は、条件記憶部１８から、この提供条件を読み出してコンテンツ提供の可否を判定する。
図１０（ａ）では、コンテンツＩＤが/memberarea/＊に該当する場合、会員であることを提供条件としている。なお、本実施形態１において、＊は、＊以下の階層に含まれる全てのコンテンツが該当することを示す。このように会員が提供条件である場合、判定部１７は、例えば問い合わせ情報のユーザ識別情報と対応するユーザ情報が抽出されたか否かで、コンテンツの提供の可否を判定する。また、判定部１７は、ユーザ識別情報と対応するユーザ情報の入会日が現在日時から所定期間（有効期間）内か否かで、コンテンツの提供の可否を判定しても良い。
また、図１０（ａ）では、コンテンツＩＤが/contents?cid=12343326に該当する場合、会員種別が「２」であることを提供条件としている。この会員種別は、通常会員であれば「１」、ゴールド会員であれば「２」、プラチナ会員であれば「３」等のように、コンテンツの提供条件を異ならせる会員の種別毎に設定される。
このように会員種別が提供条件である場合、判定部１７は、例えば問い合わせ情報のユーザ識別情報と対応するユーザ情報の会員種別が、提供条件の会員種別と合致したか否かで、コンテンツの提供の可否を判定する。なお、ユーザ情報の値、本例では会員種別が提供条件と一致したことに限らず、３＞２＞１のようにユーザ情報の値に順位を決めて条件記憶部に記憶しておき、ユーザ情報の値（会員種別）が、提供条件以上の順位か否かによって、コンテンツの提供の可否を判定しても良い。
図１０（ｂ）では、コンテンツＩＤが/management/*に該当する場合、役職が部長以上
か否かを提供条件としている。なお、役職の値は、社長＞専務＞部長＞課長＞主任等のように順位を定めておく。
このように役職が提供条件である場合、判定部１７は、例えば問い合わせ情報のユーザ識別情報と対応するユーザ情報の役職が、提供条件を満たすか否かで、コンテンツの提供の可否を判定する。例えば、役職≧部長の場合、判定部１７は、ユーザ情報の役職が部長以上、即ち、社長、専務又は部長であった場合にコンテンツの提供可と判定し、ユーザ情報の役職が部長未満、即ち、課長又は主任であった場合にコンテンツの提供不可と判定する。
同様に、図１０（ｂ）では、コンテンツＩＤが/product/*に該当する場合、問い合わせ情報のユーザ識別情報と対応するユーザ情報の部署名が、提供条件を満たすか否か、例えば一致するか否かで、コンテンツの提供の可否を判定する。
図１０（ｃ）では、コンテンツＩＤが/paidcontents/*に該当する場合、問い合わせ情
報のＵＲＬ（コンテンツ識別情報）が、ユーザ情報の購入済みＵＲＬと一致するか否かで、コンテンツの提供の可否を判定する。
なお、提供条件は、ユーザ情報だけでなく、他の情報と組み合わせたものでも良い。例えば、図１０（ｃ）では、コンテンツＩＤが/data/*に該当する場合、ユーザ情報の購入
日が一週間以内か否かで、コンテンツの提供の可否を判定する。これに限らず、コンテンツの提供回数が所定数以下か、所定期間内に提供したコンテンツの情報量が所定量以内か、デイタイムや深夜など所定の時間帯か等を条件に用いても良い。
これらの提供条件には様々なパターンが考えられ、テナント単位で、この提供条件をカ
スタマイズ可能な構成としても良い。例えばDSL（domain-specific language：ドメイン
固有言語）や既存技術の汎用的なスクリプト言語（javaScript、Groovyなど）で、提供条件の入力を受け付けて、条件記憶部１８に登録しても良い。
図１１は、料金情報として料金記憶部９１に登録される内容の一例を示す表である。図１１に示すように、料金情報は、コンテンツ識別情報や会員種別など課金対象を識別する情報と、料金（金額）、期間を記憶している。
＜ユーザ情報の登録＞
図１２は、ユーザ情報を登録する処理の一例を示す図である。先ず、入会登録のためユーザ端末３が、コンテンツサーバ２にアクセスすると（ステップＳ１０）、コンテンツサーバ２は、制御装置１の入会用のウェブページに接続するためのリンクを掲載したウェブページをユーザ端末３へ送信して表示させる(ステップＳ１５)。
このリンクをユーザが選択すると、ユーザ端末３は、当該リンクの記述に従って制御装置１にＵＲＬを送信することで、入会用のウェブページを要求する（ステップＳ２０）。
制御装置１は、入会用のウェブページ（入力フォーム）をユーザ端末３へ送信して表示させる(ステップＳ２５)。
ユーザが入力フォームにユーザ情報を入力して送信を選択すると、ユーザ端末３は、入力されたユーザ情報と事業者識別情報を制御装置１に送信する（ステップＳ３０）。なお、事業者識別情報は、ユーザが入力しても良いが、ステップＳ２０で入会用のウェブページを要求する際にパラメータとして制御装置に送信されても良い。また、当該ページの呼び出し元ページのＵＲＬからどの事業者のコンテンツサーバからかを判断しても良い。例えば、以下のように、server_a、tenant_bといったコンテンツサーバ２や事業者を示す情報をドメインのサーバ名やパス情報として組み込んでおき、これを抽出して事業者識別情報を特定しても良い。
ドメインのサーバ名: https://server_a.domain.co.jp/hoge/...
パス情報： https://wwww.domain.co.jp/tenantB/hoge/...
また入会用ウェブページのＵＲＬをテナント毎に異なるものを用意し、呼び出された入会用ウェブページがそれぞれの事業者識別情報を登録する構成でも良い。
そして制御装置１は、受信したユーザ情報と入金に伴う料金の支払いを確認するウェブページ（確認画面）をユーザ端末３へ送信して表示させる(ステップＳ３５)。なお、制御装置１は、入力されたメールアドレス等のユニークな情報をユーザ識別情報とするか、ユーザ毎に一意となる情報をユーザ識別情報として生成して、ユーザ情報に付加する。また、制御装置１は、入力された会員種別に応じた料金を料金記憶部９１から読み出して前記ウェブページ（確認画面）に反映させる。
確認画面において、確認ボタン等の選択肢（不図示）を選択する等して、ユーザが入力情報と支払いの情報を確認すると、ユーザ端末３は、確認した旨の情報を制御装置１へ送信する(ステップＳ４０)。
確認した旨の情報を受信した制御装置１は、ユーザ情報と料金に基づいて決済処理を行い（ステップＳ４５）、支払いが可能か否かを確認する（ステップＳ５０）。例えば、ユーザ端末３からクレジットカードの情報を受信し、ネットワークを介してカード会社のサーバ（不図示）にアクセスし、クレジットカードの情報と金額を通知してクレジットカードの利用を要求し、クレジットカードの利用がＯＫか否かを確認する。
クレジットカードの利用がＯＫ、即ち支払いが可であれば（ステップＳ５０、Ｙｅｓ）、制御装置１は、ユーザ情報をマルチテナントデータベースに登録する（ステップＳ５５）。なお、後払いの場合は、ユーザ情報ともに料金領収前であることを登録して、仮登録とし、支払いが確認できたときに料金領収済みであることを登録して本登録としても良い。
そして、制御装置１は、登録処理の結果、例えばステップＳ５５の登録が完了したこと、又はステップＳ４５の支払いが不可であった場合（ステップＳ５０、Ｎｏ）、その旨を記載したウェブページをユーザ端末３へ送信し(ステップＳ６０)、表示させる（ステップＳ６５）。
このように本実施形態１では、コンテンツサーバ２には、ユーザ登録の機能や決済の機能を備えなくてもユーザ端末３を制御装置１へ誘導するリンクを記載するだけでユーザ登録や決済を行えるようにしている。
なお、図１２において、ユーザを無料で登録する場合には、ステップＳ４５，Ｓ５０の処理を省略しても良い。例えば、入力フォームに入力された会員種別が、一般会員であった場合、ステップＳ４５，Ｓ５０を省略してユーザ情報を登録し（ステップＳ５５）、会員種別が、ゴールド会員やプラチナ会員であった場合には、ステップＳ４５，Ｓ５０で決済処理を行うようにしても良い。
なお、上記の例では、入会時の処理を示したが、コンテンツの購入についても同様の処理で行うことができる。例えばユーザがコンテンツ購入のため、コンテンツサーバ２にアクセスすると（ステップＳ１０）、コンテンツサーバ２は、制御装置１のコンテンツ購入用のウェブページに接続するためのリンクを掲載したウェブページをユーザ端末３へ送信して表示させる(ステップＳ１５)。
このリンクをユーザが選択すると、ユーザ端末３は、当該リンクの記述に従って制御装置１にＵＲＬを送信することで、コンテンツ購入用のウェブページを要求する（ステップＳ２０）。
制御装置１は、コンテンツ購入用のウェブページ（入力フォーム）をユーザ端末３へ送信して表示させる(ステップＳ２５)。
ユーザが入力フォームに購入のための情報、例えば購入するユーザのユーザ識別情報や、支払い方法、コンテンツ識別情報、利用期間を限定する場合には利用期間等を入力して送信を選択すると、ユーザ端末３は、入力された情報を制御装置１に送信する（ステップＳ３０）。なお、コンテンツ識別情報は、ユーザが入力しても良いが、前記リンクのＵＲＬのパラメータとして記述され、ステップＳ２０で制御装置１に送信されるものでも良い。なお、ユーザ識別情報は、事前のログイン処理時にWebブラウザのCookieなどの形式で
ユーザ端末３に保持され、自動的に送信されるようにしてもよい。
そして制御装置１は、受信した情報と入金に伴う料金の支払いを確認するウェブページ（確認画面）をユーザ端末３へ送信して表示させる(ステップＳ３５)。なお、制御装置１は、入力されたコンテンツ識別情報に応じた料金を料金記憶部９１から読み出して前記ウェブページ（確認画面）に反映させる。
確認画面において、確認ボタン等の選択肢（不図示）を選択する等して、ユーザが入力情報と支払いの情報を確認すると、ユーザ端末３は、確認した旨の情報を制御装置１へ送
信する(ステップＳ４０)。
確認した旨の情報を受信した制御装置１は、ユーザ情報と料金に基づいて決済処理を行い（ステップＳ４５）、支払いが可能か否かを確認する（ステップＳ５０）。ここで、支払いが可であれば（ステップＳ５０、Ｙｅｓ）、制御装置１は、購入したコンテンツのコンテンツ識別情報や、購入日、利用期間などの購入に係る情報をユーザ情報に追加するように、マルチテナントデータベースに登録する（ステップＳ５５）。なお、後払いの場合は、ユーザ情報ともに料金領収前であることを登録して、仮登録とし、支払いが確認できたときに料金領収済みであることを登録して本登録としても良い。
そして、制御装置１は、ステップＳ５５の登録が完了したこと、又はステップＳ４５の支払いが不可であったこと等を記載したウェブページをユーザ端末３へ送信し(ステップ
Ｓ６０)、表示させる（ステップＳ６５）。
図１３はコンテンツサーバ２が提供するウェブサイトのトップページの一例を示す図であり、図１２のステップＳ１５でコンテンツサーバ２が提供する入会用のウェブページに接続するためのリンクを掲載したウェブページの一例でもある。
図１３に示すようにウェブページ６１には、コンテンツを要求するリンク６２や、入会用のウェブページに接続するためのリンク６３、ログイン用のリンク６４が記載されている。例えばリンク６３は、htmlで以下のように記述される。
<a href="http://www.00000.com/entry/admi.html?gid=012345">会員登録</a>
このリンク６３の例では、http://www.00000.com/entry/admi.htmlが入会用のウェブページのＵＲＬであり、012345が事業者識別情報である。
図１４は入会用のウェブページの一例を示す図である。図１４に示すようにウェブページ６５には、ユーザの氏名や、ユーザ識別情報（図１４の例ではメールアドレス）、認証用のパスワード、会員種別の選択肢等のユーザ情報の入力欄６６が記載されている。ユーザが、これらの入力欄６６にユーザ情報を入力し、送信ボタン６７を選択すると、ユーザ端末３は入力されたユーザ情報を制御装置１へ送信し、登録させる。
＜ユーザの認証＞
図１５は、ユーザを認証する処理の一例を示す図である。先ず、図１３のウェブページ６１においてユーザがログイン用のリンク６４を選択すると、ユーザ端末３は、当該リンク６４の記述に従って制御装置１にＵＲＬを送信することで、ログイン用のウェブページを要求する（ステップＳ１１０）。
これに対して制御装置１は、ログイン用のウェブページ（入力フォーム）をユーザ端末３へ送信して表示させる(ステップＳ１１５)。ユーザが入力フォームにユーザ識別情報とパスワードといった認証情報を入力して送信を選択すると、ユーザ端末３は、入力された認証情報を制御装置１に送信する（ステップＳ１２０）。
この認証データを受信（ステップＳ１２３）した制御装置１は、受信した認証情報のユーザ識別情報と対応するユーザのユーザ情報としてマルチテナントデータベースに登録されているパスワードを読み出し(ステップＳ１２５)、受信したパスワードと登録されているパスワードとが一致するか否か、即ち認証情報が一致するか否かを判定する(ステップ
Ｓ１３０)。
受信したパスワードと登録されているパスワードとが一致した場合（ステップＳ１３０
、Ｙｅｓ）、制御装置１は、ユーザ識別情報をHTTP CookieやセッションＩＤとしてユー
ザ端末３に送信し（ステップＳ１３５）、記憶させる（ステップＳ１４０）。
一方、受信したパスワードと登録されているパスワードとが一致しなかった場合（ステップＳ１３０、Ｎｏ）、制御装置１は、エラーメッセージをユーザ端末３に送信して表示させ認証処理を終了する（ステップＳ１４５，Ｓ１５０）。
＜コンテンツ提供の制御＞
図１３に示すウェブページ６１は、記事の見出しを複数掲載しており、各記事の見出しがコンテンツを要求するリンク６２となっている。即ち、各記事の見出しを選択すると、コンテンツとして記事本文が提供される。図１６は、このコンテンツを提供する処理の一例を示す図である。
先ず、ユーザがコンテンツを要求するリンク６２（図１３）を選択すると、ユーザ端末３は、当該リンク６２の記述に従ってコンテンツサーバ２に記事本文のＵＲＬ、即ち要求するコンテンツのコンテンツ識別情報を送信する。また、ユーザ端末３は、ユーザ識別情報をHTTP CookieやセッションＩＤとしてコンテンツサーバ２へ送信する。このようにユ
ーザ端末３は、コンテンツ識別情報及びユーザ識別情報をコンテンツサーバ２へ送信することで、コンテンツの提供を要求する（ステップＳ２１０）。
コンテンツサーバ２は、このコンテンツの要求を受診すると（ステップＳ２１５）、当該要求のコンテンツ識別情報とユーザ識別情報に事業者ＩＤとシークレットキー（秘密鍵）を付加して問い合わせ情報とし、制御装置1に送信する（ステップＳ２２０）。シーク
レットキーは、コンテンツサーバ２の正当性を示すための情報であり、予めコンテンツサーバ及び制御装置１に登録される。
この問い合わせ情報をステップＳ２３０にて受信した制御装置１は、受信したシークレットキーと登録されているシークレットキーとを比較して、一致した場合に、問い合わせ情報の事業者ＩＤ及びユーザ識別情報と対応するユーザ情報をマルチテナントデータベースから抽出する（ステップＳ２３５）。なお、シークレットキーが一致しない場合には、正当な問い合わせではないため、ユーザ情報を抽出せずに処理を終了する。コンテンツサーバ２の正当性を判定は、シークレットキーの照合に限らず、電子証明書やコンテンツサーバ２のＩＰアドレスの照合によるものでも良い。
そして、制御装置１は、ステップＳ２３０で受信した問い合わせ情報のコンテンツ識別情報と対応する提供条件を読み出し、ステップＳ２３５で抽出したユーザ情報が提供条件を満たすか否かを判定する（ステップＳ２４０）。
この判定の結果、制御装置１は、ユーザ情報が提供条件を満たしていればコンテンツの提供を可とする制御情報を生成し、ユーザ情報が提供条件を満たしていなければコンテンツの提供を不可とする制御情報を生成し（ステップＳ２４５）、この制御情報をコンテンツサーバ２に送信する（ステップＳ２５０）。
この制御情報を受信したコンテンツサーバ２は、制御情報に基づいてコンテンツの提供の可否を判定する（ステップＳ２５５）。この制御情報がコンテンツの提供を可とするものである場合、コンテンツサーバ２は、ステップＳ２１５で要求されたコンテンツをユーザ端末３に提供（送信）する（ステップＳ２６０）。一方、制御装置１から受信した制御情報がコンテンツの提供を不可とするものである場合、コンテンツサーバ２は、コンテンツの提供が不可である旨を示すウェブページ（以下、提供不可ページとも称す）をユーザ端末３に提供（送信）する（ステップＳ２６５）。例えば、コンテンツサーバ２の制御情
報処理部２４は、制御情報がコンテンツの提供を不可とするものである場合、コンテンツ送信部２２がステップＳ２１５の要求に対するリクエストとして取得するコンテンツのＵＲＬを提供不可ページのＵＲＬに更新することで、提供不可ページをユーザ端末３に送信させる。即ち、ステップＳ２１５で要求されたコンテンツは提供（送信）しない。なお、制御情報がコンテンツの提供を不可とするものである場合、コンテンツサーバ２は、提供不可ページではなく、単にエラーステータス４０３や４０４などを送信しても良い。
ユーザ端末３は、コンテンツサーバ２からウェブページを受信して、表示などの出力を行う（ステップＳ２７０）。
図１７は、ユーザ端末３に提供されるコンテンツの一例を示す図である。図１７に示すように、ユーザ端末３に提供されるウェブページ７１には、記事に係る動画７２や本文７３が表示される。
図１８は、コンテンツの提供が不可である旨を示すウェブページの一例を示す図である。図１８に示すように、提供が不可の場合に送信されるウェブページ７４には、提供不可である旨のメッセージ７５や、会員登録のページへのリンク６３が表示される。
＜マルチテナントデータベースのデータ操作＞
図１２のステップＳ５５におけるユーザ情報の登録や、図１３のステップＳ２３５におけるユーザ情報の抽出について、以下に詳述する。
制御装置１の要求受付部１４は、コンテンツサーバ２からデータ操作に係る要求を受け付ける（図１９：Ｓ３０１）。要求は、例えば、論理テーブルに対してレコードの挿入、選択、更新、削除等を要求するクエリ（例えば、ＳＱＬ等の問合せ言語）として受け付ける。そして、要求受付部１４は、要求を変換部１５に伝送する。例えば、ユーザ端末３からユーザ情報の登録（挿入）や更新の要求を受けた場合や、コンテンツサーバ２からユーザ情報の問い合わせ（選択の要求）を受けた場合に、制御装置１の要求受付部１４がデータ操作の要求を生成する。
制御装置１の変換部１５は、メタデータ記憶部１２に記憶されているメタデータに基づいて、要求受付部１４から受けた要求を物理テーブル１１に対する要求に変換する（Ｓ３０２）。ここでは、図９に示したメタデータに基づき、クエリの内容を修正する。すなわち、レコード間の接続関係を示す情報である、物理テーブルのカラム「PageID」に保持された値に基づいて、１又は２以上のレコードを仮想的に１つのレコードとして扱う。具体的には、「TenantID」の値が要求元のテナントの識別情報と一致するレコードを操作の対象とする条件を付加する。また、操作対象のテーブルを物理テーブル１１に変更し、変換前の要求における操作対象の論理テーブルの指定を、カラム「TypeID」の値の指定に置き換える。さらに、変換前の要求におけるカラムの指定を、物理テーブル１１のカラム及び「PageID」の指定に置き換える。
例えば、テナントＣが検索を行うために次のようなクエリ１Ａを送信する例について説明する。
（クエリ１Ａ）
SELECT カスタマＩＤ，コンテンツ名, コンテンツ種別, ＵＲＬ, 価格, 発売日, 購入日 FROM 購入履歴 WHERE カスタマＩＤ=’1010999’;
この例は、論理テーブル「購入履歴」から「カスタマＩＤ」の値が「1010999」のレコ
ードを抽出し、「カスタマＩＤ」、「コンテンツ名」、「コンテンツ種別」、「ＵＲＬ」、「価格」、「発売日」及び「購入日」の各項目の値を表示させる要求である。そして、クエリ１Ａは、変換部１５によって、次のようなクエリ１Ｂに変換される。なお、物理テ
ーブル１１の物理名は「DataTable」であるものとする。
（クエリ１Ｂ）
SELECT p1.Num1, p1.Char1, p1.Char2, p2.Char1, p1.Num1, p1.Date1, p2.Date2
FROM DataTable p1 LEFT OUTER JOIN DataTable p2
ON p1.DataID=p2.DataID and p2.PageID=2
WHERE p1.Char2=’1010999’
AND p1.TenantID=’B’ AND p1.TypeID=’購入履歴’ AND p1.PageID=1;
この例では、「PageID」の値が１のレコードと「PageID」の値が２のレコードとを自己結合させいる。また、図９のメタデータに基づき、論理テーブルの「コンテンツ種別」は物理テーブル１１において「PageID」が１の「Char2」（すなわち、p1.Char2）に変換さ
れている。なお、データ操作部１０からは「PageID」が１のレコードと２のレコードとをそれぞれ取得し、変換部１５が仮想的な１つのレコードに結合するという構成にしてもよい。また、「PageID」の値が３以上のレコードがある場合、変換後のクエリにおいて３つ以上のレコードを自己結合させることも可能である。
次に、テナントＣがレコード数の計数を行うために次のようなクエリ２Ａを送信する例について説明する。
（クエリ２Ａ）
SELECT COUNT(*) FROM 購入履歴 WHERE コンテンツ種別=’語学’;
クエリ２Ａは、変換部１５によって、次のようなクエリ２Ｂに変換される。
（クエリ２Ｂ）
SELECT COUNT(*)
FROM DataTable p1 LEFT OUTER JOIN DataTable p2
ON p1.DataID=p2.DataID and p2.PageID=2
WHERE p1.Char2=’語学’
AND p1.TenantID=’B’ AND p1.TypeID=’購入履歴’ AND p1.PageID=1;
この例でも、「PageID」が２のレコードを自己結合させ、「PageID」が１のレコードを選択（SELECT）している。また、図９のメタデータに基づき、論理テーブルの「コンテンツ種別」は物理テーブル１１において「PageID」が１の「Char2」（すなわち、p1.Char2
）に変換されている。なお、データ操作部１０からは「PageID」が１のレコードと２のレコードとをそれぞれ取得し、変換部１５が仮想的な１つのレコードに結合して計数するという構成にしてもよい。
次に、テナントＣがレコードの挿入（INSERT）を行うために次のようなクエリ３Ａを送信する例について説明する。
（クエリ３Ａ）
INSERT INTO 購入履歴 VALUES(‘101999’,‘英会話’, ‘語学’, ‘/data/eng/lan.mpg’, 30000, 2014/06/06, 2014/07/29);
クエリ３Ａは、変換部１５によって、次のようなクエリ３Ｂ及びクエリ３Ｃに変換される。なお、要求を受け付けた時点において、物理テーブル１１には「DataID」が004のレ
コードまでが登録されている場合、新たに挿入されるレコードの「DataID」には005が採
番されるものとする。
（クエリ３Ｂ）
INSERT INTO DataTable(TenantID, TypeID, DataID, PageID, Char1, Char2, Num1, Num2, Date1)
VALUES(‘Ｂ’, ‘購入履歴’, 005, 1, ‘英会話’, ‘語学’, 30000, 2014/06/06);
（クエリ３Ｃ）
INSERT INTO DataTable(TenantID, TypeID, DataID, PageID, Char1, Date2)
VALUES(‘Ｂ’, ‘購入履歴’, 005, 2, ‘/data/eng/lan.mpg’, 2014/07/29);
レコードの挿入の場合、変換部１５はメタデータを参照し、論理テーブルにおける１レ
コードが物理テーブル１１における複数のレコードに対応付けられている場合、「PageID」ごとに挿入を行うクエリを生成する。上記の例では、「PageID」が「１」のレコード（第１のレコード）を挿入するクエリ３Ｂ、及び「PageID」が「２」のレコード（第２のレコード）を挿入するクエリ３Ｃが生成されている。
以上、メタデータにおいて論理テーブルのレコードが物理テーブル１１の複数のレコードに分解して対応付けられている場合のデータ操作の一例について説明した。テナントＡのレコードのように論理テーブルにおけるレコードが物理テーブル１１においても分解されずに登録されている場合は、「TenantID」及び「TypeID」の条件を追加し、カラム名の変換を行うが、「PageID」は「１」のみであり、結合や分解を行う必要はない。
また、レコードの更新については、要求に対し選択と同様の変換を行い、条件に該当するレコードを更新するクエリを生成する。レコードの削除については、例えば、条件に該当するレコードと「DataID」の値が同一のレコードを削除するクエリを生成する。
その後、制御装置１のデータ操作部１０は、物理テーブル１１に対しデータ操作を実行する（Ｓ３０３）。本ステップでは、データ操作部１０が物理テーブル１１に対し変換後のクエリを発行して挿入、選択、更新、削除等のデータ操作を行い、実行結果を変換部１５に出力する。以上のように、変換部１５及びデータ操作部１０は、受けた要求に応じて、「登録部」、「抽出部」、「更新部」、「削除部」等として機能する。また、データ操作処理のＳ３０２〜Ｓ３０４は、受けた要求に応じて、「登録ステップ」、「抽出ステップ」、「更新ステップ」、「削除ステップ」として働く。
次に、変換部１５は、メタデータ記憶部１２のメタデータに基づいて出力結果を変換し、結果応答部へ出力する（Ｓ３０４）。
そして、制御装置１の結果応答部１６は、ネットワークＮを介して要求元のコンテンツサーバ２に対して結果を送信する（Ｓ３０５）。なお、結果応答部１６は、制御装置１の図示していないアプリケーションに対して結果を渡すようにしてもよい。
＜設定処理＞
図２０は、メタデータ等の設定を行う設定処理の一例を示す処理フロー図である。上述したデータ操作処理の前に、図２０に示すような設定処理を行う。
制御装置１の設定部１３は、管理者端末４から要求を受け、メタデータ記憶部１２に論理テーブルのカラムと物理テーブル１１のカラムとの対応付けを設定する（図２０：Ｓ４１１）。本ステップでは、図９に示したようなメタデータが登録される。
本実施形態１では、物理テーブル１１に様々なデータ型のカラムを用意しておくことを特徴の１つとしている。このようにすれば、カラムのデータ型に応じて検索や集計等の機能を適用することができる。なお、論理テーブルのカラムに設定されるデータ型と物理テーブルのカラムに設定されるデータ型とは必ずしも１対１に対応していなくてもよい。例えば、図２１に示すようにカラム間のデータ型を設定するようにしてもよい。ここで、論理テーブルにおける「選択肢型」とは、予め定義された複数の選択肢の中からいずれかを指定することができるデータ型である。たとえば、優先度を示す項目に、あらかじめ定義された「最高」、「高」、「中」、「低」等の選択肢のいずれかを指定できるようにする。また、論理テーブルにおける「参照型」とは、別データへの参照を表現するデータ型である。また、論理テーブルにおける「バイナリデータ型」とは、ＢＬＯＢ型のようなバイナリデータを扱う型である。制御装置１内において、バイナリデータの格納手段（たとえば、ファイルシステムやクラウドサービス上のストレージサービスなど）を別途準備し、
物理テーブル内のカラムには格納手段へのポインタとなるＬｏｂＩＤを格納するようにしてもよい。そして、設定によって格納手段をＤＢ又はファイルシステム等に切り替え可能としてもよい。また、論理テーブルにおける「ロングテキスト型」とは、文字列型カラムのデータサイズの上限を超える文字列を格納可能とするデータ型である。例えば、ＣＬＯＢを利用し、バイナリデータ型と同様に切り替え可能としてもよい。
なお、物理テーブル１１のカラムは、すべて文字列型としてもよい。この場合、データ操作部１０は、数値や日付もすべて文字列として物理テーブル１１に格納する。そして、例えば集計のような処理は、制御装置１の図示していないアプリケーションが実行するようにする。予め物理テーブル１１に様々なデータ型のカラムをそれぞれ複数用意する場合、使用しないデータ型のカラムが増えてしまう可能性もあるところ、例えばカラムをすべて文字列型とすれば、物理テーブルのカラムを有効に利用可能となる。また、このような場合であっても、論理テーブルにおけるカラムをそれぞれ物理テーブルにおける独立したカラムに登録すれば、各カラムに対して検索のようなＤＢＭＳが提供する機能を利用できる。
また、上述の通り、データ型が同一であってデータサイズが異なる複数のカラムを設けてもよい。例えば、物理テーブル１１には、文字列型（最大長：２５６文字）のカラムと文字列型（最大長：２０００文字）のカラムとを設けておく。そして、例えば、論理テーブルの短文字列型のカラムを物理テーブル１１の文字列型（最大長：２５６文字）のカラムにマッピングし、論理テーブルの長文字列型のカラムを物理テーブル１１の文字列型（最大長：２０００文字）のカラムにマッピングする。物理テーブル１１にデータ型は同一であってデータサイズが異なる複数のカラムを設けておくことにより、ユーザは格納データに応じて十分な最大長のカラムを選択することができ、テーブルに保存されるデータ量を削減したり、データ処理時に使用するバッファメモリを節約することができる。
また、物理テーブル１１は、一部のカラムに予めインデックス（ＩＮＤＥＸ）を付与しておくようにしてもよい。インデックスは、データ操作部１０の機能を利用して付与することができる。この場合、Ｓ４１１においては、論理テーブルのカラムのうち多く検索に用いられることが想定されるカラムを、物理テーブル１１におけるインデックス付きのカラムにマッピングする。このようにすることで、図１２、図１３等に示したデータ操作処理において検索処理を高速化することができる。
なお、データ管理の方式によっては、ｎｕｌｌ値に対してもインデックスを付与し、データ領域を占有する場合がある。本実施形態１に係る物理テーブルの各カラムには必ずしも論理テーブルのカラムがマッピングされるとは限らないところ、このような方式の場合にインデックスを付与するのは好ましくない。このような場合は、図２２に示すようなインデックステーブルを別途設けるようにしてもよい。インデックステーブルは、例えば、データ型の種類に応じて、文字列型用のインデックステーブル、数値型用のインデックステーブル等を設ける。そして、メタデータにおいてインデックスの付与が設定されたカラムについてはインデックステーブルにカラムの値をコピーして（すなわち同期させて）検索に用いるようにする。
また、設定部１３は、コンテンツサーバ２から要求を受けた場合、メタデータ記憶部１２にテーブルスペースの設定をする（Ｓ４１２）。ここで、テーブルスペースとは、複数用意される物理テーブルの各々を指す概念である。複数のテーブルスペースを用意することで、いわゆるパーティショニングのように物理テーブルを分散させることができる。
図２３は、テーブルスペースを説明するための図である。図２３に示すように、メタデータにおいて、各論理テーブルがいずれのテーブルスペースを利用するのか対応付けを設
定する。また、物理テーブルはテーブルスペースの数だけ用意され、それぞれメタデータで対応付けられた論理テーブルのレコードが登録される。図２３の例では、「Default」
テーブルスペースに「DataTable_Default」という物理テーブルが対応付けられ、「TenantID」及び「TypeID」をキーとしてパーティショニングする。また、「DateBase」テーブ
ルスペースには「DataTable_DateBase」という物理テーブルが対応付けられ、「Date1」
及び「TenantID」をキーとしてパーティショニングする。
このような例において、「DateBase」テーブルスペースには、注文日等の項目を有し、レコードが日々増加するトランザクションデータを格納するものとする。一般的に物理テーブルのレコードが増加するほどレスポンスは低下していくところ、保持するレコード数の増加が見込まれる論理テーブルを物理テーブル上分けて管理することができる。
さらに、テーブルスペースの各々について、各データ型のカラム数に差をつけてもよい。例えば、文字の保存を優先するテーブルスペース（文字保存優先型）と、数値の保存を優先するテーブルスペース（数値保存優先型）を定義しておく。そして、文字保存優先型の物理テーブルには、例えば、文字列型のカラムを８０列、数値型のカラムを１０列、日付型のカラムを１０列設ける。また、数値保存優先型の物理テーブルには、例えば、文字列型のカラムを１０列、数値型のカラムを８０列、日付多型のカラムを１０列設ける。ユーザが論理テーブルを定義する際には格納するデータの見通しが立つため、適切なテーブルスペースを選択することが可能であり、テーブルに保存されるデータ量を削減したり、データ処理時に使用するバッファメモリを節約することができる。
以上のように、本実施形態１によれば、会員にのみコンテンツを提供するといったコンテンツ提供の制御を行うシステムを容易に実現できる。
特に、本実施形態１では、制御装置１が、会員情報の管理や、決済処理、コンテンツ提供の制御を行う機能を備えたことにより、既存のコンテンツサーバを大きく変更することなく、プラグインモジュールを提供するだけで、コンテンツ提供の制御を実現できる。
《実施形態２》
前述の実施形態１では、コンテンツサーバ２にプラグインモジュールを提供することで問い合わせ部２３及び制御情報処理部２４の機能を実現したが、これらの機能を制御装置に備え、プロキシサーバのようにコンテンツを提供する構成としても良い。即ち、前述の実施形態１では、プラグイン型でコンテンツの提供を制御する例を示したが、本実施形態２では、プロキシ型でコンテンツの提供を制御する構成とした。なお、その他の構成は、実施形態１と同じであるので同一の要素には同符号を付して再度の説明を省略している。
図２４は実施形態２のコンテンツ制御システムの概略構成を示す図である。図２４に示すように、本実施形態２の制御装置１は、ユーザ端末からの要求をコンテンツサーバ２へ中継し、コンテンツサーバ２から提供されるコンテンツをユーザ端末３へ中継するプロキシサーとして機能する。
本実施形態２における要求受付部１４は、ユーザ端末３からコンテンツの提供の要求を受信し、前記要求に基づいて、コンテンツを識別するコンテンツ識別情報、ユーザを識別するユーザ識別情報、及び要求されたコンテンツを提供するコンテンツサーバ２の事業者を識別する事業者識別情報を取得する。即ち、本実施形態２における要求受付部１４は、実施形態１の要求受付部１４がコンテンツサーバ２から問い合わせ情報を受信することに代えて、ユーザ端末３から直接コンテンツの提供の要求を受信する。
また、本実施形態２の要求受付部１４は、コンテンツ識別情報等、例えば要求されたコ
ンテンツを示すURLのドメインと事業者とを対応付けて記憶しておき、要求されたコンテ
ンツに基づいて事業者識別情報を特定する。
なお、ユーザ認証し、要求元のユーザ識別情報を特定する構成は前述の実施形態１と同じである。
また、本実施形態２における結果応答部１６は、判定部１７による判定の結果に基づいてコンテンツをコンテンツサーバ２から取得して要求元のユーザ端末３へ送信するコンテンツ送信部でもある。
図２５は本実施形態２におけるコンテンツの提供方法を示す図である。先ず、ユーザ端末３が、コンテンツサーバ２にアクセスすると（ステップＳ５１０）、コンテンツサーバ２は、図１３に示すようにコンテンツを提供するためのリンク６２を掲載したウェブページ６１をユーザ端末３へ送信する(ステップＳ５１５)。
ユーザ端末３が、コンテンツサーバ２からウェブページ６１を受信し、リンク６２をユーザが選択すると、ユーザ端末３は、当該リンクの記述に従って制御装置１にアクセスし、コンテンツ識別情報、ユーザ識別情報及び事業者識別情報を問い合わせ情報として送信することで、コンテンツの提供を要求する（ステップＳ５２０）。
制御装置１は、この問い合わせ情報を受診すると（ステップＳ５２５）、事業者識別情報及びユーザ識別情報と対応するユーザ情報をマルチテナントデータベースから抽出する（ステップＳ５３０）。
そして、制御装置１は、ステップＳ５２５で受信した問い合わせ情報のコンテンツ識別情報と対応する提供条件を読み出し、ステップＳ５３０で抽出したユーザ情報が提供条件を満たすか否かを判定する（ステップＳ５４０）。
この判定の結果、制御装置１は、ユーザ情報が提供条件を満たしていればコンテンツの提供を可とし、コンテンツサーバ２へコンテンツ識別情報と対応するコンテンツを要求する（ステップＳ５５０）。
このコンテンツの要求を受信したコンテンツサーバ２は、コンテンツ識別情報と対応するコンテンツを制御装置１へ送信し（ステップＳ５５５）、制御装置１は、このコンテンツをユーザ端末３へ送信する（ステップＳ５６０）。
一方、ステップＳ５４０でユーザ情報が提供条件を満たしていないと判定した場合には、コンテンツの提供が不可である旨を示すウェブページ（以下、提供不可ページとも称す）をユーザ端末３に提供（送信）する（ステップＳ５６０）。
ユーザ端末３は、制御装置１からウェブページを受信して、表示などの出力を行う（ステップＳ５６５）。
以上のように、本実施形態２おいても、前述の実施形態１と同様、会員にのみコンテンツを提供するといったコンテンツ提供の制御を行うシステムを容易に実現できる。
＜その他＞
本発明は、上述の例に限定されるものではなく、本発明の要旨を逸脱しない範囲において種々の変更を加え得るものである。
例えば、物理テーブル１１として、メインの物理テーブルと補助的な物理テーブルとを設けておくようにしてもよい。この場合、例えば、１ページ目（PageIDが１）のカラムをメインの物理テーブル（メインテーブル）に記憶させ、２ページ目以降（PageIDが２以上）のカラムを補助的な物理テーブル（補助テーブル）に記憶させる。このようにすれば、メインテーブルのレコードと論理テーブルのレコードとは１対１に対応づけられ、メインテーブルのカラム「DataID」に対してユニークインデックスを張ることができるようになる。また、例えば図２の変換部１５を介さずに、ユーザがＳＱＬ等で直接物理テーブル１１を参照するような場合、メインテーブルのレコード件数が論理テーブルにおけるレコード件数となるため、メンテナンス等が行い易くなる。
本発明のコンテンツ制御システム１００は、実施形態１と実施形態２の構成を併せ持ち、制御装置１が一部のコンテンツサーバ２に対してＳａａＳ型でコンテンツの制御を行い、また、他の一部のコンテンツサーバ２に対してプロキシ型でコンテンツの制御を行う構成でも良い。
１ マルチテナントシステム
１１ ＤＢＭＳ
１１１ 物理テーブル
１１２ データ操作部
１２ メタデータ記憶部
１３ 論理構造設定部
１４ 要求受付部
１５ 変換部
１６ 結果応答部
２ コンテンツサーバ
３ ユーザ端末

Claims (7)

  1. ユーザ端末に対してコンテンツを提供する複数のコンテンツサーバと、ネットワークを介して前記複数のコンテンツサーバと接続して前記コンテンツの提供を制御する制御装置とを有し、
    前記コンテンツサーバが、
    前記ユーザ端末からコンテンツの提供の要求を受信する要求受信部と、
    前記要求と対応するコンテンツを前記ユーザ端末へ送信するコンテンツ送信部と、
    前記ユーザ端末のユーザを識別するユーザ識別情報、及び前記コンテンツサーバを運営する事業者を識別する事業者識別情報を含む問い合わせ情報を前記制御装置へ送信する問い合わせ部と、
    前記制御装置から前記問い合わせの回答として制御情報を受信し、前記制御情報に基づいて前記コンテンツの提供が不可の場合には前記要求に対して前記コンテンツの送信を行わせない制御情報処理部と、
    を備え、
    前記制御装置が、
    前記コンテンツサーバから問い合わせ情報を受信する問い合わせ受信部と、
    前記事業者をテナントとして、複数のテナントで物理テーブルを共有し、前記テナント毎に定義される論理テーブルのカラムと前記物理テーブルのカラムとの対応付けを前記テナント毎に定義するマッピング情報に基づいて、前記事業者識別情報、前記ユーザ識別情報、及びユーザ情報を対応付けて記憶するマルチテナントデータベースから、前記マッピング情報に基づいて前記問い合わせ情報の前記事業者識別情報及び前記ユーザ識別情報と対応する前記ユーザ情報を抽出する抽出部と、
    前記ユーザ情報に基づく制御情報を問い合わせ元の前記コンテンツサーバへ送信する回答送信部と、
    を備えるコンテンツ制御システム。
  2. 前記問い合わせ部が、前記問い合わせ情報として、前記ユーザ識別情報及び前記事業者識別情報に加えて、要求する前記コンテンツを識別するコンテンツ識別情報を送信し、
    前記制御装置が、前記コンテンツ識別情報に応じたコンテンツの提供条件を前記ユーザ情報が満たすか否かを判定し、少なくとも当該判定の結果を前記制御情報とする判定部を更に備える請求項１に記載のコンテンツ制御システム。
  3. 前記制御装置が、前記マッピング情報に基づき、前記論理テーブルにおけるレコードを、前記物理テーブルにおける第１のレコード及び第２のレコードに分解し、当該第１のレコードと当該第２のレコードとの接続関係を示す情報を付与して登録する登録部を備え、
    前記抽出部が、前記マッピング情報及び前記接続関係を示す情報に基づき、前記第１のレコード及び前記第２のレコードを前記物理テーブルから読み出し、結合して出力する請求項１又は２に記載のコンテンツ制御システム。
  4. ユーザ端末に対してコンテンツを提供する複数のコンテンツサーバとネットワークを介して接続して、前記コンテンツサーバによる前記コンテンツの提供を制御する制御装置であって、
    前記ユーザ端末からコンテンツの提供の要求を受信したコンテンツサーバから、前記ユーザ端末のユーザを識別するユーザ識別情報、及び前記コンテンツサーバを運営する事業者を識別する事業者識別情報を含む問い合わせ情報を受信する問い合わせ受信部と、
    前記事業者をテナントとして、複数のテナントで物理テーブルを共有し、前記テナント毎に定義される論理テーブルのカラムと前記物理テーブルのカラムとの対応付けを前記テナント毎に定義するマッピング情報に基づいて、前記事業者識別情報、前記ユーザ識別情報、及びユーザ情報を対応付けて記憶するマルチテナントデータベースから、前記マッピング情報に基づいて前記問い合わせ情報の前記事業者識別情報及び前記ユーザ識別情報と対応する前記ユーザ情報を抽出する抽出部と、
    前記ユーザ情報に基づく制御情報を問い合わせ元の前記コンテンツサーバへ送信する回答送信部と、
    を備える制御装置。
  5. コンテンツを提供する複数のコンテンツサーバとネットワークを介して接続して、前記コンテンツサーバによる前記コンテンツの提供を制御する制御装置であって、
    ユーザ端末からコンテンツの提供の要求を受信し、前記要求に基づいて、前記コンテンツを識別するコンテンツ識別情報、前記ユーザ端末のユーザを識別するユーザ識別情報、及び要求された前記コンテンツを提供する前記コンテンツサーバの事業者を識別する事業者識別情報を取得する要求受信部と、
    前記事業者をテナントとして、複数のテナントで物理テーブルを共有し、前記テナント毎に定義される論理テーブルのカラムと前記物理テーブルのカラムとの対応付けを前記テナント毎に定義するマッピング情報に基づいて、前記事業者識別情報、前記ユーザ識別情報、及びユーザ情報を対応付けて記憶するマルチテナントデータベースから、前記マッピング情報に基づいて前記問い合わせ情報の前記事業者識別情報及び前記ユーザ識別情報と対応する前記ユーザ情報を抽出する抽出部と、
    前記ユーザ情報に基づいて前記コンテンツの提供の可否を判定する判定部と、
    前記判定の結果に基づいて前記コンテンツを前記コンテンツサーバから取得して要求元の前記ユーザ端末へ送信することで前記コンテンツの提供を中継するコンテンツ送信部と、
    を備える制御装置。
  6. ユーザ端末に対してコンテンツを提供する複数のコンテンツサーバと、ネットワークを介して前記複数のコンテンツサーバと接続して前記コンテンツの提供を制御する制御装置とが実行するコンテンツ制御方法であって、
    前記ユーザ端末及び前記制御装置との通信を行う通信インタフェースを備える前記コンテンツサーバが、
    前記ユーザ端末からコンテンツの提供の要求を前記通信インタフェースを介して受信するステップと、
    前記要求と対応するコンテンツを前記ユーザ端末へ前記通信インタフェースを介して送
    信するステップと、
    前記ユーザ端末のユーザを識別するユーザ識別情報、及び前記コンテンツサーバを運営する事業者を識別する事業者識別情報を含む問い合わせ情報を前記制御装置へ前記通信インタフェースを介して送信するステップと、
    前記制御装置から前記問い合わせの回答として制御情報を前記通信インタフェースを介して受信し、前記制御情報に基づいて前記コンテンツの提供が不可の場合には前記要求に対して前記コンテンツの送信を行わせないステップと、を実行し、
    前記ユーザ端末及び前記コンテンツサーバとの通信を行う通信インタフェースと、マルチテナントデータベースを構成する物理テーブルとして働く記憶装置とを備える前記制御装置が、
    前記コンテンツサーバから問い合わせ情報を前記通信インタフェースを介して受信するステップと、
    前記事業者をテナントとして、複数のテナントで物理テーブルを共有し、前記テナント毎に定義される論理テーブルのカラムと前記物理テーブルのカラムとの対応付けを前記テナント毎に定義するマッピング情報に基づいて、前記事業者識別情報、前記ユーザ識別情報、及びユーザ情報を対応付けて記憶するマルチテナントデータベースから、前記マッピング情報に基づいて前記問い合わせ情報の前記事業者識別情報及び前記ユーザ識別情報と対応する前記ユーザ情報を抽出するステップと、
    前記ユーザ情報に基づく制御情報を問い合わせ元の前記コンテンツサーバへ前記通信インタフェースを介して送信するステップと、
    を実行するコンテンツ制御方法。
  7. ユーザ端末に対してコンテンツを提供する複数のコンテンツサーバとネットワークを介して通信する通信インタフェースと、マルチテナントデータベースを構成する物理テーブルとして働く記憶装置とを備える制御装置が実行するコンテンツ制御プログラムであって、
    前記ユーザ端末からコンテンツの提供の要求を受信したコンテンツサーバから、前記ユーザ端末のユーザを識別するユーザ識別情報、及び前記コンテンツサーバを運営する事業者を識別する事業者識別情報を含む問い合わせ情報を前記通信インタフェースを介して受信するステップと、
    前記事業者をテナントとして、複数のテナントで物理テーブルを共有し、前記テナント毎に定義される論理テーブルのカラムと前記物理テーブルのカラムとの対応付けを前記テナント毎に定義するマッピング情報に基づいて、前記事業者識別情報、前記ユーザ識別情報、及びユーザ情報を対応付けて記憶するマルチテナントデータベースから、前記マッピング情報に基づいて前記問い合わせ情報の前記事業者識別情報及び前記ユーザ識別情報と対応する前記ユーザ情報を抽出するステップと、
    前記ユーザ情報に基づく制御情報を問い合わせ元の前記コンテンツサーバへ前記通信インタフェースを介して送信することにより、前記コンテンツサーバによる前記コンテンツの提供の可否を制御するステップと、
    を前記制御装置に実行させるためのコンテンツ制御プログラム。
JP2014066487A 2014-03-27 2014-03-27 コンテンツ制御システム Active JP6338909B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2014066487A JP6338909B2 (ja) 2014-03-27 2014-03-27 コンテンツ制御システム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2014066487A JP6338909B2 (ja) 2014-03-27 2014-03-27 コンテンツ制御システム

Publications (2)

Publication Number Publication Date
JP2015191305A JP2015191305A (ja) 2015-11-02
JP6338909B2 true JP6338909B2 (ja) 2018-06-06

Family

ID=54425775

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2014066487A Active JP6338909B2 (ja) 2014-03-27 2014-03-27 コンテンツ制御システム

Country Status (1)

Country Link
JP (1) JP6338909B2 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111581216A (zh) 2020-05-09 2020-08-25 北京百度网讯科技有限公司 数据处理方法、装置、设备以及存储介质

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4581219B2 (ja) * 1999-10-25 2010-11-17 ソニー株式会社 コンテンツ提供システム、コンテンツ配信方法、記憶媒体及びデータ処理装置
JP2002008115A (ja) * 2000-06-23 2002-01-11 Sony Corp 情報配信システム、端末装置、サーバ装置、記録媒体、情報配信方法
JP2002334227A (ja) * 2001-05-10 2002-11-22 Nippon Telegr & Teleph Corp <Ntt> 有料サービス提供方法、有料サービス提供システム、コンテンツサーバ、有料サービス提供用プログラム、および記録媒体
JP4672593B2 (ja) * 2006-05-02 2011-04-20 日本電信電話株式会社 Ｉｄ連携型認証システムおよびｉｄ連携型認証方法
JP4778500B2 (ja) * 2007-12-11 2011-09-21 株式会社日立情報システムズ データべースシステム及びデータべースシステムの制御方法
JPWO2011111532A1 (ja) * 2010-03-10 2013-06-27 日本電気株式会社 データベースシステム

Also Published As

Publication number Publication date
JP2015191305A (ja) 2015-11-02

Similar Documents

Publication Publication Date Title
US10796020B2 (en) Consent receipt management systems and related methods
US10678945B2 (en) Consent receipt management systems and related methods
US10685140B2 (en) Consent receipt management systems and related methods
US10592648B2 (en) Consent receipt management systems and related methods
US20190179490A1 (en) Consent receipt management systems and related methods
US20190180051A1 (en) Consent receipt management systems and related methods
US20110289420A1 (en) Screen customization supporting system, screen customization supporting method, and computer-readable recording medium
US8185546B2 (en) Enhanced control to users to populate a cache in a database system
US7124354B1 (en) Enterprise application transactions as shared active documents
US20140181137A1 (en) Presenting data in response to an incomplete query
US20110047146A1 (en) Systems, Methods, and Computer Program Product for Mobile Service Data Browser
US20210200899A1 (en) Data processing systems and methods for synching privacy-related user consent across multiple computing devices
US10165022B1 (en) Screen sharing management
JP2002117215A (ja) 特許管理システム
US20220156245A1 (en) System and method for managing custom fields
US10303668B2 (en) Automatic screen generation device, automatic screen generation program, and automatic screen generation method
JP6586050B2 (ja) 管理装置、管理方法および管理プログラム
JP6338909B2 (ja) コンテンツ制御システム
JP2009217529A (ja) ナレッジマネジメントシステム
CN112580065A (zh) 一种数据查询方法和装置
US20100057733A1 (en) Method, computer program product, and apparatus for enabling access to enterprise information
JP2009110241A (ja) 電子ファイル管理装置
JP2011186769A (ja) コンテンツ管理システム、コンテンツ管理装置、及びアクセス制御方法
CN116472694A (zh) 生成、保护和维护表情符号序列数字令牌的系统及方法
US20230035785A1 (en) Pagination processing and display of data sets

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20170217

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20171227

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20180123

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20180326

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: 20180410

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20180509

R150 Certificate of patent or registration of utility model

Ref document number: 6338909

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

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

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