【事件の表示】
　特願２０１６−１８１６１６「鍵を送付するための方法および装置」拒絶査定不服審判事件〔平成２９年　２月１６日出願公開，特開２０１７−　３８３７５，請求項の数（１５）〕について，次のとおり審決する。
【結　論】
　原査定を取り消す。
　本願の発明は，特許すべきものとする。
【理　由】
第１．手続の経緯
　本願は，２００５年７月１４日（パリ条約による優先権主張外国庁受理２００４年７月１４日　アメリカ合衆国）を国際出願日とする特願２００７−５２１６７２号の一部を，特許法第４４条第１項の規定により，平成２３年６月１日に新たな特許出願とした特願２０１１−１２３４０４号の一部を，特許法第４４条第１項の規定により，平成２６年７月３１日に新たな特許出願とした特願２０１４−１５６６５３号の一部を，特許法第４４条第１項の規定により，平成２８年９月１６日に新たな特許出願としたものであって，
　平成２８年１０月４日付けで特許法第１８４条の４第１項の規定による明細書，請求の範囲，及び，図面（図面の中の説明に限る）の日本語による翻訳文が提出されると共に審査請求がなされ，同日付けで手続補正がなされ，平成２９年２月１６日付けで手続補正がなされ，平成２９年２月２１日付けで審査官により拒絶理由が通知され，これに対して平成２９年５月１９日付けで意見書が提出されると共に手続補正がなされたが，平成２９年１０月１９日付けで審査官により拒絶査定がなされ，これに対して平成３０年２月１９日付けで審判請求がなされると共に手続補正がなされ，平成３０年５月３０日付けで審査官により特許法第１６４条第３項の規定に基づく報告がなされ，平成３０年８月２０日付けで上申書の提出があったものである。
　
第２．原審拒絶査定の概要
　原審拒絶査定（平成２９年１０月１９日付け拒絶査定）の概要は次のとおりである。
　本願の請求項１〜本願の請求項１５に係る発明は，以下の引用文献１〜引用文献５に基づいて，その発明の属する技術の分野における通常の知識を有する者（以下，「当業者」という。）が容易に発明できたものであるから，特許法第２９条第２項の規定により特許を受けることができない。
引用文献等一覧
１．特開２００４−０４８６７６号公報
２．特表２００２−５１８９３５号公報
３．特開２００１−２５６１９５号公報
４．特開２００３−２７２２８９号公報（周知技術を示す文献）
５．西本友成　ほか，サーバ型放送におけるコンテンツのアクセス制御方式，
　　映像情報メディア学会誌，社団法人映像情報メディア学会，２００４年７月１日，
　　第５８巻　第７号，ｐ．１００３−１００８（周知技術を示す文献）
　
第３．本願発明について
１．本願の請求項１〜本願の請求項１５に係る発明（以下，これを「本願発明１〜本願発明１５」という）は，平成３０年２月１９日付けの手続補正により補正された特許請求の範囲の請求項１〜請求項１５に記載された事項により特定されるものであり，そのうち，本願発明１は，次のとおりのものである。
　
「装置が実行する，ワイヤレス通信システムにおいて１以上の鍵を受信する方法であって，各鍵はある時間期間について有効であり，該方法は，
　　前記装置のプロセッサが，非鍵データを含むメッセージの受信に応答して，前記１以上の鍵を要求すべきかどうかを決定することと，
　　前記プロセッサが，前記１以上の鍵の送付をサーバに要求することと，
　　前記プロセッサが，前記サーバによって次にスケジュールされていた非鍵データメッセージを受信するためのスケジュールされた接続期間中に，前記要求に応答して前記次にスケジュールされていた非鍵データメッセージに前記サーバによって添付された，前記１以上の鍵を受信することと，
　を備える方法。」
　
２．本願発明２〜本願発明１５について
　本願の請求項２〜本願の請求項１０及び本願の請求項１５は，本願の請求項１を直接・間接に引用するものであって，本願発明２〜本願発明１０は，本願発明１を減縮した発明である。
　また，本願発明１１は，本願発明１と，発明のカテゴリが相違する発明であり，
　本願の請求項１２〜本願の請求項１４は，本願の請求項１１を引用するものであって，本願発明１２〜本願発明１４は，本願発明１１を減縮した発明である。
　
第４．引用文献に記載の事項及び引用文献に記載の発明
１．引用文献１について
　原審拒絶査定の拒絶の理由に引用された上記引用文献１には，図面とともに次の事項が記載されている。
　
Ａ．「【００２６】
図１を参照すると，デジタル著作権管理システム（ＤＲＭＳ）の図が示されている。図からわかるように，コンテンツ１０が，アクセス権／コンテンツ使用条件１２と共にパッケージ化され，メディア・サーバ１４にロードされる。コンテンツにアクセスするのに使用される鍵は，コンテンツとは別のコンポーネントとしてＰＣ１８にダウンロードされる。
具体的には，ダウンロード時またはレンダリング時のいずれかに，ライセンス・サーバ１６にアクセスして，コンテンツおよび対応する使用条件の説明へのアクセスの許可を受け取らなければならない。
ウェブ・サーバ２０は，メディア・サーバ１４のコンテンツにアクセスするステップを顧客に進ませるウェブ・ページを提供する。図からわかるように，コンテンツは，ストリーミング配信を介して（たとえばファイルが大きい場合に）配信される。
【００２７】
上で示したように，ＤＲＭＳは，コンテンツと，そのコンテンツを暗号化するのに使用された鍵との同期配信ができない。すなわち，ライセンス・サーバ１６に，別途アクセスしなければならない。そのような形で鍵を提供する時に，適当な鍵が暗号化済みコンテンツと一致しない，あるいは単一の鍵が使用され，セキュリティが弱まる可能性がある。さらに，ライセンス・サーバ１６から鍵を提供するために，バック・チャネルが必要である。」
　
Ｂ．「【００４０】
図８を参照すると，本発明の下での，タイトル鍵の暗号化および暗号化済みコンテンツへの添付が示されている。図からわかるように，圧縮されたコンテンツからなる基本コンテンツ・ストリーム１００が，コンテンツ・ユニット１０２に区分される。各コンテンツ・ユニットに，ヘッダ１０４およびコンテンツ・パケット１０６が含まれる。ヘッダ１０４には，タイム・スタンプ，コンテンツの種類すなわちビデオ，オーディオ，またはそれ以外など，コンテンツを識別するのに役立つ情報が含まれる。ヘッダ１０４は，たとえば，サウンド・データとビデオ・データの同期化に特に役立つ。区分された時に，各コンテンツ・ユニット１０２のヘッダ１０４が，コンテンツ・パケット１０６から構文解析され，コンテンツ・パケット１０６が，タイトル鍵１０８を用いて暗号化されて，暗号化済みコンテンツ・パケット１１４が作られる。その後，鍵暗号化鍵１１０を使用して，タイトル鍵１０８を暗号化し，ヘッダ１０４と共にコンテンツ・パケット１０６に添付する。その後，結果の処理されたコンテンツ・ユニット１１６を，受信側に送信することができる。すなわち，暗号化済みコンテンツ・ユニット，ヘッダ，およびヘッダ拡張（暗号化済みタイトル鍵を含む）を，単一の一体化されたデータ・ストリームとして受信側に配信するか，受信側が保管することができる。したがって，受信側は，コンテンツを解読するのに必要なすべての情報と一緒に，暗号化済みコンテンツを受信または保管する。これによって，前のシステムに関連する同期化問題が回避されるだけではなく，コンテンツのランダム・アクセスも提供される。上で示したように，ＤＲＭＳとＣＡＳの両方が，コンテンツのランダム・アクセスを提供する際に固有の待ち時間（たとえば遅延）を有する。具体的には，本発明の下で送信される各コンテンツ・パケットは，それを暗号化するのに使用されたタイトル鍵と共に「パッケージ化」されるので，受信側は，どのパケットでも，コンテンツ・ストリームにアクセスし，解読することができる。」
　
Ｃ．「【００４１】
本発明は，コンテンツ・ユニットに区分されなければならない基本コンテンツ・ストリームの受信に制限されないことを理解されたい。そうではなく，本発明の教示は，コンテンツがコンテンツ・ユニットとして（たとえば事前に区分されて）受信されるシナリオに適用することができる。また，図８に，図を明瞭にするだけのために１つのコンテンツ・ユニット１０２だけの処理が示されていることと，通常の実施形態で，複数のコンテンツ・ユニット１０２がこの形で処理されることを理解されたい。さらに，複数のコンテンツ・ユニット１０２が処理される時に，各コンテンツ・パケットの暗号化に同一のタイトル鍵を使用する必要がないことを諒解されたい。そうではなく，各コンテンツ・パケットを，異なるタイトル鍵を用いて暗号化することができる。この範囲で，基本コンテンツ・ストリーム１００の暗号化に使用されるタイトル鍵の量は，問題にはならない。というのは，各タイトル鍵が，対応する暗号化済みコンテンツ・パケットに添付される（たとえば暗号化された形で）からである。さらに，図示されてはいないが，図５および６に図示し，それに関して説明したように，コンテンツ使用条件を，暗号化の前にタイトル鍵と組み合わせることができることを諒解されたい。そのような場合には，コンテンツ使用条件およびタイトル鍵の暗号化された組合せが，ヘッダ拡張として暗号化済みコンテンツに添付される。」
　
（１）上記Ａの「コンテンツを暗号化するのに使用された鍵との同期配信ができない」という記載，及び，上記Ｂの「図８を参照すると，本発明の下での，タイトル鍵の暗号化および暗号化済みコンテンツへの添付が示されている」という記載から，
　引用文献１に記載されているのは，
“暗号化済みコンテンツとコンテンツを暗号化するのに使用された鍵との同期配信を行う方法”であることが読み取れる。
　
（２）上記Ａの「具体的には，ダウンロード時またはレンダリング時のいずれかに，ライセンス・サーバ１６にアクセスして，コンテンツおよび対応する使用条件の説明へのアクセスの許可を受け取らなければならない。ウェブ・サーバ２０は，メディア・サーバ１４のコンテンツにアクセスするステップを顧客に進ませるウェブ・ページを提供する」という記載から，
“ユーザが，コンテンツのダウンロードを要求するために，メディアサーバにアクセスする”ことが読み取れる。
　
（３）上記Ｂの「各コンテンツ・ユニットに，ヘッダ１０４およびコンテンツ・パケット１０６が含まれる」という記載，及び，同じく上記Ｂの「コンテンツ・パケット１０６が，タイトル鍵１０８を用いて暗号化されて，暗号化済みコンテンツ・パケット１１４が作られる。その後，鍵暗号化鍵１１０を使用して，タイトル鍵１０８を暗号化し，ヘッダ１０４と共にコンテンツ・パケット１０６に添付する」という記載，並びに，同じく上記Ｂの「暗号化済みコンテンツ・ユニット，ヘッダ，およびヘッダ拡張（暗号化済みタイトル鍵を含む）を，単一の一体化されたデータ・ストリームとして受信側に配信する」という記載から，
“受信側に，暗号化済みコンテンツ・ユニット，ヘッダ，暗号化済みタイトル鍵を含むヘッダ拡張が，配信される”ことが読み取れる。
　
（４）上記Ｃの「そうではなく，各コンテンツ・パケットを，異なるタイトル鍵を用いて暗号化することができる」という記載と，上記（３）において検討した事項から，
“受信側は，複数の暗号化済みコンテンツが配信される場合は，同時に複数の暗号化済みタイトル鍵も配信される”ことを読み取ることができる。
　よって，上記（３），及び，（４）において検討した事項を併せると，上記Ｂ，及び，Ｃで引用した記載からは，
“受信側は，１以上の暗号化済みコンテンツ・ユニットを受信する間に，１以上の暗号化済みタイトル鍵を受信する”ことが読み取れる。
　
　そして，上記（２）で検討した事項における「ユーザ」とは，上記（３），及び，（４）において検討した事項における「受信側」に相当するものであるから，
　以上（１）〜（４）において検討した事項から，引用文献１には，次の発明（以下，これを「引用発明」という）が記載されていると認める。
　
　暗号化済みコンテンツとコンテンツを暗号化するのに使用された鍵との同期配信を行う方法であって，
　受信側が，コンテンツのダウンロードを要求するために，メディアサーバにアクセスし，
　受信側は，１以上の暗号化済みコンテンツ・ユニットを受信する間に，１以上の暗号化済みタイトル鍵を受信する，方法。
　
２．引用文献２について
　原審拒絶査定の拒絶の理由に引用された上記引用文献２には，図面とともに次の事項が記載されている。
　
Ｄ．「【００１５】
    【実施例】
（詳細な説明）
　以下の説明はセルラ式無線電話システムに関して書かれているが，出願人の発明はその環境に限定されないということは理解されるであろう。また，以下の説明はＴＤＭＡセルラ式通信システムであるＩＳ−１３６規格準拠という環境において記載されるが，（上述の通り）本発明が例えばＧＳＭやＰＤＣ，さらにＩＳ−９５のようなＣＤＭＡを用いるような他の標準に従って設計された他のディジタル通信アプリケーションにおいても実施可能であることは本発明の当業者には理解されよう。」
　
Ｅ．「【００２５】 
　本発明は移動局１２０のような従来のリモート端末にも確かに適用可能であるけれども，他のタイプのリモート受信装置に対しても適用可能である。例えば，本発明はリモート装置が受信及び送信能力の両方を持っているようなシステムに適用可能である一方，受信専用の装置，例えば伝統的な呼び出しリモート装置に対しても適用可能である。実際，（１）報知サービスが記述される情報の形式，例えばスポーツスコア，証券相場等はそれ自体リモート装置の電送能力を供給しないこと，（２）送信機能を除去することによりリモート装置のさらなる小型化及び低価格化が可能であることを考慮すると，少なくともいくつかの受信専用のリモート装置を提供することは実体的な動機が存在する。」 
 　
 Ｆ．「【００４４】 
　状態変数Ｂ−ＳＡＣ実施例は利用の容易性とアクセス制御との有益なバランスをもたらすが，いくつかのサーブビスプロバイダ／システムオペレータはさらなるアクセス制御及び，この種の報知サービスに調和された，あるレベルのデータの完全性を希望するだろう。従って，本発明の別の実施例によれば，サービスプロバイダによって報知される情報は暗号化されてよい。リモート装置は，例えば毎月毎に変更可能な復号（サービス）鍵をダウンロード可能である。ダウンロードのための特別なテレサービスを開発してもよいし，ＥＩＡ／ＴＩＡ ＩＳ−１３６に示されるＯＴＡテレサービス(Over-the-Air Activation TeleService: ＯＡＴＳ）における追加エレメントであってもよい。復号鍵に加え，有効時間も含まれていて良い。あるいは，キーインデックスが供給される。報知情報サービスチャネルそれ自身（例えば証券相場）又はＢＣＣＨの汎用位置(general place)において，現在のキーインデックス又は有効時間が供給される。これによって，リモート装置が自らが有するサービス鍵が有効であることを判定することが可能になる。キーインデックス又は有効時間が装置内にストアしたデータと一致しない場合，ユーザは警告を受ける。」
　
　したがって，引用文献２には，“セルラ式無線電話システムの移動装置が，コンテンツを復号するための鍵を受信する”という技術的事項が記載されている。
　
３．引用文献３について
　原審拒絶査定の拒絶の理由に引用された上記引用文献３には，図面とともに次の事項が記載されている。
　
Ｇ．「【０１２２】ダウンロード管理プログラム７２８は，代理サーバ５０３からコンテンツ鍵またはコンテンツをダウンロードするとき，そのダウンロードの処理が正常に終了したか否かを判定し，ダウンロードの処理が正常に終了していないと判定された場合，代理サーバ５０３にコンテンツ鍵またはコンテンツの再送を要求する。ダウンロード管理プログラム７２８は，ダウンロードの処理が正常に終了したと判定された場合，配信終了通知を代理サーバ５０３に送信する。」
　
　したがって，引用文献３には，“代理サーバからコンテンツ鍵またはコンテンツをダウンロードするとき，そのダウンロードの処理が正常に終了したか否かを判定し，ダウンロードの処理が正常に終了していないと判定された場合，代理サーバにコンテンツ鍵またはコンテンツの再送を要求する”という技術的事項が記載されている。
　
４．引用文献４について
　原審拒絶査定の拒絶の理由に引用された上記引用文献４には，図面とともに次の事項が記載されている。
　
Ｈ．「【００３１】このデバイス鍵Ｄでタイトル鍵Ｔをタイトル鍵暗号部２５で暗号化し，暗号化タイトル鍵Ｔ’ファイル１７としてハードディスクドライブＨＤＤに記録する。」
　
　したがって，引用文献４には，“暗号化タイトル鍵をファイルとしてハードディスクドライブに記録しておく”という技術的事項が記載されている。
　
５．引用文献５について
　原審拒絶査定の拒絶の理由に引用された上記引用文献５には，図面とともに次の事項が記載されている。
　
Ｉ．「３．開発したＲＭＰシステム
　開発したＲＭＰシステムの概要を図１に示す．
　放送受信時は，現行ＢＳ／ＣＳデジタル放送で使用しているＣＡＳを利用してコンテンツを保護する．コンテンツをスクランブルする・ための鍵は，暗号時と復号時で同じ鍵を用いる共通鍵暗号化方式をとり，秒単位で異なる鍵でコンテンツをスクランブルするスクランブル鍵Ｋｓ，放送事業者個別のワーク鍵Ｋｗ，受信機のセキュリティモジュールに固有のマスター鍵Ｋｍの三つの暗号鍵により，放送受信時のコンテンツを保護する．
　本ＲＭＰシステムでは，コンテンツを放送受信時に視聴制御できるだけでなく，蓄積コンテンツ再生時にも制御可能とする．このために，現行ＢＳデジタル放送のＣＡＳに対して以下の方式拡張を行った．
（１）コンテンツ単位の視聴制御を実現するために，コンテンツ鍵Ｋｃを導入し鍵構造を４重化する
（２）セキュリティモジュール固有鍵Ｋｍ’を導入し，コンテンツを蓄積する際にはＫｃをＫｍ’で再暗号化して蓄積する
（３）放送事業者が付与したコンテンツの利用条件情報であるＲＭＰＩ（ＲＭＰＩｎｆｏｒｍａｔｉｏｎ：利用可能期間など）にしたがってスクランブル鍵Ｋｓを復号化し，コンテンツをデスクランブルする
　蓄積コンテンツ再生時は，Ｋｓ，Ｋｗ，Ｋｍにコンテンツ鍵Ｋｃを加え，四つの暗号鍵によりコンテンツを保護する（以下，４重鍵方式）．
　コンテンツ鍵Ｋｃは，コンテンツに対して固有の鍵であり，ＲＭＰＩと併せて，共通情報であるＥＣＭ（Ｅｎｔｉｔｌｅｍｅｎｔ  Ｃｏｎｔｒｏｌ  ｅｓｓａｇｅ）セクション（以下，Ｋｃ配布用ＥＣＭ）としてコンテンツに多重化する．ＲＭＰＩは，蓄積したコンテンツの利用期間を制御するために，コンテンツ鍵Ｋｃの利用可能期間を設定する．予めワーク鍵Ｋｗが付与されている複数の受信機に対して，Ｋｃ配布用ＥＣＭを同時に送出することができるので，本方式は，１対多のコンテンツ伝送である放送に適している．このＥＣＭには，暗号化部内に改竄検出用コードがあり，鍵情報などを不正に改竄することが困難な構造となっている（図２）．
　コンテンツを蓄積する場合，受信したＫｃ配布用ＥＣＭを，セキュリティモジュール内で復号化し，固有鍵Ｋｍ’で再暗号化して，暗号化したコンテンツと併せて蓄積装置に蓄積する．なお，スクランブル鍵Ｋｓは，コンテンツ鍵Ｋｃで暗号化されたＥＣＭ（以下，ＥＣＭ−Ｋｃとする）として多重化する．固有鍵Ｋｍ’で再暗号イヒすることで，受信機に共通の共通情報として配信されたコンテンツ鍵Ｋｃを受信機固有の鍵情報にすることができる．また，Ｋｃ配布用ＥＣＭと併せて，現行のデジタル放送で用いられているＥＣＭ（以下，ＥＣＭ−Ｋｗとする）を送出することで，放送受信と蓄積後視聴時，双方のコンテンツ保護を実現する．
　蓄積したコンテンツを再生する場合は，再暗号化したＫｃ配布用ＥＣＭをセキュリティモジュール内で復号してコンテンツ鍵Ｋｃを取得し，ＥＣＭ−Ｋｃを復号してスクランブル鍵Ｋｓをセキュリティモジュールから得ることで，視聴可能となる．その際，セキュリティモジュールは，ＲＭＰＩ内のコンテンツ鍵Ｋｃの利用可能期間を抽出して現在日時と比較し，利用可能期間を超過している場合は，復号されたスクランブル鍵Ｋｓの受信機への送出を停止する．このＲＭＰＩは，コンテンツ鍵Ｋｃと共に暗号化されているため，不正にＲＭＰＩを削除・改竄することは困難である．」（１００４（１３４）頁右欄４行〜１００５（１３５）頁左欄３７行）
　
　したがって，引用文献５には，“蓄積したコンテンツの利用期間を制御するために，コンテンツの利用条件情報であるＲＭＰＩによりコンテンツ鍵の利用可能期間を設定する”という技術的事項が記載されている。
　
第５．本願発明と引用発明との対比及び相違点についての判断
１．本願発明１について
（１）対比
ア．引用発明において，「受信側」が，何らかの“装置”である態様を含むことは明らかであり，引用発明における「暗号化済みコンテンツとコンテンツを暗号化するのに使用された鍵との同期配信を行う方法」は，「受信側」が，「１以上の暗号化済みタイトル鍵を受信する」態様を含むものであるから，
　本願発明１における「装置が実行する，ワイヤレス通信システムにおいて１以上の鍵を受信する方法」と，
“装置が実行する，１以上の鍵を受信する方法”である点で共通する。
　
イ．上記ア．で検討したとおり，引用発明は，「受信側」が，「装置」である態様を含むものであるから，「受信側」が，「プロセッサ」を構成要素として含む態様を含むものである。
　そして，引用発明において，「受信側が，コンテンツのダウンロードを要求するために，メディアサーバにアクセス」する際には，受信側は，１以上の「コンテンツのダウンロードを要求する」態様を含むことになるので，前記工程は，「受信側」が，どの「コンテンツのダウンロードを要求」するか“選択する”工程を含むことは明らかである。そして，引用発明においては，「コンテンツのダウンロードの要求をする」ことで，該「コンテンツを暗号化するのに使用された鍵」も一緒に「ダウンロード」されることになるから，引用発明においては，「コンテンツのダウンロードを要求する」ことと，「コンテンツの暗号化するのに使用された鍵」の「ダウンロードを要求する」こととは同じことであると言える。 
　そうであるとすると，引用発明における「受信側」が，本願発明１における「装置のプロセッサ」に相当するので， 
　引用発明における「受信側が，コンテンツのダウンロードを要求するために，メディアサーバにアクセス」すること， 
　本願発明１における「装置のプロセッサが，前記１以上の鍵を要求するか否かを決定することと
　装置のプロセッサが，前記１以上の鍵の送付をサーバに要求すること」こととは， 
“装置のプロセッサが，１以上の鍵を要求することを選択することと，
　前記プロセッサが，前記１以上の鍵の送付をサーバに要求すること”である点で共通する。 
　
ウ．引用発明における「暗号化済みコンテンツ」が，本願発明１における「非鍵データ」に相当し，引用発明において「１以上の暗号化済みタイトル鍵」は，「１以上の暗号化済みコンテンツ・ユニットを受信する間」，即ち，「受信側」と，「メディアサーバ」とが，“接続されている期間中”に受信されるものであるから， 
　引用発明における「受信側が，コンテンツのダウンロードを要求するために，メディアサーバにアクセスし， 
　受信側は，１以上の暗号化済みコンテンツ・ユニットを受信する間に，１以上の暗号化済みタイトル鍵を受信する」と， 
　本願発明１における「サーバによって次にスケジュールされていた非鍵データメッセージを受信するためのスケジュールされた接続期間中に，前記要求に応答して前記次にスケジュールされていた非鍵データメッセージに前記サーバによって添付された，前記１以上の鍵を受信する」とは， 
“プロセッサが，非鍵データを受信するためにスケジュールされた接続期間中に前記１以上の鍵を受信する”点で共通する。 
　
エ．　以上，ア．〜ウ．において検討した事項から，本願発明１と，引用発明との，一致点，及び，相違点は，次のとおりである。 
　
 ［一致点］
“装置が実行する，１以上の鍵を受信する方法であって，
　前記装置のプロセッサが，１以上の鍵を要求することを選択することと，
 　前記プロセッサが，前記１以上の鍵の送付をサーバに要求すること
　前記プロセッサが，非鍵データを受信するためにスケジュールされた接続期間中に前記１以上の鍵を受信することと，
　を備える方法。”
　
 ［相違点１］
“１以上の鍵を受信する”ことに関して，
　本願発明１においては，「ワイヤレス通信システム」において行われるものであるのに対して，
　引用発明においては，「ワイヤレス通信システム」である点についての言及がない点。
　
 ［相違点２］
“鍵”に関して，
　本願発明１においては，「各鍵はある時間期間について有効であ」るのに対して，
　引用発明においては，「暗号化するのに使用された鍵」の“有効期限”については，特に言及されていない点。
　
［相違点３］
　本願発明１においては，「装置のプロセッサが，非鍵データを含むメッセージの受信に応答して，前記１以上の鍵を要求すべきかどうかを決定する」のに対して，
　引用発明においては，「鍵を要求すべきかどうかを決定する」点について言及されていない点。
　
［相違点４］
“非鍵データを受信するためにスケジュールされた接続期間”に関して，
　本願発明１においては，「サーバによって次にスケジュールされていた非鍵データメッセージを受信するためのスケジュールされた接続期間」であるのに対して，
　引用発明においては，「１以上の暗号化済みタイトル鍵」を，“次にスケジュールされていた１以上の暗号化済みコンテンツ・ユニットを受信するためのスケジュールされた期間”に受信することについては，特に言及されていない点。
　
（２）相違点についての当審の判断
　上記［相違点４］について検討すると，上記「第４．引用文献に記載の事項及び引用文献に記載の発明」において記載を引用した，引用文献２〜引用文献５の何れにも，［相違点４］に係る構成に関して記載されておらず，当業者といえども，引用発明及び引用文献２〜引用文献５に記載された技術的事項から，［相違点４］に係る構成を容易に想到することはできない。
したがって，他の相違点について判断するまでもなく，本願発明１は，当業者であっても，引用発明及び引用文献２〜引用文献５に記載された技術的事項に基づいて容易に発明できたものとはいえない。
　
２．本願発明２〜本願発明１０及び本願発明１５について
　本願発明２〜本願発明１０及び本願発明１５も，本願発明１における［相違点４］に係る構成を有するものであるから，本願発明１と同じ理由により，当業者であっても，引用発明及び引用文献２〜引用文献５に記載された技術的事項に基づいて容易に発明できたものとはいえない。
　
３．本願発明１１〜本願発明１４について
　本願発明１１〜本願発明１４は，本願発明１，本願発明２，本願発明４，及び，本願発明５に対応する方法の発明であり，本願発明１の［相違点４］に係る構成を備えるものであるから，本願発明１と同様の理由により，当業者であっても，引用発明及び引用文献２〜引用文献５に記載された技術的事項に基づいて容易に発明できたものとはいえない。
　
第６．むすび
　以上のとおり，本願発明１〜本願発明１５は，当業者が引用発明及び引用文献２〜引用文献５に記載された技術的事項に基づいて容易に発明をすることができたものではない。したがって，原査定の理由によっては，本願を拒絶することはできない。
　また，他に本願を拒絶すべき理由を発見しない。
　
　よって，結論のとおり審決する。