【事件の表示】
　特願２００１−　９４４１９「配信システム及び配信方法」拒絶査定不服審判事件〔平成１４年１０月１１日出願公開、特開２００２−２９７４７７〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　手続の経緯と本願発明
　本願は，平成１３年３月２８日の出願であって，平成１６年１１月２４日付けで拒絶査定され，これに対して，同年１２月２７日に拒絶査定不服審判が請求されるとともに，平成１７年１月２６日付けで手続補正がされ，平成２０年１２月３日付けで当審において拒絶理由が通知され，これに対して平成２１年２月３日付けで手続補正がされたものである。そして，その請求項１に係る発明は，平成２１年２月３日付けの手続補正書により補正された明細書及び図面の記載から見て，特許請求の範囲の請求項１に記載された次のとおりのものと認める。（以下「本願発明」という。）
　
「第１の管理者側に設けられた管理手段と，
　複数のユーザ側にそれぞれ設けられた複数の端末手段と，
　複数の第２の管理者側にそれぞれ設けられ，上記管理手段及び端末手段に所定のネットワークを介して接続される複数の送信手段と，を有し，
　上記複数の端末手段の各々は，暗号化コンテンツを復号化して再生し，
　上記複数の送信手段の各々は，上記ユーザの各端末手段に対して，上記暗号化コンテンツを復号化するためのコンテンツキーを上記所定のネットワークを介して送信すると共に，このコンテンツキーの送信回数を示すログ情報を記録し，
　上記管理手段は，上記各送信手段で記録されたログ情報を上記所定のネットワークを介して回収すると共に，上記各送信手段から回収したログ情報に基づいて，上記第１の管理者から上記第２の管理者のそれぞれに対する課金処理を行うこと
　を特徴とする配信システム。」
　
第２　引用刊行物記載の発明
　当審の拒絶理由に引用された，特開２０００−７８５５５号公報（平成１２年３月１４日出願公開，以下「刊行物１」という。）には，図面と共に以下の事項が記載されている。
　
Ａ．「【００１３】図１に示すデータサービスシステムにおいて，データ送信装置１のデータサーバ１０は，例えばオーディオデータやビデオデータ等だけでなく，コンピュータプログラム等の各種データをディジタルコンテンツとして格納してなるものである。本実施の形態では，特にデータサービスを例に挙げているため，当該データサーバ１０から取り出されるディジタルコンテンツをコンピュータプログラム等の各種データ（以下，単にデータとする）として説明する。このデータサーバ１０から出力されたデータは，暗号化モジュール１１に送られる。
【００１４】暗号化モジュール（データエンコーダ）１１は，鍵管理モジュール１２から送られてきた暗号鍵を用いて，上記データサーバ１０からのデータを暗号化し，当該暗号化データを，例えば衛星回線やディジタルＣＡＴＶ回線等の大容量且つ高速の通信回線に送信（配信）する。
【００１５】ここで，本実施の形態では，通信回線として衛星ディジタル放送に使用される衛星回線３を用いた場合を例に挙げている。したがって当該暗号化モジュール１１では，上記データサーバ１０からのデータをＩＰ（Internet Protocol）等のデータパケットにパケット化（すなわちＩＰデータグラムを生成）して暗号化し，この暗号化データ（以下，セクションデータとする）に所定の付加情報（例えばＭＡＣ（Media Access Control）アドレスを含むヘッダ等）を付加したデータを，ディジタルオーディオ／ビデオサービスで用いられているようなＴＳ（Transport Stream）パケットに重畳させ，当該ＴＳパケットを衛星回線３に送信（すなわち配信）するようにしている。なお，このデータサーバ１０におけるＩＰデータグラムの生成及び暗号化モジュール１１における暗号化処理（セクションデータの生成処理）の詳細及び具体的構成，当該セクションデータ及びそのヘッダに含まれるＭＡＣアドレス等の詳細については後述する。
【００１６】鍵管理モジュール１２は，上記暗号化モジュール１１におけるＩＰデータグラムの暗号化に使用する暗号鍵を管理する。この鍵管理モジュール１２からの暗号鍵は，電話回線やＩＳＤＮ（Integrated Services Digital Network：統合サービスディジタル通信網）等を使用した地上回線を介して伝送される。本実施の形態では，当該地上回線として，電話回線やＩＳＤＮ等を使用したインターネット４を例に挙げている。上記鍵管理モジュール１２がインターネット４を介して受信側端末１７に送信する暗号鍵は，セキュリティ確保のため当然暗号化されているものとする。当該鍵管理モジュール１２が管理する暗号鍵，及びこの暗号鍵の送信並びに暗号化等の詳細については後述する。
【００１７】受信側端末１７の鍵受信モジュール１６は，上記インターネット４を介して送信されてきた上記暗号鍵を受信して復号（暗号解読）し，当該受信及び復号した暗号鍵を受信側端末１７内の復号化モジュール１５に転送する。
【００１８】復号化モジュール１５は，上記衛星回線３を介して受信したデータのＴＳパケットから前記セクションデータを取り出し，当該セクションデータのヘッダに含まれるＭＡＣ（Media Access Control）アドレスに基づいて，対応する暗号鍵を鍵受信モジュール１６から受け取り，当該暗号鍵を用いて上記セクションデータ内の暗号化されたＩＰデータグラムの暗号解読（データデコード）を行う。なお，当該復号化モジュール１５における暗号解読の詳細については後述する。
【００１９】データ表示リクエストモジュール１７は，提供を受けたいデータのリクエストを，例えばインターネット４を通じてデータ送信装置１に送信し，また，必要に応じて表示を行う。
【００２０】データ送信装置１のデータモニタシステム１３は，個々の契約者の受信側端末２に対して送信（配信）されるデータ量（情報量）や通信路が確立された接続時間などをモニタする。例えば送信されるデータ量をモニタする場合には，送信されるデータのアドレス毎のデータ量或いはパケット毎のデータ量を集計し，また，接続時間をモニタする場合には，図示しない内部時計からの時間情報に基づいて当該接続時間を集計する。
【００２１】また，データ送信装置１の顧客管理モジュール１４は，上記鍵管理モジュール１２に対して指令を行い，当該鍵管理モジュール１２による暗号鍵の配信をどのように行うかを管理する。また，顧客管理モジュール１４は，契約者毎の契約形態やデータ単位毎或いはデータ種別毎の課金形態によって様々な課金方法の管理を行うと共に，それら契約形態や課金方法に基づいて契約者毎の課金情報の集計及び管理を行う。さらに，顧客管理モジュール１４は，金融／クレジット会社等の与信／決済システム５と回線が繋がっており，したがって，当該顧客管理モジュール１４は，当該与信／決済システム１７を通して，上記集計された課金情報に基づいた個々の契約者への請求書の発行及び入金管理等を行う。」
　
Ｂ．「【００２９】ただし，暗号鍵を変更せずに常に同一の暗号鍵を使用していると，例えばハッカー等によって暗号鍵が解明される恐れがある為，一般にはあるタイミングで暗号鍵を変更する必要がある。
【００３０】上記暗号鍵を変更するタイミングとしては，以下の３種類の変更タイミング（第１〜第３の暗号鍵変更タイミング）が考えられる。
【００３１】「第１の暗号鍵変更タイミング」暗号鍵の不正解読等の問題が発生するまで暗号鍵の変更を行わない。言い換えれば，問題が発生したタイミングで暗号鍵を変更する。
【００３２】「第２の暗号鍵変更タイミング」通信路（セッション）が確立される毎に暗号鍵を配信する。すなわち，通信路が確立される毎のタイミングで異なる暗号鍵を配信する。
【００３３】「第３の暗号鍵変更タイミング」通信路（セッション）が確立されて通信を行っている時間中は定期的に暗号鍵の配信を行う。すなわち，通信路が確立されて通信を行っている時間中の定期的なタイミングで異なる暗号鍵を配信する。」
　
Ｃ．「【００３５】次に，上記第２の契約形態（従量制課金）にて契約がなされた場合，すなわち，受信するデータ量によって課金を行う場合は，契約者（受信側端末２）が受信したデータ量（言い換えればデータ送信装置１が送信したデータ量）を計測しなければならない。このデータ量の計測方法としては，以下の３種類の計測方法（第１〜第３のデータ量計測方法）が考えられる。
【００３６】「第１のデータ量計測方法」通信路（セッション）が確立されて通信を行っている時間中は定期的に暗号鍵の配信を行う上記第３の暗号鍵変更タイミングの場合において，通信路（セッション）が確立されている期間中に配信される暗号鍵の配信回数を数え，この配信回数からデータ量を計測する。
【００３７】「第２のデータ量計測方法」通信路（セッション）が確立されている期間の接続時間を計り，この接続時間からデータ量を計測する。
【００３８】「第３のデータ量計測方法」各通信路（セッション）毎の実際のデータ伝送量を計測する。例えば送信されるアドレス毎或いはパケット数からデータ量を計測する。」
　
Ｄ．「【００４７】先ず最初に，前記第１の契約形態（フラット／定額制課金）の場合の顧客管理モジュール１４における課金処理の流れについて説明する。
【００４８】契約者（受信側端末２）から通信路（セッション）確立の要求（リクエスト）がインターネット４等の地上回線を経由してなされた場合，このリクエストは一旦，鍵管理モジュール１２に転送される。当該リクエストを受け取った鍵管理モジュール１２は，顧客管理モジュール１４の顧客認証／鍵管理モジュール制御部２３に対して，暗号鍵の配信要求を行う。
【００４９】顧客認証／鍵管理モジュール制御部２３は，顧客データベース２１に格納した顧客情報を用いて，このリクエストを行った契約者の契約情報をチェックし，暗号鍵を与えて良いか否かを判断し，与えて良いと判断された場合は，その顧客情報に記述された鍵配信の形態と合わせて，暗号鍵の配信を鍵管理モジュール１２に指示する。また同時に，顧客認証／鍵管理モジュール制御部２３は，利用履歴ログ収集部２４に対して当該リクエストを行った契約者（受信側端末２）の利用履歴を登録し，利用料課金処理部２５に対して例えば毎月のある期日にその利用状況に応じた課金処理を行い，さらに請求・収納・支払・滞納管理部２６を介して銀行やクレジット会社等の与信／決済システム５に対して契約者への請求書の発行依頼等を行う。
【００５０】次に，前記第２の契約形態（従量制課金）を行う場合の顧客管理モジュール１４における課金処理の流れについて説明する。
【００５１】当該第２の契約形態のように，伝送された情報量（前記暗号鍵の配信回数や接続時間，データ伝送量）に応じた課金を行う場合には，前述したように図１の鍵管理モジュール１２における暗号鍵の配信回数や，図１のデータモニタシステム１３におけるアドレス毎のデータ量（或いはパケット数）又は接続時間，データ伝送量等の集計情報の取得／集計結果が，顧客認証／鍵管理モジュール制御部２３に転送される。顧客認証／鍵管理モジュール制御部２３では，この集計情報の取得／集計結果に基づいて，利用履歴ログ収集部２４に対して当該データの提供を受けた契約者（受信側端末２）の利用履歴のログを取り，利用料課金処理部２５に対して例えば毎月のある期日にその利用状況に応じた課金処理を行い，請求・収納・支払・滞納管理部２６を介して与信／決済システム５に対して契約者への請求書の発行依頼等を行う。」
　
　以上の記載によれば，刊行物１には，次の発明（以下，「刊行物１発明」という。）が記載されている。
　
「データ送信装置１と受信側端末２は高速の通信回線及びインターネットなどの地上回線で接続され，
　データ送信装置１は，ディジタルコンテンツを格納するデータサーバ１０，データサーバ１０からのデータを鍵管理モジュール１２から送られてきた暗号鍵を用いて暗号化する暗号化モジュール１１，個々の契約者の受信側端末２に対して送信（配信）されるデータ量などをモニタするデータモニタシステム１３，顧客管理モジュール１４，顧客データベース２１，顧客認証／鍵管理モジュール制御部２３，利用履歴ログ収集部２４，利用料課金処理部２５を備え，
　暗号化したデータを高速の通信回線に送信（配信）し，鍵管理モジュール１２からの暗号鍵は暗号化してインターネット等の地上回線を使用して伝送し，
　受信側端末２の鍵受信モジュール１６は，暗号鍵を復号し，復号化モジュール１５は暗号鍵を鍵受信モジュール１６から受け取り，当該暗号鍵を用いて受信したデータの暗号解読を行い，
　受信側端末２から通信路（セッション）確立の要求（リクエスト）が地上回線を経由してなされた場合，このリクエストは一旦，鍵管理モジュール１２に転送され，当該リクエストを受け取った鍵管理モジュール１２は，顧客管理モジュール１４の顧客認証／鍵管理モジュール制御部２３に対して，暗号鍵の配信要求を行い，
　顧客認証／鍵管理モジュール制御部２３は，顧客データベース２１に格納した顧客情報を用いて，このリクエストを行った契約者の契約情報をチェックし，暗号鍵を与えて良いか否かを判断し，与えて良いと判断された場合は，その顧客情報に記述された鍵配信の形態と合わせて，暗号鍵の配信を鍵管理モジュール１２に指示し，
　伝送された情報量（前記暗号鍵の配信回数や接続時間，データ伝送量）に応じた課金を行う場合には，鍵管理モジュール１２における暗号鍵の配信回数や，データモニタシステム１３におけるアドレス毎のデータ量（或いはパケット数）又は接続時間，データ伝送量等の集計情報の取得／集計結果が，顧客認証／鍵管理モジュール制御部２３に転送され，
　顧客認証／鍵管理モジュール制御部２３では，この集計情報の取得／集計結果に基づいて，利用履歴ログ収集部２４に対して当該データの提供を受けた契約者（受信側端末２）の利用履歴のログを取り，利用料課金処理部２５に対してその利用状況に応じた課金処理を行い、請求・収納・支払い・滞納管理部２６を介して与信／決裁システム５に対して契約者への請求書の発行依頼等を行うデータサービスシステム。」
　
　同じく引用した，特開平８−１１１６７１号公報（平成８年４月３０日出願公開，以下「刊行物２」という。）には，図面と共に以下の事項が記載されている。
　
　「【００２４】図３は本発明の実施例のノードの説明図であり，ネットワークとサービスセンタとの間のトラヒックを低減する場合の加入者収容のノード１６の構成を示す。同図に於いて，３１はコピー部，３２はコピー制御部，３３は暗号化部，３４は公開鍵処理部，３５はリクエスト受付部である。コピー部３１は，データをコピーして暗号化部３３に加えるもので，コピーが完了するまでデータを一時的に蓄積できる容量のメモリを備えている。
【００２５】図２に於ける加入者１３を収容したノード１６に，図３に示す構成を設けた場合，このノード１６に収容された加入者１３からのリクエストに対して，サービスセンタ１１では，暗号化部１５に於けるデータの暗号化を中止し，蓄積部１４から読出したデータをそのまま送信部２２から送出する。又ネットワーク１２の加入者を収容した総てのノード１６にコピー部３１や暗号化部３３等の構成を備えた場合は，サービスセンタ１１の暗号化部１５を省略することができる。
【００２６】加入者が複数台の再生・記録装置を備えて，同一のデータをサービスセンタに対してリクエストした場合，ノードのリクエスト受付部３５でリクエスト数を保持し，サービスセンタに対してはデータ名等のリクエストのみを送出する。サービスセンタは，このリクエストに従ったデータを蓄積部１４から読出し，暗号化しないで送信部２２から送出する。
【００２７】加入者を収容したノードでは，リクエスト受付部３５からコピー制御部３２に，リクエストした加入者番号等とリクエスト数とを通知し，コピー制御部３２はコピー部３１を制御して，サービスセンタからのデータをリクエスト数だけコピーし，又コピー制御部３２は加入者番号等に対応した秘密鍵に対応する公開鍵を公開鍵処理部３４から暗号化部３３に加え，リクエストされたデータをそれぞれ暗号化して送出する。
【００２８】例えば，図１に示す加入者３−１のように，複数台の再生・記録装置８を有する場合に，複数の同一データのリクエストを行った場合，単一の加入者３−１の番号のみでなく，複数台の再生・記録装置８についての情報をそれぞれ所定の順序で送出し，ノードのコピー制御部３２は，その送出順序に従って公開鍵を公開鍵処理部３４から暗号化部３３に加えて暗号化し，加入者３−１では，受信順序に従って暗号化データを各再生・記録装置８に順次分配し，自再生・記録装置に於いてのみ復号できるデータを受信処理するように構成することができる。
【００２９】従って，複数のデータのリクエストがあっても，同一のデータについては，サービスセンタとネットワークとの間では１データの転送のみで済むから，サービスセンタの処理負担の軽減とネットワークのトラヒックの低減とを図ることができる。
【００３０】図４は本発明の実施例のサービスセンタとノードとの説明図であり，加入者を収容したノードは，コピー部４１とコピー制御部４２と暗号化部４３と公開鍵処理部４４とを備え，サービスセンタ４５は，各種データを蓄積した蓄積部４６と加入者からネットワークを介したリクエストを受付けるリクエスト受付部４７を備えている。
【００３１】サービスセンタ４５のリクエスト受付部４７は，単一の加入者からの複数の同一データのリクエスト又は複数の加入者から同一のデータのリクエストがあった場合，蓄積部４６からそのデータを検索して読出して送出し，且つリクエスト数及び加入者番号等の情報を送出する。加入者を収容したノードは，コピー部４１にデータが加えられ，リクエスト数及び加入者番号等の情報がコピー制御部４２に加えられる。
【００３２】コピー制御部４２は，リクエスト数に従ってコピー部４１を制御して，サービスセンタからのデータをコピーし，暗号化部４３に加える。又公開鍵処理部４４を制御して，加入者対応又は再生・記録装置対応の秘密鍵に従った公開鍵を暗号化部４３に加える。従って，暗号化部４３は，コピーしたデータ対応に公開鍵処理部４４からの公開鍵で暗号化し，加入者に送出する。
【００３３】この実施例に於いても，サービスセンタの処理負担を軽減し，且つネットワークとの間のトラヒックの低減を図ることができる。又ノードは，サービスセンタからの指令に従ってデータのコピー等を行うものであるから，比較的簡単な構成で実現できる。又サービスセンタに於いてリクエスト数を把握して課金処理等を容易に行うことができる利点がある。
【００３４】
【発明の効果】以上説明したように，本発明は，加入者３−１〜３−ｎに於ける再生・記録装置８対応に，予め秘密鍵を復号化部９に設定し，再生時のみ復号化部９で復号する構成とし，サービスセンタ１に対してリクエストしたデータは，ネットワーク２を介して秘密鍵に対応した公開鍵で暗号化するから，加入者３−１〜３−ｎ側で無断で複製したとしても，他の再生・記録装置８に於いては秘密鍵が異なるから復号できないことになる。従って，著作権の問題を解決することができる。
【００３５】又加入者３−１〜３−ｎを収容したネットワークのノード６に，データのコピー機能と暗号化機能とを設けて，同一のデータに対する複数のリクエストに対して，サービスセンタ１は単一のデータをノード６に転送し，ノード６に於いてリクエスト数に従ったデータ数にコピーし，且つそれぞれ加入者３−１〜３−ｎの再生・記憶装置８の秘密鍵に対応する公開鍵で暗号化して加入者に送出するもので，サービスセンタ１の処理負担を軽減し，且つネットワーク２のノード６との間のトラヒックを低減することができる利点がある。
【００３６】又サービスセンタ１に於いて，リクエスト送出の加入者及び同一のデータのリクエスト数を管理し，加入者３−１〜３−ｎを収容したネットワーク２のノード６に，リクエストに対応したデータとリクエスト数とを送出し，ノード６は，サービスセンタ１から通知されたリクエスト数に従ってデータをコピーし，それぞれ加入者の秘密鍵に対応する公開鍵で暗号化して送出するもので，サービスセンタ１とネットワーク２のノード６との間のトラヒックを低減すること共に，サービスセンタ１に於いて加入者のリクエスト管理が可能となり，課金等の処理も容易となる利点がある。」
　
　以上の記載によれば，刊行物２には，次の発明（以下，「刊行物２発明」という。）が記載されている。
　
「加入者を収容したネットワークのノードは，コピー部４１とコピー制御部４２と暗号化部４３と公開鍵処理部４４とを備え，サービスセンタ４５は，各種データを蓄積した蓄積部４６と加入者からネットワークを介したリクエストを受付けるリクエスト受付部４７を備え，
　サービスセンタ４５のリクエスト受付部４７は，単一の加入者からの複数の同一データのリクエスト又は複数の加入者から同一のデータのリクエストがあった場合，蓄積部４６からそのデータを検索して読出して送出し，且つリクエスト数及び加入者番号等の情報を送出し，
　加入者を収容したノードは，コピー部４１にデータが加えられ，リクエスト数及び加入者番号等の情報がコピー制御部４２に加えられ，コピー制御部４２は，リクエスト数に従ってコピー部４１を制御して，サービスセンタからのデータをコピーし，暗号化部４３に加え，公開鍵処理部４４を制御して，加入者対応の秘密鍵に従った公開鍵を暗号化部４３に加え，暗号化部４３は，コピーしたデータ対応に公開鍵処理部４４からの公開鍵で暗号化し，加入者に送出するシステム。」
　
第３　対比
　本願発明と刊行物１発明とを対比する。
　刊行物１発明のデータサービスシステムは，データを顧客に配信することを目的としているから，本願発明の配信システムといえる。
　刊行物１発明のデータ送信装置１が送信する暗号化されたデータは，本願発明の暗号化コンテンツに相当する。そして，刊行物１発明の暗号鍵は暗号化されたデータを暗号解読するために使うものであるから，本願発明のコンテンツキーに相当する。
　刊行物１発明の受信側端末２は，暗号鍵を使って受信したデータの暗号解読を行っているから，暗号化コンテンツを復号化していることは明白である。
　刊行物１発明に記載されたデータ送信装置１は，暗号鍵をインターネット等の地上回線を使用して受信端末へ伝送しているから，暗号化コンテンツを復号化するためのコンテンツキーを所定のネットワークを介して送信しているといえる。
　刊行物１発明のデータサービスシステムは複数の契約者にサービスを提供することが一般的であり，配信先として複数の受信端末を持っていることが普通である。そうすると，刊行物１発明においても実質的に，「複数のユーザ側にそれぞれ設けられた複数の端末手段」を備え，「複数の端末手段の各々は，暗号化コンテンツを復号して再生」することが行われるものと解される。
　刊行物１発明では，データ送信装置１が鍵管理モジュール１２、顧客管理モジュール１４、顧客認証／鍵管理モジュール制御部２３及び利用履歴ログ収集部２４を有し、鍵管理モジュール１２が受信側端末２に配信した暗号鍵の配信回数を集計し，集計結果が，顧客認証／鍵管理モジュール制御部２３に転送され，顧客認証／鍵管理モジュール制御部２３では，この集計情報の取得／集計結果に基づいて，利用履歴ログ収集部２４に対して当該データの提供を受けた契約者（受信側端末２）の利用履歴のログを取っており，このことは本願発明においてコンテンツキーの送信回数を示すログを記録することに相当する。また、顧客認証／鍵管理モジュール制御部２３では，利用料課金処理部２５に対してその利用状況に応じた課金処理を行っている。
　上記のように、刊行物１発明のデータ送信装置１は、コンテンツキーの配信を行い、配信回数をログ情報として取り、課金処理を行っているから、本願発明の管理手段及び送信手段に相当する。
　
　したがって，両者の一致点，相違点は次のとおりである。
　
［一致点］
「管理手段及び送信手段と複数の端末手段を有し、
　複数のユーザ側にそれぞれ設けられた複数の端末手段と，
　上記複数の端末手段の各々は，暗号化コンテンツを復号化して再生し，
　管理手段及び送信手段は、上記ユーザの各端末手段に対して，上記暗号化コンテンツを復号化するためのコンテンツキーを所定のネットワークを介して送信すると共に，このコンテンツキーの送信回数を示すログ情報を記録する，
　配信システム。」
　
［相違点１］
　本願発明では，第１の管理者側に設けられた管理手段，複数の第２の管理者側にそれぞれ設けられ，上記管理手段及び端末手段に所定のネットワークを介して接続される複数の送信手段を有しているのに対して，刊行物１発明では，管理手段及び送信手段に相当するデータ送信装置１が端末手段と接続されていることは記載されているが，データ送信装置１が一つの装置であり、第１の管理者側の管理手段と複数の第２の管理者側の送信手段に分かれていない点。
　
［相違点２］
　本願発明では，複数の送信手段の各々が上記ユーザの各端末手段に対して，上記暗号化コンテンツを復号化するためのコンテンツキーを上記所定のネットワークを介して送信すると共に，このコンテンツキーの送信回数を示すログ情報を記録し，管理手段が送信手段で記録されたログ情報を所定のネットワークを介して回収し，各送信手段から回収したログ情報に基づいて，上記第１の管理者から上記第２の管理者のそれぞれに対する課金処理を行っているのに対して，刊行物１発明ではデータ送信装置１が課金処理を行っている点。
　
第４　判断
　上記相違点について検討する。
［相違点１について］
　刊行物２発明は加入者からのリクエストに応じてデータを送出するシステムであるから，本願発明の配信システムに相当する。刊行物２発明は，サービスセンタ，複数のノード，複数の加入者をネットワークで接続し，サービスセンタが暗号化を行う代わりにノードがリクエスト数に応じたデータのコピーと暗号化を行うことによりサービスセンタの負担を軽減し，トラヒックを低減している。刊行物１発明に刊行物２発明を適用して，データ送信装置１の機能を，サービスセンタと複数のノードに分け，相違点１のようにすることは当業者が容易に想到し得ることである。
　
［相違点２について］
　刊行物１発明に刊行物２発明を適用して，データ送信装置１の機能を，サービスセンタと複数のノードに分けるときに，負担軽減やトラヒック低減の目的を考慮して複数の加入者に対してデータを送信するノードにコンテンツキーを送信する機能を持たせることは当業者が容易に想到し得ることであり、そのときに，付随して送信回数を示すログ情報をノードに記録させるようにすることは，当業者が適宜に実施し得ることである。
　また，課金処理に関して出願人は平成２１年２月３日付け意見書において，「（５）また，仮に，（II）受信側端末２の利用履歴のログを取る機能と，（III）利用状況に応じて受信側端末１７のユーザに対して課金処理を行う機能とを，共にサービスセンターに割り当てること，若しくは共にノードに割り当てることが当業者にとって容易に想到可能であったとしても，本願発明のように，管理手段は，各送信手段で記録されたログ情報を所定のネットワークを介して回収すると共に，各送信手段から回収したログ情報に基づいて，第１の管理者から第２の管理者のそれぞれに対する課金処理を行う（上記構成（ｆ））という構成を得ることができないことは明らかです。
　さらに，刊行物２の技術は，サービスセンタの処理負担の軽減とネットワークのトラヒックの低減（段落番号[００２９]，[００３５]）とを目的として，サービスセンタの機能の一部をノードに分散するものであり，サービスセンタの管理者とノードの管理者とが事業主体として相違することを想定したものではありません。このため，サービスセンタからユーザへの課金処理をノードに割り当てることが容易に想到可能であったとしても，サービスセンタからノードに対して課金処理を行うという技術思想については，刊行物２は全く示唆しておらず，この点において，本願発明と刊行物２とは明らかに相違します。
（６）このように，刊行物１及び刊行物２は，各送信手段で記録されたログ情報を所定のネットワークを介して回収する機能と，各送信手段から回収したログ情報に基づいて，第１の管理者から第２の管理者のそれぞれに対する課金処理を行う機能とを送信手段に持たせること（上記構成（ｆ））について，開示も示唆もしていないと思料します。
　すなわち，刊行物１の技術に刊行物２の技術を適用し，送信装置１の機能をサービスセンタと複数のノードとに分け，ノードに送信装置の機能の一部を持たせる場合において，本願発明のように，各送信手段で記録されたログ情報を所定のネットワークを介して回収する機能と，各送信手段から回収したログ情報に基づいて，第１の管理者から第２の管理者のそれぞれに対する課金処理を行う機能とを送信手段に持たせること（上記構成（ｆ））は，単なる設計的な事項ではなく，特有の作用効果を奏するものであり，当業者が容易に想到できないことであると思料します。」と主張している。
　しかし，コンテンツの配信システムを，コンテンツを提供する者，コンテンツをユーザに供給する者，ユーザの３者から構成することは周知（国際公開第００／０７３２９号パンフレットの図１及び第１０頁の図１に関する記載，特開２０００−１８８５９５号公報の図１及び段落００２５から００２８の記載，「ＣａｓｅＳｔｕｄｙ　コンテンツ集め携帯に配信ｉモードの普及で急成長」日経ネットビジネス，Ｎｏ．６３，Ｐ．１２４−１２５（２０００年９月１５日発行））であり，コンテンツを提供する者とコンテンツをユーザに供給する者は異なるのが一般的であるから，刊行物１発明に刊行物２発明を適用して，サービスセンタからノードに課金する構成をとることは当業者が必要に応じて適宜実施し得ることであり，そのために，管理者がログ情報を回収し，ログ情報に基づいて第１の管理者から上記第２の管理者のそれぞれに対する課金処理を行うようにすることに格別な困難性はない。
　
　そして，本願発明のように構成したことによる効果も刊行物１発明，刊行物２発明及び周知技術から予測できる程度のものである。
　
　第５　むすび
　以上のとおり，本願発明は，刊行物１発明，刊行物２発明及び周知技術に基づいて，当業者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができない。
　したがって，本願は他の請求項について論及するまでもなく，拒絶すべきものである。
　
　よって結論のとおり審決する。