JP2004500643A - System and method for providing an electronic license - Google Patents

Abstract

The present invention relates to a system and method for providing a license management system in which a customer uses a computer to connect to the license management system via a communication medium. The customer exchanges information with the license management system via a communication medium and copies various contents. Further, the customer exchanges information with the license management system via a communication medium to obtain a license for accessing the content. The license management system can be used for various types of content and allows the content owner to have full control over access to the content.

Description

ＡｃｔｉｖａｔｅｄＦｗｉｄｓテーブル
ユーザによるメディアセンターのすべての成功したインストレーションを登録する。各ユーザに活性化したフレームワークを割当てる。現在、ユーザと活性化したフレームワークの間には一対一の関係がある。この関係を変更して、一人のユーザが複数の活性化したフレームワークを持てるようにする計画がある。
フレームワークを活性化する前に、まずペンディングしなければならない。活性化する時、ＰｅｎｄｉｎｇＦｗｉｄｓテーブル中のフレームワークに関するすべての情報をＡｃｔｉｖａｔｅｄＦｗｉｄｓテーブルにコピーする。バックエンドは、この時、ユーザが誰で、どのフレームワークが使われるか分かる。
【表２】

フィールドの説明
ＴｉｍｅＳｔａｍｐ
フレームワークが活性化された日付と時間
ＦｒａｍｅｗｏｒｋＩｄ
フレームワークユニーク識別子（例：ｆｗｉｄ０００１．００００００１１０１）。現在、一ユーザアカウントＩｄに対応して一フレームワークである。ユーザアカウントＩｄに複数の活性化されたフレームワークＩｄを許容する計画がある。
ＣｅｌｌＩｄ
フレームワークＩｄセルをユニークに識別する文字ストリング。フレームワークＩｄセル、コントラクトセル、コンテントセルを含む各セルはユニークなＩｄを有する。
Ｅｍａｉｌ
メディアセンターをインストールした時にユーザが入力した電子メールアカウント。
ＲｅｑｕｅｓｔＩｄ
どのフレームワークから来たものかを検証する。さらにセキュリティーを高める（即ち、バックエンドが応答する場合、要求Ｉｄを活性化し送信するよう試みる。ハッカーを予防するために使う）。
ＵｓｅｒＨｏｓｔ
今は使用していない。
ＲｅｍｏｔｅＨｏｓｔ
今は使用していない。
Ａｕｔｈｅｎｔｉｃａｔｉｏｎ
ブール値。偽は電子メールアドレスが認証されていないことを表す。ユーザがバックエンドの確認電子メールを受信し、登録を完了すためにクリックしたことを示す。このプロセスは、ユーザが実際に電子メールを受信したことがバックエンドに分かるので、電子メールアドレスが正しいものであることを認証、または検証できる。
ＵｓｅｒＡｃｃｏｕｎｔＩｄ
ユーザと同じ。
ＶａｌｉｄＴｈｒｏｕｇｈ
フレームワークＩｄの有効期限（例：６ヶ月、１年等）
Ａｄｍｉｎｉｓｔｒａｔｏｒｓテーブル
管理業務を行う権限を有する特別なユーザのリストを含む。このリスト中のアドミニストレータはユーザとは何の関係もない。アドミニストレータは、ナレッジスターのデータを管理できる権限を有するメディアＤＮＡ社員及び発行者としてログインする。
【表３】

フィールドの説明
Ｎａｍｅ
アドミニストレータの名前またはログインアカウント。
Ｐａｓｓｗｏｒｄ
アドミニストレータアカウントにアクセスするためのパスワード。
Ｅｍａｉｌ
アドミニストレータの電子メールアドレス。アドミニストレータと電子的に通信可能である（例：レポート、統計の送信）。
Ｐｈｏｎｅ
アドミニストレータの電話番号。
ＰｕｂｌｉｓｈｅｒＩｄ
このアドミニストレータが管理する権限を持つ発行物。
Ｔｙｐｅ
このアドミニストレータのタイプを定義する。現在はレギュラーとスーパーの２タイプのみ。レギュラーアドミニストレータは指定された発行者とその発行物のみ取り扱える。スーパーアドミニストレータにはこの制限は無い。言い換えれば、スーパーアドミニストレータになるということは、ＰｕｂｌｉｓｈｅｒＩｄコラムを無効とすることである。このコラムで有効な値はＲとＳである。
ＭａｎａｇｅＣｏｒｐＡｃｃｏｕｎｔｓ
このアドミニストレータがコーポレートアカウントを管理する権限を有するかを示す。
ＭａｎａｇｅＰｒｏｍｏＥｍａｉｌ
このアドミニストレータが販促電子メールを管理する権限を有するかを示す。
ＡｒｔｉｃｌｅＳｙｎｃテーブル
ダイナミクスデータベース上でアップデートすべきＤＯＩ（アーティクル）の待ち行列を表す。ダイナミクスデータベース中のＤＯＩリストをナレッジスター上のＤＯＩリストと同期するためである。
【表４】

フィールドの説明
Ｄｏｉ
同期する必要があるアーティクルのＤｏｉ。
Ｏｐｅｒａｔｉｏｎ
データベース間でアーティクルを同期するには何をすべきかを説明する。
現在、作成と更新という二つのＯｐｅｒａｔｉｏｎが可能である。有効な値はＣとＵである。
Ｓｔａｔｕｓ
Ｏｐｅｒａｔｉｏｎの状態を記述する。未決定（Ｐｅｎｄｉｎｇ）、進行中、エラーの３つの値が定義されている。有効な値はＰ、Ｉ、Ｅである。
ＥｒｒｏｒＲｅａｓｏｎ
同期中にエラーが発生した場合、ＳｔａｔｕｓがＥに設定され、エラーメッセージがこのフィールドに入る。
ＢｉｌｌａｂｌｅＳｕｍｍａｒｉｅｓテーブル
特定のフレームワーク（ユーザ）によってなされたすべての取引の要約を、そのアカウントへの課金情報としてリストする。一つのエントリーはＢｉｌｌａｂｌｅＴｒａｎｓａｃｔｉｏｎｓテーブル中のたくさんの個別取引の合計である。
【表５】

フィールドの説明
ＴｒａｎｓａｃｔｉｏｎＩｄ
ユーザの一群の取引（一つまたは多数の）をユニークに識別する。
ＴｉｍｅＳｔａｍｐ
取引が発生した日付と時刻。
ＡｃｃｏｕｎｔＩｄ
取引を行ったユーザ。
ＦｉｒｓｔＮａｍｅ
ユーザのファーストネーム。
ＬａｓｔＮａｍｅ
ユーザのラストネーム。
Ｃｏｍｐａｎｙ
ユーザの勤務先。このフィールドは空欄でも良い。
Ｅｍａｉｌ
ユーザの電子メールアドレス。
ＡｃｃｏｕｎｔＳｔａｔｕｓ
ユーザアカウントの状態を定義する。ユーザアカウントには不活性（０）、ゲスト使用（１）、メンバー使用（２）、グループ使用（３）の状態がある。不使用（４）とすることもできる。
ＳｅｒｖｉｃｅＬｅｖｅｌ
将来、ユーザによって異なったレベルのサービスを提供するためのもの（例えば、ゴールド、シルバー、エリート等）。現在はゲストとメンバーという二つのレベルのみ。
ＮａｍｅＦｏｒＢｉｌｌｉｎｇ
このユーザに対する課金業務のための名前。
ＢｉｌｌｉｎｇＡｄｄｒｅｓｓ１
請求先住所フィールドＮｏ．１
ＢｉｌｌｉｎｇＡｄｄｒｅｓｓ２
請求先住所フィールドＮｏ．２
Ｃｉｔｙ
請求先住所（都市）。
Ｓｔａｔｅ
請求先住所（州）。
ＰｏｓｔａｌＣｏｄｅ
請求先郵便番号。
Ｃｏｕｎｔｒｙ
請求先住所（国）。
ＣａｒｄＴｙｐｅ
請求用クレジットカードタイプ（ビザ、マスター等）。
ＥｎｃｒｙｐｔｅｄＣａｒｄＮｕｍｂｅｒ
暗号化されたクレジットカード番号。セキュリティのために暗号化されている。
ＥｎｃｒｙｐｔｉｏｎＴｙｐｅ
クレジットカード番号を暗号化するのに使われた暗号タイプ。使えるのはＢａｓｉｃ（１）、ＲＳＡ（２）、ＳｉｍｐｌｅＨａｓｈ（３）である。
ＣａｒｄＥｘｐｉｒａｔｉｏｎＭｏｎｔｈ
クレジットカードの有効期限（月）。
ＣａｒｄＥｘｐｉｒａｔｉｏｎＹｅａｒ
クレジットカードの有効期限（年）。
ＣｏｕｎｔＯｆＴｒａｎｓａｃｔｉｏｎｓ
この要約書でグループ化された取引数。
Ａｍｏｕｎｔ
この要約書でグループ化された取引の金額。
Ｃｏｍｍｅｎｔ
一般的なコメントフィールド。ほとんど使わない。
ＢｉｌｌａｂｌｅＴｒａｎｓａｃｔｉｏｎｓテーブル
ナレッジスターで発生した課金可能な個々の取引をリストする。契約を発行するたびに取引が発生する。
【表６】

フィールドの説明。
ＴｒａｎｓａｃｔｉｏｎＩｄ
一ユーザの一群の取引の一部として取引を識別する。
ＴｉｍｅＳｔａｍｐ
このテーブルにエントリーされた日時。一般的には、ユーザが「支払い」ページにおいてクレジットカードへの課金を承諾した時である。
ＴｒａｎｓＴｉｍｅ
取引が発生した日時。ＴｉｍｅＳｔａｍｐに先立つ時間、日数、週数でも良い。一般的にはユーザが各ドキュメントを購入した時である。
Ｄｅｓｃｒｉｐｔｉｏｎ
何の取引かの記述。通常は購入されたアーティクルのタイトルを含み、または紹介文である。
Ｄｏｉ
取引されたアーティクル。
ＡｃｃｏｕｎｔＩｄ
取引したユーザ。
ＦｒａｍｅｗｏｒｋＩｄ
ユーザが使用するフレームワーク識別番号。
ＰｕｂｌｉｃａｔｉｏｎＩｄ
アーティクルが属する発行物。
ＴｒａｎｓＴｙｐｅ
番号によって識別される取引タイプ。有効なタイプは、使用中（０）、導入クレジット（１）、購入（２）、要約（３）である。
Ａｍｏｕｎｔ
取引金額。
Ｃｏｍｍｅｎｔ
取引に関するコメント。通常は空欄である。
ＣｌｉｃｋＴｈｒｏｕｇｈｓテーブル
ユーザが発行されたウェブサイトに行くのにナレッジスターをクリックするたびにトラッキングする。
【表７】

フィールドの説明。
ＴｉｍｅＳｔａｍｐ
クリックスルーされた日時。
ＦｒａｍｅｗｏｒｋＩｄ
クリックスルーしたフレームワーク。後でこのフレームワークを使っているユーザまでトラッキングする。
ＰｕｂｌｉｃａｔｉｏｎＣｏｄｅ
ユーザがクリックスルーし終わった発行物。
ＣｏｎｔｒａｃｔＳｔａｔｓテーブル
バックエンドをとめる時、エグジットする前に、バックエンドが取引数とそれに要した平均時間を記録する。この記録がこのテーブルに保管される。このテーブルはバックエンドスターデータベースの他のテーブルと直接関係は無い。デバッグ及びシステムモニタリングを依頼中である。
【表８】

フィールドの説明
ＴｉｍｅＳｔａｍｐ
バックエンドが実行を終了した日時。
ＮｕｍｂｅｒＣｏｎｔｒａｃｔｓ
バックエンドが前回初期化されてから今回終了されるまでに、バックエンドにより生成（発行）されたコントラクト数。
ＡｖｅｒａｇｅＴｉｍｅ
コントラクト生成に要した平均時間。この値は契約生成コードの性能をモニターするために使われる。
Ｃｏｍｍｅｎｔ
一般的なコメント。普通、バックエンドが実行終了したとのメッセージを表示する。
ＣｒｅｄｉｔＣａｒｄＮｕｍｂｅｒｓテーブル
各ユーザのクレジットカード番号を暗号化して保管する。クレジットカード番号を暗号化した暗号化のタイプも特定される。
【表９】

フィールドの説明
ＵｓｅｒＡｃｃｏｕｎｔＩｄ
このカードが使用可能なアカウントを特定する。
ＥｎｃｒｙｐｔｉｏｎＴｙｐｅ
クレジットカード番号を暗号化するのに使用した方法。使用できるのは、Ｂａｓｉｃ（１）、ＲＳＡ（２）、ＳｉｍｐｌｅＨａｓｈ（３）である。
ＥｎｃｒｙｐｔｅｄＣａｒｄＮｕｍｂｅｒ
暗号化されたクレジットカード番号。
ＣｕｒｒｅｎｔＴｒａｎｓａｃｔｉｏｎｓテーブル
取引に関連した情報を保存する。各契約についてＣｕｒｒｅｎｔＴｒａｎｓａｃｔｉｏｎｓテーブルにエントリーがなされる。エントリーは借方または貸方でも良いし、これらのエントリーを消去するものでも良い。ユーザがアーティクルを購入するたびに、ＩｓｓｕｅｄＣｏｎｔｒａｃｔエントリーとＣｕｒｒｅｎｔＴｒａｎｓａｃｔｉｏｎエントリーがなされる。
【表１０】

フィールドの説明
ＴｉｍｅＳｔａｍｐ
取引のなされた日時。
Ｄｅｓｃｒｉｐｔｉｏｎ
取引対象を説明する。通常、購入されたアーティクルのタイトルを含み、紹介クレジットに関する情報を含む（即ち、購入取引の場合、アーティクルの名称が入力される）。
Ｄｏｉ
取引されたアーティクルである。
ＡｃｃｏｕｎｔＩｄ
ユーザを特定する。
ＦｒａｍｅｗｏｒｋＩｄ
この取引を処理すべきフレームワークを特定する。
ＰｕｂｌｉｃａｔｉｏｎＩｄ
取引されたアーティクルの発行物を特定する。
ＴｒａｎｓＴｙｐｅ
数字で特定された取引タイプ。有効なタイプは未使用（０）、紹介クレジット（１）、購入（２）、要約（３）である。
Ａｍｏｕｎｔ
この取引の金額である。
Ｃｏｍｍｅｎｔ
一般的なコメントフィールド。
ＤＯＩｓテーブル
アーティクル関係の情報が入っている。アーティクルはＤＯＩとしても知られている。各ＤＯＩはナレッジスターで取り扱えるＤＯＩを表す。このテーブルはアーティクルの在庫であり、ユーザがアクセスするだろうすべてのアーティクル、すべてのコンテントセルなどを含む。このテーブルはネーミングサーブレットである。
【表１１】

フィールドの説明
ＴｉｍｅＳｔａｍｐ
ＤＯＩが登録された日時。
Ｔｉｔｌｅ
アーティクルのタイトル。
ＰｕｂｌｉｃａｔｉｏｎＩｄ
このＤＯＩが属する発行物の識別番号。
ＰｕｂｌｉｓｈｅｒＩｄ
このＤＯＩが属する発行者の識別番号。
Ｕｒｌ
アーティクルセルがあるアドレス（例：ｆｉｌｅ：／／／ｄ：￥ｄａｔａＤｉｒｅｃｔｏｒｙ￥ｃｅｌｌｓ￥ｃｏｍ．ｃａｄｃａｍｎｅｔ＿ｃａｄ＿０１８＿０１＿０１．ｍｄｎａ）
Ｐｒｉｃｅ
このアーティクルの価格。
ＶａｌｉｄＦｒｏｍ
このＤＯＩにアクセス可能となる最初の日を示す。アーティクルへのアクセスを制限する。
ＶａｌｉｄＴｈｒｏｕｇｈ
このＤＯＩにいつまでアクセスできるか示す。アーティクルへのアクセスを制限する。
ＣｏｎｔｅｎｔＣｅｌｌ
このＤＯＩで特定されたセルがコンテントセルかどうかを示す。値は真（１）または偽（０）である。
ＥｍａｉｌＨｉｓｔｏｒｙテーブル
特定のユーザに送信された電子メールをトラッキングする。電子メールがテンプレートユーザに送信された日付も記録される。
【表１２】

フィールドの説明
ＴｅｍｐｌａｔｅＩｄ
使用した電子メールテンプレート。ＥｍａｉｌＴｅｍｐｌａｔｅｓ．ＴｅｍｐｌａｔｅＩＤへの外部キー。
ＤａｔｅＳｅｎｔ
電子メールが送信された日付。
ＴｏＨｅａｄｅｒ
電子メールが送信された電子メールアカウント。ユーザはこのデータをカスタマープロファイルで変更できるので、実際に使用されたアドレスを記憶している。
ＵｓｅｒＡｃｃｏｕｎｔＩｄ
電子メールを受信するユーザ。Ｕｓｅｒｓ．ＡｃｃｏｕｎｔＩｄへの外部キーである。
ＥｍａｉｌＴｅｍｐｌａｔｅｓテーブル
このテーブルは、電子メールメッセージを生成するためにシステムが使用できるテンプレートの集まりを収容している。電子メールメッセージを生成するには、システムはデータベースのエントリーからＦｒｏｍＨｅａｄｅｒ、ＳｕｂｊｅｃｔＨｅａｄｅｒ、Ｂｏｄｙを取り、メッセージを組み立てるのに使用する。テンプレートは特定の発行者が保有するか、システムが保有する。
【表１３】

フィールドの説明
ＴｅｍｐｌａｔｅＩｄ
この番号によりテンプレートがユニークに特定される。
ＰｕｂｌｉｓｈｅｒＩｄ
このテンプレートを所有する発行者。この欄が０（ゼロ）の場合はシステムテンプレートであることを示す。
Ｎａｍｅ
このテンプレートの名前。この名前は、この発行者が所有するテンプレート中でユニークである。
ＣｒｅａｔｉｏｎＤａｔｅ
テンプレートが作成された日付。
ＳｕｂｊｅｃｔＨｅａｄｅｒ
このテンプレートで電子メールを送信する時のＳｕｂｊｅｃｔライン。
ＦｒｏｍＨｅａｄｅｒ
このテンプレートを使用して送信される電子メールのＦｒｏｍＨｅａｄｅｒを定義する。
Ｂｏｄｙ
このテンプレートを使った電子メールの内容。
ＥｒｒｏｒＬｏｇＤｏｉテーブル
Ｄｏｉ関係のエラーを記録する。エラーが発生した日付、エラーのタイプ、エラーが発行されたフレームワーク（ユーザ）、及び試みられたＤｏｉがこのログに含まれる。
【表１４】

フィールドの説明
ＴｉｍｅＳｔａｍｐ
エラーが記録された日付と時刻。
ＥｒｒｏｒＮｕｍｂｅｒ
エラーの内容を記述するエラー番号。頻度が高いＤｏｉエラーは、Ｄｏｉが見つからない（１０１）とＤｏｉが解決されていない（ｕｎｒｅｓｏｌｖｅｄ）（１０２）である。
Ｄｏｉ
このアーティクルに対するアクセスがエラーとなった。
ＦｒａｍｅｗｏｒｋＩｄ
失敗したアーティクルを要求しているフレームワーク。
ＲｅｍｏｔｅＡＤｄｒ
Ｄｏｉエラーが発行されたリモートＩＰアドレス。
ＲｅｍｏｔｅＨｏｓｔ
Ｄｏｉエラーが発行されたリモートホスト名。
ＥｒｒｏｒＬｏｇＦｗｉｄテーブル
ＦｒａｍｅｗｏｒｋＩｄ関連のエラーを記録する。エラーが発生した日付、エラーのタイプ、エラーが発行されたフレームワーク（ユーザ）、試みられたＤｏｉがこのログに含まれる。
【表１５】

フィールドの説明。
ＴｒａｎｓａｃｔｉｏｎＩｄ
エラーを特定するユニークな取引番号。
ＴｉｍｅＳｔａｍｐ
エラーが記録された日付と時刻。
ＥｒｒｏｒＮｕｍｂｅｒ
エラーを記述する番号。起こりえるエラーは、Ｆｗｉｄが無い（２００１）、フォーマットが良くない（２００２）、未登録（２００３）、アカウントが見つからない（２００４）、活性化されていない（２００５）、期限超過（２００６）である。
ＦｒａｍｅｗｏｒｋＩｄ
エラーに巻き込まれたフレームワーク。
Ｄｏｉ
エラーに巻き込まれたＤｏｉ。
ＲｅｍｏｔｅＡｄｄｒ
エラーに巻き込まれたユーザＩＰアドレス。
ＲｅｍｏｔｅＨｏｓｔ
エラーに巻き込まれたユーザホスト名。
ＥｘｔｒａＴｅｘｔ
一般的なコメント。
ＥｒｒｏｒＬｏｇＦｗｉｄＡｃｔｉｖａｔｉｏｎテーブル
ＦｒａｍｅｗｏｒｋＩｄの活性化に関するエラーを記録する。
【表１６】

フィールドの説明
ＴｉｍｅＳｔａｍｐ
エラーが記録された日付及び時刻。
ＦｒａｍｅｗｏｒｋＩｄ
エラーに巻き込まれたフレームワーク。
ＣｅｌｌＩｄ
エラーを経験したフレームワークのＩＤセルをユニークに特定する文字ストリング。
Ｅｘｐｉｒｅｓ
フレームワークのＩＤセルが期限切れとなる時間。
ＵｓｅｒＨｏｓｔ
このカラムはもう使用しない。
ＲｅｑｕｅｓｔＩｄ
要求番号。
ＲｅｍｏｔｅＡｄｄｒ
ユーザのＩＰアドレス。
ＲｅｍｏｔｅＨｏｓｔ
このカラムはもう使用しない。
ＦｒａｍｅｗｏｒｋＲｅｉｎｓｔａｌｌｓテーブル
ユーザがフレームワークをリインストールしようと試みた回数をカウントし、成功したリインストールに新しいフレームワーク識別番号を割当てる。
【表１７】

フィールドの説明
ＴｉｍｅＳｔａｍｐ
フレームワークのリインストールが記録された日付。
ＦｒａｍｅｗｏｒｋＩｄ
以前インストールされたフレームワーク。
ＩｎｓｔＦｗｉｄ
リインストールされたフレームワーク。
ＣｈａｉｎＬｅｎｇｔｈ
ユーザが試みたフレームワークのリインストールの数。回数が所定の制限に達したら、そのユーザはそれ以上のリインストールを許されない。
ＲｅｍｏｔｅＵｓｅｒ
このカラムはもう使われていない。
ＲｅｍｏｔｅＡｄｄｒ
フレームワークをリインストールしたユーザのＩＰアドレス。
ＲｅｍｏｔｅＨｏｓｔ
フレームワークをリインストールしたユーザのホスト名。
ＦｗｉｄＣｅｌｌｉｄＮｕｍｂｅｒＧｅｎｅｒａｔｏｒテーブル
ユニークなセル番号を生成するメカニズムである。セルＩＤ番号をトラッキングする。このテーブルはナレッジスターデータベースのバックエンドの他のテーブルとは直接的な関係を持たない。
【表１８】

フィールドの説明
ＮｅｘｔＣｅｌｌｉｄＮｕｍｂｅｒ
次のセルの識別番号をトラッキングする。
ＧｒｏｕｐＰｕｂｌｉｃａｔｉｏｎｓテーブル
ユーザグループメンバーによってアクセス可能な発行物を特定する。
【表１９】

フィールドの説明
ＧｒｏｕｐＩｄ
グループの識別番号。
ＰｕｂｌｉｃａｔｉｏｎＩｄ
発行物の識別番号。
Ｇｒｏｕｐｓテーブル
グループ関係の情報を保管する。コーポレートアカウントユーザをコーポレートアカウントとして一つのアカウントにまとめる。
【表２０】

フィールドの説明
ＧｒｏｕｐＩｄ
グループの識別番号。この番号はユニークである。
Ｎａｍｅ
グループの名前。
Ｐａｓｓｗｏｒｄ
このグループのアカウントにアクセスするパスワード。
Ｔｙｐｅ
有効なグループアカウントのタイプ。現在許されているグレープアカウントは、デモアカウントＤ、標準アカウントＳである。それぞれのグループアカウントフィーが支払われれば、デモアカウントのユーザは標準アカウントに昇格される。
ＵｓｅｒＴＴＬ
このグループのグループアカウントが有効な日数。
ＰｕｂｌｉｃａｔｉｏｎＩｄ
このグループのメンバーがアクセスできる発行物。
Ｅｘｐｉｒｅｓ
このグループアカウントの有効期限日。
ＧｒｏｕｐＵｓｅｒｓテーブル
ユーザをグループに結びつける。グループのメンバーを特定する。
【表２１】

フィールドの説明
ＧｒｏｕｐＩｄ
グループ識別番号。
ＵｓｅｒＡｃｃｏｕｎｔＩｄ
ユーザアカウントの識別番号。
Ｅｘｐｉｒｅｓ
このユーザに関するこのグループアカウントの有効期限日。
ＩｓｓｕｅｄＣｏｎｔｒａｃｔｓテーブル
特定のユーザがアーティクルを入手する時発行された各契約を記録する。フレームワークに契約ごとにエントリーされる（発行されたアーティクルごとに一つの契約）。これらのエントリーは永久に保存され、ユーザが同じアーティクルをダウンロードしても課金されないようにする。
【表２２】

フィールドの説明
ＴｒａｎｓａｃｔｉｏｎＩｄ
ユニークな番号であり、監査に使用するこの取引の識別子である。
ＴｉｍｅＳｔａｍｐ
この取引が登録された日時。
Ｄｏｉ
この契約がなされたアーティクルを示す。
ＣｏｎｔｒａｃｔＵｒｌ
契約セルがある場所を特定する（ディスクをきれいにするため、しばらくすると契約セルは破棄される）。
ＣｅｌｌＩｄ
契約セルをユニークに特定する文字ストリング。フレームワークＩＤセル、契約セル、コンテントセルを含め、各セルはユニークなＩＤを有する。
ＦｒａｍｅｗｏｒｋＩｄ
フレームワークＩＤはＤｏｉで特定されたセルにアクセスできる。
ＰｕｂｌｉｃａｔｉｏｎＩｄ
この契約のＤｏｉがどの発行物に属するか示す。
Ａｍｏｕｎｔ
ユーザが課金された金額。デバッグとトラッキングに使用される。
ＯｎｌｉｎｅＳｕｂｓｃｒｉｐｔｉｏｎＤｅｆｓテーブル
ナレッジスターが管理するオンライン購読に関する定義を含む。
【表２３】

フィールドの説明
Ｄｅｓｃｒｉｐｔｉｏｎ
オンライン購読の特徴を記述する。
ＰｕｂｌｉｃａｔｉｏｎＩｄ
オンライン購読をサポートする発行物。
Ｐｒｉｃｅ
この発行物をオンライン購読するための価格。
ＰｅｎｄｉｎｇＦｗｉｄｓテーブル
ペンディングとなっているすべてのフレームワークをリストする。ペンディングフレームワークは通常ゲストユーザに属する。ＰｅｎｄｉｎｇＦｗｉｄが活性化された時、そのエントリーはこのテーブルからＡｃｔｉｖａｔｅｄＦｗｉｄｓテーブルに「移動」する。
【表２４】

フィールドの説明
ＣｅｌｌＩｄ
フレームワークＩＤセルをユニークに定義する文字ストリング。フレームワークＩＤセル、コントラクトセル、コンテントセルを含め、セルごとにユニークなＩＤを有する。
ＦｒａｍｅｗｏｒｋＩｄ
ペンディングされたフレームワーク。
Ｅｍａｉｌ
ペンディングフレームワークを有するゲストユーザの電子メール。
ＶａｌｉｄＴｈｒｏｕｇｈ
このペンディングフレームワークが有効な期限日。
ＵｓｅｒＡｃｃｏｕｎｔＩｄ
このペンディングフレームワークを持つユーザアカウント。
ＰｒｏｍｏｔｉｏｎａｌＥｍａｉｌテーブル
バックエンドにある販促電子メールごとの特性と特徴を登録する。
【表２５】

フィールドの説明
ＰｕｂｌｉｃａｔｉｏｎＩｄ
この販促電子メールに関係する発行物。
ＴｅｍｐｌａｔｅＩｄ
この販促電子メールに使用されたテンプレート。
Ｅｎａｂｌｅｄ
この販促電子メールがイネーブルかどうかを示す。
ＥｎａｂｌｅＤａｔｅ
この販促電子メールがイネーブルされた日付。
Ｐｕｂｌｉｃａｔｉｏｎｓテーブル
ナレッジスター上の各発行物に関する情報を有する。一つの発行物が多数のアーティクル又はＤＯＩを含んでも良い。
【表２６】

フィールドの説明
ＰｕｂｌｉｃａｔｉｏｎＩｄ
各発行物のユニークな番号。内部的に発行物を特定する。
Ｓｔａｔｕｓ
発行物の状態は「ａｃｔｉｖｅ」又は「ｉｎａｃｔｉｖｅ」である。
ＰｕｂｌｉｃａｔｉｏｎＣｏｄｅ
発行物を特定する短いコード、通常は３文字のコードである（例：ｃｓｎ、ｏｌｒ、ｃａｄ）。
ＲｅｓｏｕｒｃｅＦｉｌｅ
この発行物があるファイルを示す（例：ｃ：￥ｂａｃｋ￥ｐｒｏｐｅｒｔｉｅｓ／ＡＴＣｏｎｔｅｎｔＣｅｌｌ．ｐｒｏｐｅｒｔｉｅｓ）。
ＰｕｂｌｉｓｈｅｒＩｄ
この発行物を所有する発行者。
Ｄｏｍａｉｎ
この発行物の発行者ドメイン（例：ｃｏｍ．ｇ２ｎｅｗｓ、ｃｏｍ．ｃａｄｃａｍｎｅｔなど）
Ｎａｍｅ
発行物の名称。
ＣｏｎｔｅｎｔＣｅｌｌＥｘｔｅｎｓｉｏｎ
この発行物のコンテントのセルフォーマット（例：ＭＤＮＡ、ＸＤＮＡ）
ＵｒｌＨｏｍｅＰａｇｅ
この発行物のウェブアドレス（例：ｈｔｔｐ：／／ｗｗｗ．ｇ２ｎｅｗｓ．ｃｏｍ／ｃｓｎｉｎｄｅｘ．ｈｔｍｌ）。
ＩｎｔｒｏＣｒｅｄｉｔ
この発行物からアーティクルにアクセスするユーザに提供される紹介クレジット。金額はＵＳドルである。
ＤｅｆａｕｌｔＰｒｉｃｅ
この発行物のアーティクルのデフォルト価格。金額はＵＳドルである。
ＦｒｅｅＡｒｔｉｃｌｅｓ
ユーザに提供される無料アーティクルの数。
ＰｅｒｍｉｔＰｒｉｎｔｉｎｇ
この発行物のアーティクルのプリントが許されているかどうかを示す。有効な値は真（１）又は偽（０）である。
ＰｅｒｍｉｔＣｏｐｙｉｎｇ
この発行物のアーティクルのコピーが許されているかどうかを示す。有効な値は真（１）又は偽（０）である。
Ｐｕｂｌｉｓｈｅｒｓテーブル
ナレッジスターにコンテントを有する各発行者からの情報を含む。一発行者は多数の発行物を有していても良い。
【表２７】

フィールドの説明
ＰｕｂｌｉｓｈｅｒＩｄ
発行者のユニークな識別番号。
Ｓｔａｔｕｓ
発行物の状態は「ａｃｔｉｖｅ」又は「ｉｎａｃｔｉｖｅ」である。
ＰｕｂｌｉｓｈｅｒＮａｍｅ
発行者の名称。
ＤｅｆａｕｌｔＰｒｉｃｅ
この発行物のアーティクルのデフォルト価格。金額はＵＳドルである。
ＴｒａｎｓａｃｔｉｏｎＮｕｍｂｅｒＧｅｎｅｒａｔｏｒテーブル
ユニークな取引ＩＤ番号が生成されるメカニズムである。ユニークな取引ＩＤ番号を保管する。このテーブルはナレッジスターデータベースのテーブルとは直接的な関係を持たない。
【表２８】

フィールドの説明
ＮｅｘｔＴｒａｎｓａｃｔｉｏｎＮｕｍｂｗｅｒ
次の取引番号を保管する。
ＵｓｅｒＢａｌａｎｃｅｓテーブル
ユーザのクレジット及び特定の発行物に対する課金の記録を保管する。ユーザがアクセスした発行物に関するエントリーがある。
【表２９】

フィールドの説明
ＵｓｅｒＡｃｃｏｕｎｔＩｄ
アーティクルにアクセスするユーザ。
ＰｕｂｌｉｃａｔｉｏｎＩｄ
アクセスされたアーティクルが属する発行物。
ＴｉｍｅＣｒｅｄｉｔＣｒｅａｔｅｄ
この発行物からのアーティクルについてこのユーザにクレジットされた日時。
ＡｖａｉｌａｂｌｅＣｒｅｄｉｔ
使用可能なクレジットの金額をＵＳドルで示す。
ＣｒｅｄｉｔＡｐｐｌｉｅｄ
適用されたクレジットの金額をＵＳドルで示す。
ＣｕｒｒｅｎｔＣｈａｒｇｅｓ
この発行物からのアーティクルについてこのユーザに課金されている金額をＵＳドルで示す。
ＨａｖｅＳｈｏｗｎＰｒｉｃｉｎｇＴｅｒｍｓ
ユーザがこの発行物のアーティクルの契約条件を見たかどうかを示す。有効な値は真（１）又は偽（０）である。
ＵｓｅｒＣｏｍｍｅｎｔｓテーブル
各ユーザのコメントを保管する。このテーブルはカスタマーサポートで使われる。
【表３０】

フィールドの説明
ＵｓｅｒＡｃｃｏｕｎｔＩｄ
コメントが登録されているユーザ。
ＴｉｍｅＳｔａｍｐ
コメントが登録された日時。
Ｃｏｍｍｅｎｔ
このユーザのコメント。
Ｕｓｅｒｓテーブル
ナレッジスターのユーザアカウントの情報を保管する。この情報は各ユーザについてアドレス、アカウント状態、クレジット、課金などを含む。ユーザごとにエントリーがある。ユーザがフレームワークＩＤ番号を必要とする事を何かすると、エントリーが作成されフレームワークＩＤ番号が送信される。
【表３１】

フィールドの説明
ＵｓｅｒＡｃｃｏｕｎｔＩｄ
各ユーザを識別する。
ＦｉｒｓｔＮａｍｅ
ユーザのファーストネーム。
ＬａｓｔＮａｍｅ
ユーザのラストネーム。
Ｃｏｍｐａｎｙ
ユーザの勤務先。空欄でも良い。
Ｅｍａｉｌ
ユーザの電子メールアドレス。
ＡｃｃｏｕｎｔＣｒｅａｔｉｏｎＤａｔｅ
このユーザアカウントが作成された日付。
ＡｃｃｏｕｎｔＳｔａｔｕｓ
ユーザアカウントの状態。ユーザアカウントはｉｎａｃｔｉｖｅ（０）、ゲスト（１）、メンバー（２）、又はグループメンバー（３）である。ディスエーブル（４）とすることも可能である。「ゲスト」はナレッジスターに完全には登録していないユーザである。「メンバー」は課金情報も含めて完全な情報を提供したユーザである。
ＣｕｒｒｅｎｔＣｈａｒｇｅｓ
このユーザアカウントへの課金をＵＳドルで表す。
ＣｕｒｒｅｎｔＣｒｅｄｉｔｓ
このユーザが使えるクレジットをＵＳドルで表す。
ＯｕｔｓｔａｎｄｉｎｇＬｉｍｉｔ
ユーザに支払いを督促する限度額。ユーザごとに設定できる。
ＳｅｒｖｉｃｅＬｅｖｅｌ
ユーザに様々なレベルのサービスを提供するために将来しようする（例：「ゴールド」、「シルバー」、「エリート」など）。現在は「ゲスト」と「メンバー」の２レベルある。
ＰｒｏｍｏｔｉｏｎａｌＥｍａｉｌ
ユーザが販促電子メールを欲しているかどうかを示す。有効な値は真（１）と偽（０）である。
ＲｅｍｏｔｅＵｓｅｒ
このカラムは使用していない。
ＲｅｍｏｔｅＡｄｄｒ
ユーザのＩＰアドレス。
ＲｅｍｏｔｅＨｏｓｔ
このカラムは使用していない。
ＮａｍｅＦｏｒＢｉｌｌｉｎｇ
請求先名。
ＢｉｌｌｉｎｇＡｄｄｒｅｓｓ１
ユーザの請求先アドレスＮｏ．１
ＢｉｌｌｉｎｇＡｄｄｒｅｓｓ２
ユーザの請求先アドレスＮｏ．２
Ｃｉｔｙ
ユーザの住所（都市名）。
Ｓｔａｔｅ
ユーザの住所（州名）。
ＰｏｓｔａｌＣｏｄｅ
ユーザの郵便番号。
Ｃｏｕｎｔｒｙ
ユーザの住所（国名）。
Ｐａｓｓｗｏｒｄ
ユーザのパスワード。
ＰａｓｓｗｏｒｄＥｎｃｒｙｐｔｉｏｎＴｙｐｅ
ユーザのパスワードを暗号化した暗号タイプ。使用可能なのはＢａｓｉｃ（１）、ＲＳＡ（２）、ＳｉｍｐｌｅＨａｓｈ（３）である。
ＣａｒｄＴｙｐｅ
クレジットカードのタイプ（例：Ｖｉｓａ、ＭａｓｔｅｒＣａｒｄ等）
ＣａｒｄＡｃｃｏｕｎｔＮｕｍｂｅｒ
表示しても安全なクレジットカード番号で、例えば「ｘｘｘｘｘｘｘｘｘｘｘｘ１２３４」。
ＣａｒｄＥｘｐｉｒａｔｉｏｎＭｏｎｔｈ
クレジットカードの有効期限が切れる月。
ＣａｒｄＥｘｐｉｒａｔｉｏｎＹｅａｒ
クレジットカードの有効期限が切れる年。
ＵｓｅｒＳｙｎｃテーブル
ダイナミクスデータベースでアップデートされるのを待つユーザのキュー。主な目的は、ダイナミクスデータベースのユーザリストをナレッジスターデータベースのユーザリストとシンクロナイズすることである。
【表３２】

フィールドの説明
ＵｓｅｒＡｃｃｏｕｎｔＩｄ
両方のデータベースをシンクロナイズするためのユーザアカウント。
Ｏｐｅｒａｔｉｏｎ
データベース間でアーティクルをシンクロナイズするために何をするかを記述する。現在、ＣｒｅａｔｅとＵｐｄａｔｅという二つの動作が許されている。有効な値はＣとＵである。
Ｓｔａｔｕｓ
Ｏｐｅｒａｔｉｏｎの状態を記述する。ペンディング、進行中、エラーという３つの値が定義されている。有効な値はＰ、Ｉ、Ｅである。
ＥｒｒｏｒＲｅａｓｏｎ
エラーが発生しＳｔａｔｕｓがＥとマークされると、エラーメッセージがここに表される。
【図面の簡単な説明】
【図１】
本発明の一実施形態のハイレベルのブロック図であり、ライセンス管理システムとユーザコンピュータの間の情報交換を示す。
【図２】
本発明の一実施形態のハイレベルのブロック図であり、コンテントマネージャ、オファーマネージャ、及びユーザコンピュータの間の情報の流れを示す。
【図３】
図２のユーザコンピュータの一実施形態のブロック図である。
【図４】
図２のコンテントマネージャの一実施形態のブロック図である。
【図５】
図２のオファーマネージャの一実施形態のブロック図である。
【図６ａ】
コンテントセルの一実施形態のブロック図である。
【図６ｂ】
コンテントセルの他の実施形態のブロック図である。
【図７ａ】
ライセンスセルの一実施形態のブロック図である。
【図７ｂ】
ライセンスセルの他の実施形態のブロック図である。
【図８】
ユーザにコンテントへのアクセスを提供する一実施形態のフローチャートである。
【図９】
コンテントを送信する一実施形態のフローチャートである。
【図１０】
ライセンスを要求する一実施形態のフローチャートである。
【図１１】
ライセンスを送信する一実施形態のフローチャートである。
【図１２】
コンテント及びライセンスをチェックする一実施形態のフローチャートである。
【図１３】
コンテントセルを生成する一実施形態のフローチャートである。
【図１４】
ライセンスセルを生成する一実施形態のフローチャートである。[0001]
[Field of the Invention]
The systems and methods relate to digital rights management.
[0002]
[Background of the Invention]
The growth of the Internet has increased the number of online consumers, as well as online companies that provide goods and services via the Internet. Accordingly, consumers are beginning to rely more on electronic transfer of information and expect instant access to information. While such ease of access is a great benefit for consumers, controlling consumer access is often a difficult task.
[0003]
One approach to controlling consumer access is to leverage digital rights management (DRM). DRM grants digital rights to information, thereby controlling user access and providing appropriate control to information owners. For example, DRM allows information owners to be paid for royalties, track use of information, issue licenses, etc.
[0004]
One common problem is that traditional approaches do not adequately control consumer access to information. Consumers find ways to avoid owner control. For example, assume that the owner has sent a password to the consumer to access the information. Once a consumer has access to the information, the consumer may copy the information and pass it on to others.
[0005]
Another common problem is that traditional approaches have failed to provide a digital rights management system that can be used for various types of information. For example, some digital rights management systems may work for music files, but may not be suitable for literary works.
[0006]
[Summary of the Invention]
The present invention provides a system and associated method for granting access to a data object.
[0007]
The present invention relates to a system and method for providing a license management system in which a customer uses a computer to connect to a license management system via a communication medium. The customer exchanges information with the license management system through a communication medium to obtain copies of the various content, and a content cell containing the requested content is created and transmitted to the customer. In addition, the customer exchanges information with the license management system over a communication medium to obtain a license to access the content, and a license cell containing the requested license is created and transmitted to the customer. Once the customer has obtained both the content cell and the associated license cell, access to the content is allowed as specified in the content cell and license cell conditions.
[0008]
A feature of the system and method is that the license management system has complete control over access to customer information. The license management system can embed the license associated with the customer and the access rights for the content in the content and / or license. Thus, the customer can access the content after the license conditions have been met. In addition, licensing rights allow the owner to control various types of access to the content. For example, a customer can view the content but cannot print the content.
[0009]
Another feature of the system and method is that the license management system can be used for a variety of different types of information. Since a wide range of content is created as a content cell and a license corresponding to the content cell is created, a license can be created for any content cell. For example, customers can access a variety of content, such as audio files, executable files, text files, and the like.
[0010]
Another benefit of this embodiment is that the customer can receive and access the content without significant delay, as the license management system is readily accessible through the communication medium. The license management system allows the user to get a quick response to the request.
[0011]
For purposes of summarizing the invention, certain aspects, features, and novel features of the invention have been described herein. Not all of these features can be realized in a particular embodiment of the present invention. Thus, for example, as will be appreciated by one skilled in the art, the invention may be practiced to achieve one or more features taught herein, but not necessarily other features taught or implied herein. It does not realize.
[0012]
[Embodiment of the invention]
These and other features will be described with reference to the drawings. These drawings and accompanying descriptions are intended to illustrate embodiments of the present invention and not to limit the scope of the invention.
[0013]
Throughout the drawings, reference numbers are re-used to indicate correspondence between referenced elements. Further, the first digit of each reference number identifies the drawing in which the element first appears.
[0014]
This application is incorporated by reference into U.S. Pat. No. 5,845,281 to Benson et al.
[0015]
The present invention relates to systems and methods for providing a license management system 120. FIG. 1 illustrates one embodiment, in which a customer 110 uses a user computer 115 to connect to a license management system 120 via a communication medium 130. In the illustrated system, the license management system 120 consists of two main components: an offer manager 122 and a content manager 124. The customer 110 exchanges information with the content manager 124 via the communication medium 130 to obtain various copies of the content. Content includes audio files, video files, text documents, emails, database records, hypertext markup language (HTML) files, extensible markup language (XML) files, electronic data interchange (EDI) files, message-oriented middleware (MOM) ) Including files, executable scripts, etc. In addition, the customer 110 exchanges information with the offer manager 122 via the communication medium 130 and obtains a license to access the content.
[0016]
I.Overview
An overview of one embodiment of the license management system 120 is shown in FIG. In the illustrated system, the user computer 115 communicates with the offer manager 122 and the contact manager 124 via a communication medium 130. In the embodiment illustrated in FIG. 2, the offer manager 122 and the content manager 124 of the license management system 120 are implemented as separate components connected to a communication medium 130. In other embodiments, offer manager 122 and content manager 124 may be part of a single, directly connected system.
[0017]
FIG. 2 illustrates the flow of information when a customer 110 (FIG. 1) wants to access content. For Event A, user computer 115 requests content, and the request is sent to content manager 124. At Event B, the content manager 124 sends a content cell 210 containing the requested content to the user computer 115. Next, at event C, the user computer 115 requests a license, and the request is sent to the offer manager 122. At Event D, offer manager 122 sends a license cell 220 containing the requested license to user computer 115. At events E and F, user computer 115 verifies that it has both a content cell 210 and a corresponding license cell 220, and user computer 115 grants access to the content.
[0018]
An advantage of this embodiment is that the user computer 115 receives the content and can access the content without significant delay, because the license management system 120 is immediately accessible through the communication medium 130. The license management system 120 allows the user to receive a response to the request in a timely manner.
[0019]
Another advantage of this embodiment is that the license management system 120 manages the use of content on the user computer 115 by license. The license management system 120 can incorporate license rights associated with the user computer 115 and access rights related to the content in the content cell 210 and / or the license cell 220.
[0020]
II.Implementation of license management system
This section further describes one embodiment of a system for providing an electronic license as shown in FIG. The illustrated system includes a communication medium 130, a user computer 115, and a license management system 120.
[0021]
A.Communication media
With respect to the communication medium 130 shown in FIG. 2, the currently preferred communication medium 130 includes the Internet, which is a global network of computers. The structure of the Internet, as is well known to those skilled in the art, includes a network backbone and a network branched from the backbone. These branches have more branched networks. Routers exchange information packets at the network level and send them from network to network until the packet reaches the vicinity of the destination. From the destination, a host on the destination network sends the information packet to the appropriate terminal or node. For a more detailed description of the structure and operation of the Internet, see "The Internet Complete Reference" by Harley Hahn and Rick Stout (McGraw-Hill, 1994).
[0022]
It is well known that in one advantageous embodiment, the Internet routing hub comprises a Domain Name System (DNS) server. DNS is a Transfer Control Protocol / Internet Protocol (TCP / IP) service that is invoked when translating a domain name to an Internet Protocol (IP) address or from an Internet Protocol (IP) address to a domain name. Routing hubs connect to other routing hubs through high-speed communication links.
[0023]
However, one skilled in the art will recognize that a wide range of interactive communication media 130 can be used with the present invention. For example, communication media 130 includes an interactive television network, a telephone network, a wireless data transmission system, a two-way cable system, a customized computer network, an interactive kiosk network, an automated teller machine network, and the like.
[0024]
The most commonly used on the Internet is the World Wide Web. The World Wide Web includes different computers that store documents that can display graphics and text information. Computers that provide information on the World Wide Web are commonly referred to as "websites." Websites are designated by Internet addresses, which are accompanied by electronic pages. The electronic page is identified by a uniform research locator (URL). Generally, an electronic page is a document that integrates the display of text, graphical images, audio, video, and the like.
[0025]
B.User computer
The user computer 115, shown in FIG. 3, is a device by which a user exchanges information with the communication medium 130 (FIG. 1). In one embodiment, user computer 115 is a conventional general-purpose computer, and includes one or more microprocessors, such as a Pentium® processor, a Pentium® II processor, a Pentium® Pro processor, an xx86 processor. , 8051 processor, MIPS processor, Power PC processor, and Alpha processor. In one embodiment, the user computer 115 is a suitable operating system, for example, Microsoft® Windows®. X, Microsoft (registered trademark) Windows (registered trademark) 98, Microsoft (registered trademark) Windows (registered trademark) NT, Microsoft (registered trademark) Windows (registered trademark) CE, Palm Pilot OS, Apple (registered trademark) Mac (registered trademark) Trademark), Disk Operating System (DOS), UNIX (registered trademark), Linux (registered trademark), or IBM (registered trademark) OS / 2 (registered trademark). In one embodiment, the user computer 115 has a conventional modem or other network connection function such as Ethernet (IEEE 802.3), Token Ring (IEEE 802.5), Fiber Distributed Data Link Interface (FDDI), It has an asynchronous transfer mode (ATM). As is conventional, in one embodiment, the operating system includes a TCP / IP stack that handles all message traffic coming and going through the communication medium 130.
[0026]
In other embodiments, the user computer 115 may be, for example, a computer workstation, a local area network of separate computers, an interactive television, an interactive kiosk, a personal digital assistant, an interactive wireless communication device, a handheld computer, a telephone, a router, a satellite, a smart card. Any device that can exchange information with the communication medium 130, such as a built-in computing device, may be used. In such a system, the operating system is different, but provides the appropriate communication protocol necessary to establish a communication link with communication medium 130.
[0027]
The illustrated user computer 115 includes a browser module 310, a user manager 320, and a database collection 330.
[0028]
1. Browser module
In one embodiment, user computer 115 utilizes a plurality of operational modules, including user browser module 310. User browser module 310 (hereinafter referred to as user browser 310) is a software program that allows consumers to access different content providers through communication medium 130 (FIG. 1). In one embodiment, the user browser 310 is a Netscape® Navigator developed by Netscape or Microsoft® Internet Explorer developed by Microsoft. However, those skilled in the art will recognize that many other types of access software can implement embodiments of the present invention. Other types of access software may be, for example, other types of Internet browsers, custom network browsers, two-way communication software, cable modem software, point-to-point software, and the like.
[0029]
2. User Manager
In one embodiment, user computer 115 includes user manager 320. User manager 320 keeps track of all content and licenses received by user computer 115. In one embodiment, the user manager 320 is loaded on the user computer 115 through a web-based download process. In a web-based download process, the user browser 310 can ask the user to download the user manager 320. If the user answers YES, the download process checks whether the user manager 320 supports the user browser 310. If so, the user browser 310 automatically downloads the user manager 320 onto the user computer. In other embodiments, the download process of the user manager may be performed without user intervention, or the user manager 320 may be pre-installed on the user computer 115.
[0030]
3. Database collection
In one embodiment, user computer 115 includes database collection 330 shown in FIG. The illustrated database collection 330 includes multiple databases, for example, a license database 332, a content database 334, an encryption key database 336, and the encryption key database 336 can include one or more encryption keys.
[0031]
The license database 332 includes information on the license cell 220 received by the user computer 115. The information can include a copy of the license cell 220 as received, or decompressed information, such as license terms, license cell header information, and the like.
[0032]
Content database 334 contains information about content cells 210 received by user computer 115. The information can include a copy of the content cell 210 as received, or decompressed information, such as encrypted content, content cell header information, and the like.
[0033]
The encryption key database 336 contains the key received through the license cell 220, which key is used by the user manager 320 to decrypt the encrypted content. In one embodiment, a symmetric key cipher is used, but in other embodiments, other cryptographic methods can be used separately or in conjunction with the symmetric cipher.
[0034]
In one embodiment, the database collection 330 can be implemented using a flat file database structure. In another embodiment, the database collection 330 can be implemented using other databases, for example, using Microsoft® SQL Server, a relational database that can access data using Structured Query Language (SQL). it can. Further, while the data collection 330 shown in FIG. 3 comprises a plurality of separate databases, in other embodiments, the database collection 330 may include other databases or may combine other databases. . In addition, database collection 330 may be implemented as a single database having a plurality of individual tables, or may be implemented as another well-known data structure, such as a linked list, binary tree, or the like.
[0035]
C. License management system
In one embodiment, license management system 120 (FIG. 1) manages the generation and issuance of content and licenses. In another embodiment, license management system 120 primarily manages the issuance of content cells 210 and license cells 220, and a separate module may generate license cells 220 and / or content cells 210. As described above, the license management system 120 is composed of two main components, a content manager 124 and an offer manager 122. However, in other embodiments, there may be multiple content managers 124 and / or multiple offer managers 122.
[0036]
1. Content Manager
FIG. 4 illustrates one embodiment of the content manager 124. The illustrated content manager 124 includes web server software 410, a content manager component 420, and a database collection 430.
[0037]
a. Web server software
In one embodiment, content manager 124 includes web server software 410 as shown in FIG. The web server software 410 may be, for example, Netscape's Internet server software, Microsoft's Internet server software (ISS), or the like. Such web server software 410 is configured to process messages from user computer 115 and offer manager 122, as shown in FIG.
[0038]
b. Content Manager component
In one embodiment, content manager 124 includes a content manager component 420 that manages the creation and publication of content cells 210. The content manager component 420 shown in FIG. 4 comprises two processes, a user manager download process 422 and a content cell generation process 424. The content manager component 420 may include other processes not shown, for example, a process for registering and managing users, a process for tracking an inventory of content cells, and a process for providing a search engine.
[0039]
The user manager download process 422 downloads the user manager 320 to the user computer 115. In another embodiment, the user manager download process 422 may be performed in another module, or the user manager 320 may be pre-installed on the user computer 115. Content cell generation process 424 is invoked when user computer 115 requests content and process 424 generates content cell 210 for the requested content. In this embodiment, the content manager 124 includes a content generation process 424, but in other embodiments, another module may generate the content cell 210, and the content manager 124 generates the content cell 210. By locating the content cell 210, the issuance of the content cell 210 may be mainly managed.
[0040]
c. Database collection
In one embodiment, content manager 124 includes database collection 430 shown in FIG. The illustrated database collection 430 includes a plurality of databases, for example, a contract database 432, an encryption key database 434 (the encryption key database includes one or more symmetric keys), a public certificate database 436, a content database 438, and a cell. A header information database 439 is included.
[0041]
The rules database 432 contains rules regarding how and when to assign rights to content. The rules may be general (eg, content X requires license Y) or more specific (eg, anyone with license Y can print content X. Print content X Needs a license Y, otherwise jumps to URL C.). Although FIG. 4 shows the conventions stored in the conventions database 432, in other embodiments the conventions may be stored in other formats, for example, stored in a program or a set of script formats. Is also good.
[0042]
The encryption key database 434 contains a set of symmetric keys, and the content manager 124 uses the set of symmetric keys to decrypt the requested content. The symmetric key can be generated using a known technique. For a more detailed description of symmetric and asymmetric encryption, see Bruce Schneier, "Applied Cryptography: Protocols, Algorithms, and Source Code in C, Second Edition" (John Wiley, 1996). Although this embodiment uses a symmetric cipher, in other embodiments, other cryptographic methods may be used separately from or in conjunction with the symmetric cipher.
[0043]
The public certificate database 436 contains public certificates from other components with which the content manager 124 communicates. The component's public encryption key is in the component's public certificate. For example, the public certificate database 436 includes the public certificate of the offer manager 122 (including the public encryption key of the offer manager 122) to encrypt and authenticate when the content manager 124 and the offer manager 122 communicate. Is also good. The public certificate database 436 may include the public certificate of the user computer 115 that requested the content.
[0044]
The content database 438 contains various content itself and information about the content. Content can be audio files, text documents, e-mails, database records, hypertext markup language (HTML) files, extensible markup language (XML) files, electronic data interchange (EDI) files, message-oriented middleware (MOM) files , An executable script or the like. Content database 438 may include an issuer table, issue table, article table, and the like.
[0045]
The issuer table stores information about the issuer. The issuer table may include fields such as issuer ID, status (indicating whether the issuer is active), issuer name, default price, and the like. Each issuer can issue one or more issues.
[0046]
The issue table stores information about issues. The issue table contains issue ID, status (indicates whether the issue is active or not), issue code, attributes, issuer ID, domain, issue name, issue file type, issue web address, introduction It may include fields such as credits, default price, number of free articles, print fields (indicating whether printing is possible), copy fields (indicating whether copying is possible), and the like. Each publication contains one or more articles.
[0047]
The article table stores information about articles (one by one). The term "article" is used, but the term "article" is used to refer to audio files, video files, text documents, e-mail, database records, hypertext markup language (HTML) files, extensible markup languages ( It is recognized that the content may include XML (XML) files, electronic data interchange (EDI) files, message-oriented middleware (MOM) files, executable scripts, and the like. The article table may include fields such as title, time stamp, issue ID, issuer ID, price, validity period, cell type, and the like.
[0048]
The content database 438 may include other tables related to the content, such as an application table and an administrator table. The application table defines various applications and includes fields such as a description field, an application ID, and a price. The administrator table stores special accounts having the authority to perform management tasks, such as price, end date, and group settings. The administrator table may include fields for name, password, e-mail address, telephone number, issuer ID, administrator level, group account management permission, promotion management permission, and the like.
[0049]
The cell header information database 439 includes information on the cell header. This information may include an identifier unique to each content cell 210, information about the various shops that make the content, descriptive information, and authentication information (eg, expiration date / time).
[0050]
Regarding the database collection 430, in one embodiment, there may be multiple processes (not shown) such as an ID generator, a number generator, a statistics generator, a session generator, a temporary storage unit, etc., that work with the database collection 430.
[0051]
In one embodiment, the database collection 430 is implemented using a Microsoft SQL server, a relational database that can access data through Structured Query Language (SQL). SQL is a language standardized by the International Standards Organization (ISO) for defining, updating, and querying relational databases.
[0052]
In another embodiment, database collection 430 may be implemented using another relational database or may use another type of database (eg, a flat file database, etc.). Further, while the database collection 430 shown in FIG. 4 is comprised of a plurality of individual databases, in other embodiments, the database collection 430 may include another database or may have several databases combined. good. The database collection 430 may be implemented as a single database having individual tables, or may be implemented as another well-known data structure such as a linked list or a binary tree.
[0053]
In one embodiment, the database collection 430 is connected to a back-end component (not shown) that receives database requests through servlets (small programs running on the server) and sends corresponding SQL requests to the database 430. May be. In other embodiments, the manner in which the data is accessed may be different, for example, using different types of back-end components or accessing the database collection 430 directly.
[0054]
A more detailed description of an embodiment of the database collection 430 is provided in Appendix A attached. Appendix A database collection 430 illustrates license management system 120, with content manager 124 and offer manager 122 both accessing the same database collection, but in another embodiment, content manager 124 and offer manager 122. May have separate copies of various databases.
[0055]
2. Offer manager
FIG. 5 illustrates one embodiment of the offer manager 122. The illustrated offer manager 122 includes web server software 510, an offer manager component 520, a license manager 530, and a database collection 540.
[0056]
a. Web server software
In one embodiment, offer manager 122 includes web server software 510 as shown in FIG. The web server software 510 may be, for example, Netscape Internet server software or Microsoft Internet server software (ISS). Such web server software 510 is configured to process messages from user computer 115 and content manager 124.
[0057]
b. Offer Manager component
In one embodiment, as shown in FIG. 5, offer manager 122 includes an offer manager component 520 that manages the issuance of license cells 220. The offer manager component 520 manages information exchange with the user, determines whether the user request has been satisfied before the license manager 530 is called, tracks payments, determines whether a license has been issued, and other processes (not shown). ) May be included.
[0058]
c. License Manager component
In one embodiment, offer manager 122 includes a license manager 530 that manages the generation of license cells 220. The license manager 530 shown in FIG. 5 includes a license cell generation process 532. The license cell generation process 532 may be invoked after the user computer 115 requests a license for the content cell 210. The license cell generation process 532 generates a license cell 220 for the requested content. In this embodiment, the license manager 530 includes the content generation process 424, but in other embodiments, another module may generate the license cell 220.
[0059]
For example, offer manager 122 may include license cell generation process 532 to generate license cell 220. However, in one embodiment, another module may generate the license cell 220, and either the license manager 530 or the content manager 124 may place the appropriate license cell 220.
[0060]
The license manager 530 may include other processes (not shown) such as temporary storage of the issued license. In one embodiment, the license manager 530 includes an issued license database 547 that is tracked each time a new license is generated. With this management, the license manager 530 becomes an audit trail (audit trail) of the licensing process and can provide the required license information to other modules.
[0061]
d. Database collection
In one embodiment, offer manager 122 includes database collection 540 shown in FIG. The illustrated database collection 540 includes a contract database 541, an encryption key database 542 (including one or more symmetric keys), a public certificate database 543, a content database 544, a user database 545, a group database 546, and an issued license database. (“License database”) includes a plurality of databases such as 547, billing database 548, cell header information database 549, and the like.
[0062]
The rules database 541 contains rules regarding how and when to assign rights to content. The rules may be general (eg, content X requires license Y) or more specific (eg, anyone who has license Y can print content Y, print content X) Needs a license Y, and if there is no license, it jumps to URL C). Although FIG. 5 illustrates the convention database 541, in other embodiments, the convention may be stored in another format, such as a program or script.
[0063]
The encryption key database 542 contains a set of symmetric keys used by the content manager 124 to encrypt the requested content. The symmetric key can be generated using known techniques. For a more detailed description of symmetric and asymmetric cryptography, see "Applied Cryptography: Protocols, Algorithms, and Source Code in C, Second Edition," by Bruce Schneier (see John Wiley & Co., 1992). Although this embodiment uses a symmetric cipher, in other embodiments, another cipher different from or related to the symmetric cipher may be used.
[0064]
Public certificate database 543 contains a set of public certificates from other components with which offer manager 122 communicates. The component's public encryption key is in the component's public certificate. For example, the public certificate database 543 may include a public certificate of the content manager 124 (including the public key of the content manager 124) so that the content manager 124 and the offer manager 122 can authenticate when communicating. The public certificate database 543 may include a public certificate of the user computer 115 requesting the license.
[0065]
In particular embodiments, offer manager content database 544 may include some or all of content manager content database 438. Content database 544 may copy data from content manager's content database 438 using well-known data duplication techniques so that offer manager 122 and content manager 124 each copy the same data without compromising data identity. May be used. Further, offer manager content database 544 may include information that is not included in content manager content database 438. Although this embodiment has shown that the offer manager 124 and the content manager 122 each have the same copy of the content database 544, 438, in another embodiment, the offer manager 122 and the content manager 124 both have the same content. You may access the database. For more detailed information on one embodiment of the content database 544, see the section entitled "1. Content Manager c. Database Collection".
[0066]
User database 545 tracks information about users. The user database 545 may include tables such as a user information table, a user credit card information table, a user comment table, and a user account balance table.
[0067]
The user information table contains information about the users of the system. User information table includes user account ID, name, last name, work place, email address, account creation data, account status, current billing amount, current credit, balance limit, service level, promotional email, remote user, remote address, remote It may include fields such as host, billing name, billing address, password, password encryption type, and the like. The user credit card information table holds a record of the user's encrypted credit card number and other credit card information. The user credit card information table may include fields such as a user account ID, a credit card encryption method, an encrypted credit card account number, a credit card expiration month, and a credit card expiration year. The user comment table tracks the comments of a particular user and allows for customized customer support. The user comment table includes fields such as a user account ID, a time stamp, and a comment field. The user account balance table keeps a record of the user's credits and charges for each particular issue accessed by the user. The user account balance table contains fields such as user account ID, issue ID, credit generation time, available credit, applied credit amount, current billing amount, displayed price terms, and other information related to the user account. May be included.
[0068]
The group database 546 links multiple users to one account, such as a corporate account. The group database 546 may include tables such as a group table, a group user table, and a publication table.
[0069]
The group table maintains information related to the group. The group table includes fields such as group ID, group name, password, account type, number of days the account is valid, issue ID, expiration date, and the like. The group user table specifies the members of the group. The group user table may include fields such as a group ID, a user account ID, and an expiration date. The group publications table identifies the publications that members of the group can access. The group publication table may include fields such as group ID and publication ID.
[0070]
The license database 547 may include a plurality of tables such as issued license tables. The issued license table records each license issued to the user that allows access to the article. The fermented license table may include fields such as transaction ID, time stamp, article ID, content cell location, content cell ID, framework ID, issue ID, billing amount, and the like.
[0071]
Billing database 548 manages billing transactions. The billing database 548 may include tables for current transactions, billable transactions, billable applications (summary), and the like. Other standard billing information may be included in billing database 548.
[0072]
Cell header information database 549 contains information for cell headers. This information includes a unique identifier for each license cell 220, a unique identifier for each content cell 210, information about the various stores that make the content, descriptive information, and verification information (eg, expiration date and time). ) May be included.
[0073]
The database collection 540 may include other databases (not shown) to perform various management tasks. For example, the database collection 540 may include a user action database that tracks various user activities, such as user requests, and may use click-through (tracking every time a user selects a web link). In addition, the database collection 540 may include an error database that tracks various system errors, for example, errors related to a specific article, errors related to a new user, errors related to a new license, and the like. The database collection 540 may include a database for maintaining data identity, such as various synchronization tables that alert the system when new information is added and / or when existing information must be changed. good. Database collection 540 may include a promotion database that tracks promotions sent to users by email and other communication means. The database collection 540 allows the user to load the user manager 320 on one of the user's computers, such as when the user attempts to reinstall the user manager 320 on one of the user's computers, or when the user verifies the user ID. May include user manager activation information for tracking the number of attempts.
[0074]
With respect to the database collection 540, in one embodiment, there may be multiple processes (not shown) such as an ID generator, a number generator, a statistics generator, a session generator, a temporary storage unit, etc., that work with the database collection 540.
[0075]
In one embodiment, database collection 540 is implemented using a Microsoft SQL server, a relational database that can access data through Structured Query Language (SQL). SQL is a language standardized by the International Standards Organization for defining, updating, and querying relational databases.
[0076]
In one embodiment, the database collection 540 can be implemented using different relational databases and different types of databases (eg, flat file databases). Further, although the database collection 540 shown in FIG. 5 comprises a plurality of individual databases, in other embodiments, the database collection 540 may include another database, or some databases may be combined. Is also good. The database collection 540 may be implemented as a single database having individual tables, or may be implemented as another known data structure such as linked data or a binary tree.
[0077]
In one embodiment, the database collection 540 is connected to a backend component (not shown) that receives database requests through a servlet (a small program running on a server) and sends SQL requests corresponding to the database collection 540. Is also good. In other embodiments, accessing the data may be different, for example, using different types of back-end components, or accessing the database collection 540 directly.
[0078]
A more detailed description of an embodiment of the database collection 540 is in Appendix A attached. Appendix A database collection 540 shows the license management system 120 where both the content manager 124 and the offer manager 122 access the same database collection, but in another embodiment, the content manager 124 and the offer manager 122 It may have a database (similar, partially identical, or different).
III. License management system cell
In one embodiment, the license management system 120 generates a cell containing the content (content cell 210) and a cell containing the license (license cell 220).
[0079]
A. Content cell
FIG. 6a is an embodiment of a content cell 210a. The illustrated content cell 210a includes a set of conventions 612a, an encrypted content 614a, a cell header 616a, a public certificate 618a, and a content cell signature 611a.
[0080]
1. Terms
Content cell convention 612a informs user computer 115 what rights are associated with content cell 210a and what is required to obtain those rights. For example, content cell 210a may have a set of requirements for the right to print an article and a set of requirements for viewing an article. In one embodiment, the convention 612a may be written for a particular user, and in another embodiment, the convention 612a applies to a more general written class of users. It may be something.
[0081]
2. Encrypted content
Content cell encrypted content 614a includes the requested content encrypted by content manager 124. In one embodiment, the content is encrypted using a symmetric key. The symmetric key is encrypted by the license management system 120 using the offer manager's public key, and only the offer manager 122 can decrypt the subject key, and the encrypted subject key is sent to the user manager 320. When the user manager 320 requests a license, the user manager 320 sends the encrypted target key to the offer manager 122. Once offer manager 122 verifies that user computer 115 has a valid license, offer manager 122 can decrypt the symmetric key, encrypt the symmetric key with the user manager's public key, and provide Allow the symmetric key to be decrypted and the content to be decrypted. For a more detailed description of symmetric and asymmetric encryption, see "Applied Cryptography: Protocols, Algorithms, and Source Code in C, Second Edition," by Bruce Schneier (John Wiley, 1992). Although this embodiment uses a combination of symmetric and asymmetric encryption, other encryption methods may be used. For example, both offer manager 122 and content manager 124 may have access to a database of symmetric keys, and the symmetric keys may not be sent to user computer 115 until user computer 115 obtains a license.
[0082]
3. Cell header
Cell header 616a contains information about content cell 210a. Such information includes the unique identifier of the content cell 210a, information about the store that produces the requested content, descriptive information, information for locating the offer manager 122 (eg, the offer manager's URL, etc.), and verification information ( For example, the date and time of the expiration date) may be included.
[0083]
4. Public certificate
The public certificate 618a of the content cell is a public certificate of the cell creator, and includes the public key of the cell creator. For example, if content manager 124 creates content cell 210a, content manager 124 signs cell 210a and includes the public certificate in content cell 210a. The public certificate 618a causes the recipient of the cell (eg, the user computer 115) to verify the authenticity of the sender (eg, the content manager 124).
[0084]
5. Content cell signature
The digital signature 611a of the content cell is information based on both the content cell 210a and the private key of the content manager. Digital signature 611a is used by user computer 115 to authenticate the creator of content cell 210a and the information contained in content cell 210a.
[0085]
Generally, a digital signature is a code that is unique to each message and the sender of the message. Authentication using a digital signature ensures that the message is from the sender as expected and that the message is complete and unaltered. Digital signatures are cryptographic means that can be used to verify the origin of a cell and the identity of the sender. For a more detailed description of digital signatures, see "Applied Cryptography: Protocols, Algorithms, and Source Code in C, Second Edition" by Bruce Schneier (John Wiley & Sons, 1992).
[0086]
6. Other signatures
FIG. 6b shows another embodiment of the content cell 210b. The convention 612b, the encrypted content 614b, and the cell header 616b are similar to those described above, but each component has its own digital signature 613b, 615b, 617b. Each digital signature 613b, 615b, 617b is generated by the module that generated the component. For example, the contract signature 613b is generated by the module that generated the contract 612b, and the cell header signature 617b is generated by the module that generated the cell header 616b. In another embodiment, different modules may generate different portions of content cell 210, with each module providing its own digital signature. This feature allows the cell recipient to verify the identity of the component creator. To verify the creator's identity in this embodiment, the content cell 210 must include a public certificate 618b of each module that generated the portion of the content cell 210.
[0087]
In another embodiment, the digital signature can be used for a separate contract, or a set of contracts. For example, if module A generates rules X, Y, Z and module B generates rules M, N, module A can sign rules X, Y, Z, and module B signs rules M, N. it can. The public certificates of both module A and module B are sent in content cell 210, and the user can verify the source of each agreement.
[0088]
In another embodiment, the content cell 210 may be composed of different components, or may include only a subset of the components described above. Further, while various encryption techniques have been discussed, such as symmetric encryption, asymmetric encryption, and digital signatures, in other embodiments, other security means may be used.
[0089]
B. License cell
FIG. 7a illustrates one embodiment of a license cell 220a. The illustrated license cell 220a includes a set of encrypted conventions 712a, an encrypted license 714a, a cell header 716a, a public certificate 718a, and a license cell signature 711a.
[0090]
1. Terms
The license cell agreement 712a informs the user computer 115 what rights accompany the license cell 220a and what is needed to obtain those rights. For example, license cell 220a may have a set of requirements for the right to print an article and another requirement for viewing an article. In one embodiment, the contract may be written for a particular user, or in another embodiment, the contract may be written more generally and apply to a particular class of users. In one embodiment, both license cell 220 and content cell 210 include rules 612, 712. In another embodiment, only the license cell 220 or only the content cell 210 includes the rules 612, 712, or neither includes the rules 612, 712.
[0091]
2. Encrypted license
The license license 714a of the license cell includes the requested license encrypted by the license manager 530. In one embodiment, the license is a unique identifier. In another embodiment, the license may be another type of data, eg, a record of information, and the license may include terms.
[0092]
In one embodiment, the license is encrypted using a symmetric key. For example, a license may be encrypted using the same symmetric key that encrypted the content. In one embodiment, the symmetric key is encrypted by the license management system 120 using the user manager's public key, so that only the user manager 320 can decrypt the symmetric key and thus decrypt the license. Although this embodiment describes the use of symmetric and asymmetric keys, other encryption methods may be used.
[0093]
3. Cell header
Cell header 716a contains information about license cell 220a. Such information may include the unique identifier of the license cell 220a, the identifier associated with the content cell 210, information about the store making the requested content, descriptive information, and verification information (eg, expiration date and time). May be included.
[0094]
4. Public certificate
The public certificate 718a of the license cell is a public certificate of the cell creator and includes the public key of the cell creator. For example, if license manager 530 generates license cell 220a, license manager 530 signs cell 220a and includes public certificate 718a in license cell 220. The public certificate 718a allows the recipient of the cell (eg, the user computer 115) to verify the authenticity of the sender (eg, the license manager 530).
[0095]
5. License cell signature
The digital signature 611a of the license cell is information based on the private key of the license cell 220a and the license manager. Using the digital signature 611a, the user computer 115 confirms that the creator of the license cell 220a and the information included in the license cell 220a are authentic.
[0096]
6. Another signature
FIG. 7b shows another embodiment of a license cell 220b. Terms 712b, encrypted license 714b, cell header 716b are similar to those described above, but each component has its own digital signature 713b, 715b, 717b. Each digital signature 713b, 715b, 717b is generated by the module that generated the components 712b, 715b, 716b. For example, the contract signature 713b is generated by the module that generated the contract 712b, and the cell header signature 715b is generated by the module that generated the cell header 714b. In another embodiment, another module may generate another portion of license cell 220b, so that each module provides its own digital signature. This feature allows the recipient of the cell to verify that the creator of the component is authentic. In this embodiment, to verify the identity of the creator, license cell 220b must include a public certificate 718b in each module that generated a portion of license cell 220b.
[0097]
In another embodiment, the digital signature may be used to sign individual or set of rules. For example, if module A generates rules X, Y, and Z, and module B generates rules M and N, module A signs rules X, Y, and Z, and module B writes rules M, N Will sign. The public certificates of Module A and Module B will be sent in license cell 220 and the user will be able to verify the source of each agreement.
[0098]
In another embodiment, license cell 220 may be comprised of other components or may include some of the components described above. Furthermore, although various encryption techniques such as symmetric encryption, asymmetric encryption, and digital signature have been discussed, in another embodiment, security may be ensured by another method.
IV. Overview of the license management process
FIG. 8 shows a flowchart of one embodiment of the information flow previously discussed in FIG. The flowchart shown in FIG. 8 corresponds to the information flow shown in FIG. 2. Step 820 corresponds to event A, step 830 corresponds to event B, step 840 corresponds to event C, step 850 corresponds to event D, and step 860 corresponds to event E. , And step 870 corresponds to event F, respectively.
[0099]
Beginning at a start step 810, the process proceeds to a user computer request step 820. At step 820, user computer 115 requests the specific content, and then proceeds to content manager transmission step 830. At step 830, content manager 124 sends the requested content to user computer 115 and proceeds to the next step 840 where user computer 115 requests a license. At step 850, offer manager 122 sends the license to user computer 115 and proceeds to step 860 where user computer 115 checks for the requested content and the corresponding license. If they are found, the process proceeds to step 870, where the user manager 320 invokes the appropriate application for the requested content. The process proceeds to end step 880.
[0100]
A. User requests content
In one embodiment, at step 820, the user views the web page using browser 310. Next, the user requests the content to view, print, copy, or play. In another embodiment, the user requests content by attempting to access content cells 210 sent using e-mail or stored on a storage unit such as a CD-ROM, floppy disk, or the like. You can also. Note that in other embodiments, the content may be requested without the user's knowledge. For example, when a particular computer application is executed, the computer program application may automatically send a request for content to the content manager 124.
[0101]
B. Content manager sends content cell
With reference to step 830, content manager 124 finds the requested content and prepares the content for presentation to user computer 115. The flowchart corresponding to step 830 is further shown in FIG. Beginning at a start step 830, the process proceeds to step 910, where the content manager 124 receives a content request. Proceeding to step 920, the content manager 124 creates a content cell 210 containing the requested content, and proceeds to step 930, where the content manager 124 sends the content cell 210 to the user browser 310 of the user computer 115.
[0102]
In this embodiment, the content manager 124 creates the content cells 210, but in other embodiments, the content manager 124 may locate a pre-made content cell 210 in a database. As described above, another module may create and store a generic content cell 210, and another module, such as content manager 124, may access the content cell 210 and send it to the user as requested. Further, the content cells 210 may be drawn from disks, CD-ROMs, and other storage devices. After the content manager 124 has created the content cell 210 in step 920, the content manager 124 sends the content cell 210 to the user's browser 310 in step 930, and then proceeds to the end step 940. In another embodiment, the content cell 210 may be sent directly to the user manager 320 instead of the user browser 310.
[0103]
C. User computer requests license
FIG. 10 shows a flowchart corresponding to step 840 in which the user computer 115 requests a license. Beginning at a start step 840, the process proceeds to step 1010, where the user browser 310 receives the content cell 210 and passes the content cell 210 to the user manager 320. The user manager 320 opens the content 210 at step 1020 and proceeds to step 1030, where the user manager 320 verifies that the content cell 210 is genuine. As described above, in one embodiment, the content cell 210 includes a signature and a public certificate so that the user manager 320 can use the public certificate to verify that the sender and creator of the content cell 210 are authentic. It has become. Proceeding to step 1040, the user manager 320 searches for a license for the content cell 210. If a license is found in step 1050, the process proceeds to end step 1090, and proceeds to step 870, where the user manager 320 invokes the application and content. However, if a license is not found, the process proceeds to step 1070 where the user manager 320 stores the content cell information in the content database 334 and proceeds to step 1080 where the user computer 115 requests a license. In one embodiment, user manager 320 causes user browser 310 to send a license request to content manager 124 and proceeds to end step 1090.
[0104]
D. Offer manager submits license
A flowchart corresponding to step 850 in which offer manager 122 sends a license to user computer 115 is shown in FIG. Beginning at a start step 850, the process proceeds to step 1110, where the offer manager 122 receives a license request and proceeds to step 1120, where the offer manager 122 uses the user browser 310 to cause the user to meet license issuance requirements. For example, a user may have to send registration information, mailing information, answer questions, and send credit card information. Sample registration form includes name, last name, email address, work location, credit card type, credit card number, expiration date, name on credit card, billing address, city, state, postal code, country, password Etc. may be entered. Proceeding to step 1130, if the user does not meet the requirements, the process proceeds to end step 1140. However, if the user meets the requirements, the process proceeds to step 1150, where the user manager 320 starts creating the license cell 220. After license manager 530 creates license cell 220, the process proceeds to step 1160, where offer manager 122 may "bill" user computer 115 for a license fee. This billing occurs, for example, if the license issuance requirement includes payment by credit card or other account information. In another embodiment, the billing transaction may be processed by another module, for example, a service provider, a server, etc. Step 1170, offer manager 122 sends license cell 220 to user's browser 310 and proceeds to end step 1180.
[0105]
E. FIG. User computer looks for license and content
A flowchart corresponding to step 860 in which the user computer 115 finds the content and the license is shown in FIG. Beginning at a start step 860, the process proceeds to step 1210, where the user's browser 310 receives the license cell 220 and passes the license cell 220 to the user manager 320. At step 1220, user manager 320 opens license cell 220 and proceeds to step 1230, where user manager 320 verifies that license cell 220 is genuine. As described above, the license cell 220, in one embodiment, includes a signature and a public certificate so that the user manager 320 can use the license cell 220 to verify that its sender and creator are authentic. Proceeding to step 1240, the user manager 320 stores the license cell information on the user computer 115. In one embodiment, license manager 530 stores license cell information in license database 332. In other embodiments, other storage methods may be used. Proceeding to step 1250, the process verifies that the user still wants a license. If the user's answer is no, the process proceeds to end step 1255. If the user still wants a license, the process proceeds to step 1260, where user computer 115 reclaims the license, and proceeds to step 1270, where user computer 115 looks for the license and proceeds to step 1280. At step 1280, user computer 115 searches for content and proceeds to step 1290.
[0106]
F. User manager calls the application
If the user manager 320 has the license and the content, the user manager 320 calls the appropriate application for the requested content at step 870 and proceeds to an end step 880. The user manager 320 enables appropriate access to the content according to the rules. For example, if the requested content is a song in MP3 format and the convention allows the user computer 115 to play the first 20 seconds of the song, the user manager 320 will send the MP3 player on the user computer 115 along with the requested song. To play the song for 20 seconds. The access method to the content can be various types according to the rules, such as viewing part of the content, watching the entire content, copying part of the content, copying the entire content, etc. It is also possible to print a part of the content, print the entire content only once, or print the entire content twice.
[0107]
G. FIG. Other embodiments
In one embodiment, the content may be requested before the license is generated, but in another embodiment, the license may be generated or requested before the content is generated or requested. For example, a user can buy a license to subscribe to all new articles in a particular publication. The user receives a license for the content that has not yet been generated. Further, one content may relate to one or more licenses, or one license may correspond to one or more content.
[0108]
In one embodiment, the content manager 124 may send the content location cell to the user. The content location cell provides the user with information on where the content is. The user may still need the content cell 210 when ready to access the content. For example, suppose the user wants to watch a two hour movie video file. Rather than sending the entire content at once, a license management system module, such as content manager 124, may send the user a content location cell that has access to the location of the requested content.
[0109]
The content location cell may be similar to the content cell, but includes the location information of the encrypted content, such as a URL, instead of the content itself. Content location cells may be generated by content manager 124 or other modules. When the user receives the content location cell, the user may request a license to access the content location. After the user receives a license to access a particular location, the user may access the content location. This access allows the user, for example, to view a piece of content and access the advertisement. The user may request access to the content itself or, if necessary, an appropriate license.
V. Make cells
13 and 14 illustrate one embodiment for creating a content cell 210 and a license cell 220. FIG. As described above, in another embodiment, another module may make the cell, or the cell may be made using another technique.
[0110]
A. Create content cells
A flowchart corresponding to the embodiment of the composition of the content cell 210 is shown in FIG. At a start step 920, the process proceeds to step 1310 where the content manager 124 extracts the contract 612. As described above, the rules 612 inform what types of licenses and / or users can access various types of data and what is needed to access the content. The rules 612 may be stored in a rules database or may be listed as text documents and / or programs, as long as the content manager 124 can determine which rules 612 apply to the selected content.
[0111]
Proceeding to step 1320, the content manager 124 obtains content from the content database 438. In one embodiment, all content is stored in one database, and content manager 124 can search the database and retrieve the requested content.
[0112]
Proceeding to step 1330, the content manager 124 encrypts the content. Various known techniques may be used for the encryption technique. However, as described above, in one embodiment, the content manager 124 encrypts the content using the symmetric key and encrypts the symmetric key using the offer manager's public key. When the encrypted content 614 and the encrypted symmetric key are sent to the user computer 115, the user computer 115 cannot decrypt the content and cannot decrypt the symmetric key until it has the appropriate license.
[0113]
Proceeding to step 1340, the content manager 124 generates a cell header 616. Cell header 616 may include a unique identifier for the content, the store from which the content was derived, descriptive text, expiration information, and other information.
[0114]
Proceeding to step 1350, the content manager 124 adds the extracted rules 612, the encrypted multi-content 614, the cell header 616, and its own public certificate 618 to the content cell 210. At step 1360, content manager 124 "signs" content cell 210. As described above, the module that signs the content cell 210 must also include the module's public certificate in the cell. Accordingly, in step 1350, content manager 124, including its public certificate, enables the recipient to verify that it was content manager 124 that generated and transmitted content cell 210. After content manager 124 signs content cell 210, the process proceeds to end step 1370.
[0115]
B. Make a license cell
FIG. 14 shows a flowchart corresponding to one embodiment of forming the license cell 220. At a start step 1150, the process proceeds to step 1410 where the license manager 530 extracts the rules 712. As described above, the rules 712 inform what types of licenses and / or users can access various types of data and what is needed to access the content. The rules 712 may be stored in a rules database, or may be listed as a text document and / or program, as long as the license manager 530 can decrypt and determine which rules 712 apply.
[0116]
Proceeding to step 1420, the license manager 530 generates a license. Proceeding to step 1430, license manager 530 encrypts the license. Various known techniques can be used for the encryption technique. However, as described above, in one embodiment, license manager 530 encrypts the license using a symmetric key, and then encrypts the symmetric key using the user's public key. When the encrypted license 714 and the encrypted symmetric key are sent to the user computer 115, the user computer can decrypt the license.
[0117]
Proceeding to step 1440, license manager 530 generates cell header 716. Cell header 716 may include a unique identifier for the license cell, a unique identifier associated with the content, the store from which the content was derived, a descriptive text, information about the expiration date, and other information.
[0118]
Proceeding to step 1450, the license manager 530 adds the extracted contract 712, the encrypted license 714, the cell header 716, and its own public certificate 718 to the license cell 220. At step 1460, license manager 530 "signs" license cell 220. As described above, the module that signs the license cell 220 must include the module's public certificate in the cell. Accordingly, at step 1460, license manager 530, including its public certificate, allows the recipient to verify that license manager 530 has generated and transmitted license cell 220. After license manager 530 signs license cell 220, the process proceeds to end step 1470.
[0119]
In one embodiment, license manager 530 stores a copy of license cell information in license database 547 for later tracking of issued licenses.
VI. Conclusion
While certain preferred embodiments of the invention have been described, these embodiments are provided by way of example only and are not intended to limit the scope of the invention. Accordingly, the breadth and scope of the present invention should be determined only by the claims and the equivalents thereof.
[0120]
[Table 1]Addendum A

ActivatedFwids table
Register all successful installations of the media center by the user. Assign the activated framework to each user. Currently, there is a one-to-one relationship between a user and an activated framework. There are plans to change this relationship so that one user can have multiple activated frameworks.
Before activating the framework, it must first be pending. When activated, copies all information about the framework in the PendingFwids table to the ActivatedFwids table. The backend then knows who the user is and which framework is used.
[Table 2]

Field description
TimeStamp
Date and time when the framework was activated
FrameworkId
Framework unique identifier (eg, fwid0001.000000001101). Currently, it is one framework corresponding to one user account Id. There are plans to allow multiple activated frameworks Id for a user account Id.
CellId
A character string that uniquely identifies the framework Id cell. Each cell, including the framework Id cell, contract cell, and content cell, has a unique Id.
Email
The email account entered by the user when installing the media center.
RequestId
Verify which framework came from. Further increase security (ie, if the backend responds, try to activate and send the request Id; use it to prevent hackers).
UserHost
Not used now.
RemoteHost
Not used now.
Authentication
Boolean value. False indicates that the email address has not been authenticated. Indicates that the user received the backend confirmation email and clicked to complete registration. This process can authenticate or verify that the email address is correct because the backend knows that the user actually received the email.
UserAccountId
Same as user.
ValidThrough
Expiration date of framework Id (eg, 6 months, 1 year, etc.)
Administrators table
Contains a list of special users who are authorized to perform administrative tasks. The administrators in this list have nothing to do with the user. The administrator logs in as a media DNA employee and publisher with authority to manage Knowledge Star data.
[Table 3]

Field description
Name
Administrator name or login account.
Password
Password for accessing the administrator account.
Email
E-mail address of administrator. Can communicate electronically with the administrator (eg, sending reports, statistics).
Phone
Administrator phone number.
PublisherId
Publications for which this administrator has authority.
Type
Defines the type of this administrator. Currently there are only two types, regular and super. Regular Administrators can only handle designated publishers and their publications. Super Administrators do not have this restriction. In other words, becoming a super administrator means disabling the PublisherId column. Valid values in this column are R and S.
ManageCorpAccounts
Indicates whether this administrator has authority to manage corporate accounts.
ManagePromoEmail
Indicates whether this administrator has the authority to manage promotional emails.
ArticleSync table
Represents a queue of DOIs (articles) to be updated on the dynamics database. This is for synchronizing the DOI list in the dynamics database with the DOI list on the Knowledge Star.
[Table 4]

Field description
Doi
Doi of articles that need to be synchronized.
Operation
Explain what to do to synchronize articles between databases.
Currently, two operations, creation and update, are possible. Valid values are C and U.
Status
Describes the state of Operation. Three values are defined: Pending, In Progress, and Error. Valid values are P, I, E.
ErrorReason
If an error occurs during synchronization, Status is set to E and an error message enters this field.
BillableSummaries table
Lists a summary of all transactions made by a particular framework (user) as billing information for that account. One entry is the sum of a number of individual transactions in the BillableTransactions table.
[Table 5]

Field description
TransactionId
Uniquely identify a group of transactions (one or many) of the user.
TimeStamp
Date and time when the transaction occurred.
AccountId
The user who made the transaction.
FirstName
User's first name.
LastName
Last name of the user.
Company
Workplace of the user. This field may be blank.
Email
Email address of the user.
AccountStatus
Define the status of a user account. The user account has inactive (0), guest use (1), member use (2), and group use (3) states. It can also be unused (4).
ServiceLevel
For providing different levels of service to different users in the future (eg, gold, silver, elite, etc.). Currently there are only two levels, guest and member.
NameForBilling
The name for the billing business for this user.
BillingAddress1
Billing address field No. 1
BillingAddress2
Billing address field No. 2
City
Billing address (city).
State
Billing address (state).
PostalCode
Billing postal code.
Country
Billing address (country).
CardType
Billing credit card type (Visa, Master, etc.).
EncryptedCardNumber
An encrypted credit card number. Encrypted for security.
EncryptionType
The encryption type used to encrypt the credit card number. Available are Basic (1), RSA (2), and SimpleHash (3).
CardExpirationMonth
Credit card expiration date (month).
CardExpirationYear
Credit card expiration date (year).
CountOfTransactions
The number of transactions grouped in this summary.
Amount
Transaction amounts grouped by this summary.
Comment
General comment field. Rarely used
BillableTransactions table
List individual billable transactions that have occurred on Knowledge Stars. Transactions occur each time a contract is issued.
[Table 6]

Description of the field.
TransactionId
Identify the transaction as part of a group of transactions for a user.
TimeStamp
Date and time when this table was entered. Generally, when the user has accepted the credit card charge on the "Payments" page.
TransTime
Date and time when the transaction occurred. Time, days, or weeks prior to TimeStamp may be used. Generally, when a user purchases each document.
Description
Description of what transaction. It usually contains the title of the purchased article or is an introduction.
Doi
Articles traded.
AccountId
The user who transacted.
FrameworkId
Framework identification number used by the user.
PublicationId
The publication to which the article belongs.
TransType
Transaction type identified by number. Valid types are In Use (0), Introductory Credit (1), Purchase (2), and Summary (3).
Amount
Transaction amount.
Comment
Comments about the transaction. It is usually blank.
ClickThroughs table
Tracks each time a user clicks on a Knowledge Star to go to the published website.
[Table 7]

Description of the field.
TimeStamp
The date and time of the click through.
FrameworkId
Click-through framework. We will track users who use this framework later.
PublicationCode
Publications that the user has clicked through.
ContractStats table
When stopping the backend, before exiting, record the number of transactions the backend took and the average time it took. This record is kept in this table. This table is not directly related to other tables in the backend star database. Request for debugging and system monitoring.
[Table 8]

Field description
TimeStamp
The date and time when the backend finished executing.
NumberContracts
The number of contracts generated (issued) by the backend between the time the backend was last initialized and the time it is terminated this time.
AverageTime
Average time required to generate a contract. This value is used to monitor the performance of the contract generation code.
Comment
General comments. Usually displays a message that the backend has finished executing.
CreditCardNumbers table
Each user's credit card number is encrypted and stored. The type of encryption that encrypted the credit card number is also specified.
[Table 9]

Field description
UserAccountId
Identify accounts that can use this card.
EncryptionType
The method used to encrypt the credit card number. Basic (1), RSA (2), and SimpleHash (3) can be used.
EncryptedCardNumber
An encrypted credit card number.
CurrentTransactions table
Stores information related to the transaction. An entry is made in the CurrentTransactions table for each contract. Entries may be debits or credits, or may delete these entries. Each time a user purchases an article, an Issued Contract entry and a CurrentTransaction entry are made.
[Table 10]

Field description
TimeStamp
The date and time when the transaction was made.
Description
Explain the transaction target. It typically contains the title of the purchased article and information about the referral credit (ie, for a purchase transaction, the name of the article is entered).
Doi
Articles traded.
AccountId
Identify the user.
FrameworkId
Identify the framework that should handle this transaction.
PublicationId
Identify the issue of the traded article.
TransType
Transaction type identified by a number. Valid types are unused (0), referral credit (1), purchase (2), and summary (3).
Amount
The amount of this transaction.
Comment
General comment field.
DOIs table
Contains article-related information. Articles are also known as DOIs. Each DOI represents a DOI that can be handled by the Knowledge Star. This table is an inventory of articles, including all articles that the user will access, all content cells, and so on. This table is a naming servlet.
[Table 11]

Field description
TimeStamp
Date and time when the DOI was registered.
Title
Article title.
PublicationId
The identification number of the issue to which this DOI belongs.
PublisherId
The identification number of the issuer to which this DOI belongs.
Url
Address at which the article cell is located (example: file: // d: \ dataDirectory \ cells \ com.cadcamnet_cad_018_01_01.mdna)
Price
The price of this article.
ValidFrom
Indicates the first date that this DOI can be accessed. Restrict access to articles.
ValidThrough
Indicates how long this DOI can be accessed. Restrict access to articles.
ContentCell
Indicates whether the cell specified by this DOI is a content cell. The value is true (1) or false (0).
EmailHistory table
Track email sent to specific users. The date the email was sent to the template user is also recorded.
[Table 12]

Field description
TemplateId
Email template used. EmailTemplates. Foreign key to TemplateID.
DateSent
Date when the email was sent.
ToHeader
The email account from which the email was sent. Since the user can change this data in the customer profile, the user remembers the address actually used.
UserAccountId
The user receiving the email. Users. Foreign key to AccountId.
EmailTemplates table
This table contains a collection of templates that can be used by the system to generate email messages. To generate an e-mail message, the system takes the FromHeader, the SubjectHeader, and the Body from the database entries and uses them to compose the message. Templates are owned by a specific publisher or owned by the system.
[Table 13]

Field description
TemplateId
This number uniquely identifies the template.
PublisherId
The publisher that owns this template. If this column is 0 (zero), it indicates that it is a system template.
Name
The name of this template. This name is unique among templates owned by this publisher.
CreationDate
Date when the template was created.
SubjectHeader
Subject line when sending e-mail with this template.
FromHeader
Define a FromHeader for emails sent using this template.
Body
Email content using this template.
ErrorLogDoi table
Record Doi related errors. The log includes the date the error occurred, the type of error, the framework (user) that issued the error, and the Doi attempted.
[Table 14]

Field description
TimeStamp
Date and time when the error was recorded.
ErrorNumber
Error number that describes the nature of the error. Doi errors with high frequency are Doi not found (101) and Doi is unresolved (102).
Doi
Access to this article resulted in an error.
FrameworkId
Framework requesting failed articles.
RemoteADdr
Remote IP address where Doi error was issued.
RemoteHost
Remote host name where Doi error was issued.
ErrorLogFwid table
Logs FrameworkId related errors. The log contains the date the error occurred, the type of error, the framework (user) that issued the error, and the Doi attempted.
[Table 15]

Description of the field.
TransactionId
A unique transaction number that identifies the error.
TimeStamp
Date and time when the error was recorded.
ErrorNumber
Number describing the error. Possible errors are no Fwid (2001), bad format (2002), unregistered (2003), account not found (2004), not activated (2005), expired (2006). .
FrameworkId
Framework involved in errors.
Doi
Doi involved in an error.
RemoteAddr
User IP address involved in the error.
RemoteHost
User host name involved in the error.
ExtraText
General comments.
ErrorLogFwidActivation table
Record errors related to activation of FrameworkId.
[Table 16]

Field description
TimeStamp
Date and time when the error was recorded.
FrameworkId
Framework involved in errors.
CellId
A character string that uniquely identifies the ID cell of the framework that experienced the error.
Expires
The time at which the framework's ID cell expires.
UserHost
This column is no longer used.
RequestId
Request number.
RemoteAddr
User's IP address.
RemoteHost
This column is no longer used.
FrameworkReinstalls table
Count the number of times the user has attempted to reinstall the framework and assign a new framework identification number to the successful reinstallation.
[Table 17]

Field description
TimeStamp
Date when the framework reinstallation was recorded.
FrameworkId
Previously installed framework.
InstFwid
Reinstalled framework.
ChainLength
Number of framework reinstalls attempted by the user. When the number of times reaches a predetermined limit, the user is not allowed to perform further reinstallation.
RemoteUser
This column is no longer used.
RemoteAddr
IP address of the user who reinstalled the framework.
RemoteHost
Host name of the user who reinstalled the framework.
FwidCellidNumberGenerator table
This is a mechanism for generating a unique cell number. Track the cell ID number. This table has no direct relationship to other tables in the Knowledge Star Database back end.
[Table 18]

Field description
NextCellidNumber
Track the identification number of the next cell.
Group Publications table
Identify publications accessible by user group members.
[Table 19]

Field description
GroupId
Group identification number.
PublicationId
Issue identification number.
Groups table
Stores group-related information. Corporate account Users are combined into one account as a corporate account.
[Table 20]

Field description
GroupId
Group identification number. This number is unique.
Name
The name of the group.
Password
The password to access this group's account.
Type
A valid group account type. The currently permitted grape accounts are the demo account D and the standard account S. As each group account fee is paid, demo account users are promoted to standard accounts.
UserTTL
The number of days that this group's group account is valid.
PublicationId
Publications accessible to members of this group.
Expires
Expiration date of this group account.
GroupUsers table
Connect users to groups. Identify group members.
[Table 21]

Field description
GroupId
Group identification number.
UserAccountId
User account identification number.
Expires
Expiration date of this group account for this user.
IssueContracts table
Record each contract issued when a particular user obtains an article. Each contract is entered into the framework (one contract per published article). These entries are stored forever, so that users are not charged for downloading the same article.
[Table 22]

Field description
TransactionId
A unique number, an identifier for this transaction used for auditing.
TimeStamp
Date and time this transaction was created.
Doi
Indicates the article for which this contract was made.
ContractUrl
Identify where the contract cell is (contract cell will be destroyed after a while to clean the disk).
CellId
A character string that uniquely identifies the contract cell. Each cell has a unique ID, including framework ID cells, contract cells, and content cells.
FrameworkId
The framework ID can access the cell specified by Doi.
PublicationId
Indicates which issue the Doi of this contract belongs to.
Amount
The amount charged by the user. Used for debugging and tracking.
OnlineSubscriptionDefs table
Contains definitions for online subscriptions managed by Knowledge Star.
[Table 23]

Field description
Description
Describe the characteristics of the online subscription.
PublicationId
Publications that support online subscriptions.
Price
The price to subscribe to this publication online.
PendingFwids table
List all frameworks that are pending. The pending framework usually belongs to the guest user. When PendingFwid is activated, its entries "move" from this table to the ActivatedFwids table.
[Table 24]

Field description
CellId
A character string that uniquely defines the framework ID cell. Each cell has a unique ID including a framework ID cell, a contract cell, and a content cell.
FrameworkId
Pending framework.
Email
Guest user email with pending framework.
ValidThrough
Expiration date for which this pending framework is valid.
UserAccountId
User account that has this pending framework.
PromotionalEmail table
Register the characteristics and characteristics of each promotional email in the backend.
[Table 25]

Field description
PublicationId
Publication related to this promotional email.
TemplateId
The template used for this promotional email.
Enabled
Indicates whether this promotional email is enabled.
EnableDate
The date this promotional email was enabled.
Publications table
Contains information about each publication on the Knowledge Star. A single publication may contain multiple articles or DOIs.
[Table 26]

Field description
PublicationId
A unique number for each issue. Identify the issue internally.
Status
The status of the issue is "active" or "inactive".
PublicationCode
A short code that identifies the issue, usually a three-letter code (eg, csn, olr, cad).
ResourceFile
Indicates the file in which the publication is located (eg, c: \ back \ properties / ATContentCell.properties).
PublisherId
Issuer who owns this publication.
Domain
Issuer domain of this issue (eg, com.g2news, com.cadcamnet, etc.)
Name
Issue name.
ContentCellExtension
Cell format of the content of this issue (eg MDNA, XDNA)
UrlHomePage
The web address of this publication (eg: http://www.g2news.com/csnindex.html).
IntroCredit
Referral credits provided to users accessing articles from this publication. The amount is US dollar.
DefaultPrice
The default price of the article for this publication. The amount is US dollar.
FreeArticles
The number of free articles offered to users.
PermitPrinting
Indicates whether printing of articles in this publication is allowed. Valid values are true (1) or false (0).
PermitCopying
Indicates whether copying of articles in this publication is allowed. Valid values are true (1) or false (0).
Publishers table
Contains information from each publisher that has content on the Knowledge Star. An issuer may have multiple publications.
[Table 27]

Field description
PublisherId
The issuer's unique identification number.
Status
The status of the issue is "active" or "inactive".
PublisherName
Issuer's name.
DefaultPrice
The default price of the article for this publication. The amount is US dollar.
TransactionNumberGenerator table
This is a mechanism for generating a unique transaction ID number. Store a unique transaction ID number. This table has no direct relationship to the Knowledge Star Database table.
[Table 28]

Field description
NextTransactionNumber
Store the next transaction number.
UserBalances table
Keep a record of the user's credits and charges for a particular issue. There is an entry for the publication that the user has accessed.
[Table 29]

Field description
UserAccountId
The user accessing the article.
PublicationId
The publication to which the accessed article belongs.
TimeCreditCreated
The date and time that this user was credited for articles from this publication.
AvailableCredit
Shows the amount of credit available in US dollars.
CreditApplied
The amount of credit applied is shown in US dollars.
CurrentCharges
The amount in US dollars charged to this user for articles from this publication.
HaveShownPricingTerms
Indicates whether the user has viewed the terms and conditions of this publication's article. Valid values are true (1) or false (0).
UserComments table
Store comments for each user. This table is used for customer support.
[Table 30]

Field description
UserAccountId
The user whose comment is registered.
TimeStamp
Date and time when the comment was registered.
Comment
Comments for this user.
Users table
Stores Knowledge Star user account information. This information includes address, account status, credit, billing, etc. for each user. There is an entry for each user. If the user does anything that requires a framework ID number, an entry is created and the framework ID number is sent.
[Table 31]

Field description
UserAccountId
Identify each user.
FirstName
User's first name.
LastName
Last name of the user.
Company
Workplace of the user. You can leave it blank.
Email
Email address of the user.
AccountCreationDate
Date this user account was created.
AccountStatus
User account status. The user account is inactive (0), guest (1), member (2), or group member (3). It is also possible to disable (4). "Guest" is a user who has not completely registered with Knowledge Star. “Member” is a user who has provided complete information including billing information.
CurrentCharges
The charge for this user account is expressed in US dollars.
CurrentCredits
The credit available to this user is expressed in US dollars.
OutstandingLimit
The limit that reminds the user to pay. Can be set for each user.
ServiceLevel
Try to provide users with different levels of service in the future (eg "gold", "silver", "elite", etc.). Currently there are two levels, "guest" and "member".
PromotionalEmail
Indicates whether the user wants a promotional email. Valid values are true (1) and false (0).
RemoteUser
This column is not used.
RemoteAddr
User's IP address.
RemoteHost
This column is not used.
NameForBilling
Billing name.
BillingAddress1
User billing address No. 1
BillingAddress2
User billing address No. 2
City
The user's address (city name).
State
The user's address (state).
PostalCode
Postal code of the user.
Country
The user's address (country name).
Password
User password.
PasswordEncryptionType
Encryption type that encrypted the user's password. Usable are Basic (1), RSA (2), and SimpleHash (3).
CardType
Credit card type (eg Visa, MasterCard, etc.)
CardAccountNumber
A credit card number that is safe to display, for example, “xxxxxxxxxxxxxxx1234”.
CardExpirationMonth
The month in which the credit card expires.
CardExpirationYear
Year when the credit card expires.
UserSync table
User queue waiting to be updated in the dynamics database. The main purpose is to synchronize the user list in the dynamics database with the user list in the Knowledge Star database.
[Table 32]

Field description
UserAccountId
A user account for synchronizing both databases.
Operation
Describe what to do to synchronize articles between databases. Currently, two operations, Create and Update, are allowed. Valid values are C and U.
Status
Describes the state of Operation. Three values are defined: pending, ongoing, and error. Valid values are P, I, E.
ErrorReason
If an error occurs and Status is marked E, an error message is displayed here.
[Brief description of the drawings]
FIG.
FIG. 2 is a high-level block diagram of one embodiment of the present invention, illustrating the exchange of information between a license management system and a user computer.
FIG. 2
FIG. 3 is a high-level block diagram of one embodiment of the present invention, illustrating the flow of information between a content manager, an offer manager, and a user computer.
FIG. 3
FIG. 3 is a block diagram of an embodiment of the user computer of FIG. 2.
FIG. 4
FIG. 3 is a block diagram of one embodiment of the content manager of FIG. 2.
FIG. 5
FIG. 3 is a block diagram of one embodiment of the offer manager of FIG. 2.
FIG. 6a
FIG. 2 is a block diagram of one embodiment of a content cell.
FIG. 6b
FIG. 9 is a block diagram of another embodiment of a content cell.
FIG. 7a
FIG. 3 is a block diagram of one embodiment of a license cell.
FIG. 7b
FIG. 11 is a block diagram of another embodiment of a license cell.
FIG. 8
5 is a flowchart of one embodiment for providing a user with access to content.
FIG. 9
6 is a flowchart of an embodiment for transmitting content.
FIG. 10
6 is a flowchart of an embodiment for requesting a license.
FIG. 11
6 is a flowchart of an embodiment for transmitting a license.
FIG.
6 is a flowchart of an embodiment for checking content and license.
FIG. 13
6 is a flowchart of an embodiment for generating a content cell.
FIG. 14
6 is a flowchart of an embodiment for generating a license cell.

Claims (45)

A method of granting access to a data object,
Create a data object cell,
Sending the data object cell to a computer over a network,
Generating a license object cell related to the data object cell;
Transmitting the license object cell to the computer on the network;
A method for granting access to said data object cell based on information of said related license object cell. The method of claim 1, further comprising receiving a user request for a data object cell. The method of claim 1, further comprising receiving a user request for a license object. The method of claim 1, wherein granting access to the object cell comprises verifying that a license object cell associated with the data object cell is on the computer. The method of claim 1, wherein the data object cell includes at least a data control element and a data object. The method of claim 5, wherein at least the data object is encrypted. The method of claim 1, wherein at least a portion of the license object cell is encrypted. The method of claim 1, further comprising: retrieving a data location cell associated with the data object cell;
Transmitting the data location cell to a computer over a network,
A method of granting access to said data location cell based on information of an associated license object cell. A method of granting access to a data object,
Pull out the data object cell,
Sending the data object cell to a computer over a network,
Draw a license object cell related to at least one data object cell,
Sending the license object cell to the computer over a network,
A method for permitting access to said data object cell based on information of a related license object cell. The method of claim 9, further comprising receiving a user request for a data object cell. The method of claim 9, further comprising receiving a user request for a license object. 10. The method of claim 9, wherein granting access to the data object cell comprises verifying that a license object cell associated with the data object cell is on the computer. The method of claim 9, wherein the object cell includes at least one data control element and a data object. 14. The method of claim 13, further comprising encrypting at least the data object. The method of claim 9, wherein at least a portion of the license object cell is encrypted. The method of claim 9, further comprising generating a data object cell. The method of claim 9, further comprising generating a license object cell. The method of claim 9, wherein the data object cell and the license object cell are related by at least one unique identifier. A method of managing data objects,
Sending a request for a data object to the first computer,
Receiving a data object cell relating to the requested data object from the first computer;
Sending a request for a license object associated with the data object cell to a second computer;
Receiving a license object cell related to the requested license object from the second computer;
A method for permitting access to the data object cell based on information of the related license object cell. 20. The method according to claim 19, wherein said first computer and said second computer are the same computer. A method of managing data objects,
Receiving a request for a data object from a network node;
Identifying a data object cell associated with the requested data object;
Transmitting the data object cell to the network node;
The method wherein accessing the data object cell requires an associated license object cell. 22. The method of claim 21, further comprising:
Accessing a license object cell related to the data object cell;
Transmitting the license object cell to the network node;
A method wherein the license object cell grants access to at least the data object cell. A method of managing data objects,
Receiving a request for a license object from a network node;
Accessing a license object cell associated with the requested license object;
Transmitting the license object cell to the network node;
A method wherein the license object cell permits access to at least one data object cell. Network
Providing a user node coupled to said network, said user node including a user manager module for requesting the network for data objects and related license objects;
A content manager node is provided coupled to the network, wherein the content server node receives a request for a data object from the network, retrieves the requested data object, and responds to the request for a data object from the network. ,
A license manager node coupled to the network, wherein the content server node receives a request for a related license object from the network, retrieves the requested related license object, and retrieves the related license object from the network. A network that responds to the request for a request. Network
A content manager node is provided that responds to requests for the supply of data objects,
A license manager node is provided responsive to a request for a supply of a license object associated with at least one data object;
A network provided with a user node providing access to said data object with said associated license object. 26. The network of claim 25, wherein the user node further provides a user interface for requesting one or more data objects,
Issuing a request for a selected data object from the content manager node;
A network that determines whether the user node has access to data objects and license objects. A system for managing data objects,
A content module is provided for receiving a request for a data object, retrieving the data object, and transmitting the requested data object;
A system comprising a license module for receiving a request for a license object associated with the data object, extracting a license object associated with the data object, and transmitting the requested license object. A system for managing data objects,
Means for managing the data object are provided,
Means for managing the license object is provided,
A system provided with means for granting access to said data object based at least on a related license object. A method of granting access to a data object,
Data object cell extracting means is provided,
Data object cell transmission means is provided,
License object cell withdrawal means is provided,
A license object cell transmission means is provided;
A method provided with access permission means. A data object cell,
A data object cell provided with data control elements and data objects. 31. The data object cell of claim 30, wherein the data object is encrypted. 31. The data object cell of claim 30, further comprising a cell header. 31. The data object cell according to claim 30, further comprising at least one public certificate. 31. The data object cell according to claim 30, further comprising at least one signature. A license object cell,
A license object cell in which a license control element and a license object are provided. 31. The license object cell of claim 30, wherein the license object is an encrypted license object cell. 31. The license object cell of claim 30, further comprising a cell header. 31. The license object cell according to claim 30, further comprising at least one public certificate. 31. The data object cell according to claim 30, further comprising at least one signature. The database schema,
User data,
Content data,
Database schema that associates license data. 41. The database schema according to claim 40, wherein the user data includes group data. 41. The database schema of claim 40, wherein the content data is provided with publisher data,
Publication data is provided,
Database schema with article data. 41. The database schema according to claim 40, wherein the content data is provided with subscription data. 41. The database schema according to claim 40, wherein the content data is provided with accounting data. 41. The database schema according to claim 40, wherein the license data is provided with issued license data.

Images