• ポートフォリオ機能


ポートフォリオを新規に作成して保存
既存のポートフォリオに追加保存

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 取り消して特許、登録 H04L
管理番号 1346510
審判番号 不服2018-2259  
総通号数 229 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2019-01-25 
種別 拒絶査定不服の審決 
審判請求日 2018-02-19 
確定日 2018-12-11 
事件の表示 特願2016-181616「鍵を送付するための方法および装置」拒絶査定不服審判事件〔平成29年 2月16日出願公開,特開2017- 38375,請求項の数(15)〕について,次のとおり審決する。 
結論 原査定を取り消す。 本願の発明は,特許すべきものとする。 
理由 第1.手続の経緯
本願は,2005年7月14日(パリ条約による優先権主張外国庁受理2004年7月14日 アメリカ合衆国)を国際出願日とする特願2007-521672号の一部を,特許法第44条第1項の規定により,平成23年6月1日に新たな特許出願とした特願2011-123404号の一部を,特許法第44条第1項の規定により,平成26年7月31日に新たな特許出願とした特願2014-156653号の一部を,特許法第44条第1項の規定により,平成28年9月16日に新たな特許出願としたものであって,
平成28年10月4日付けで特許法第184条の4第1項の規定による明細書,請求の範囲,及び,図面(図面の中の説明に限る)の日本語による翻訳文が提出されると共に審査請求がなされ,同日付けで手続補正がなされ,平成29年2月16日付けで手続補正がなされ,平成29年2月21日付けで審査官により拒絶理由が通知され,これに対して平成29年5月19日付けで意見書が提出されると共に手続補正がなされたが,平成29年10月19日付けで審査官により拒絶査定がなされ,これに対して平成30年2月19日付けで審判請求がなされると共に手続補正がなされ,平成30年5月30日付けで審査官により特許法第164条第3項の規定に基づく報告がなされ,平成30年8月20日付けで上申書の提出があったものである。

第2.原審拒絶査定の概要
原審拒絶査定(平成29年10月19日付け拒絶査定)の概要は次のとおりである。

本願の請求項1?本願の請求項15に係る発明は,以下の引用文献1?引用文献5に基づいて,その発明の属する技術の分野における通常の知識を有する者(以下,「当業者」という。)が容易に発明できたものであるから,特許法第29条第2項の規定により特許を受けることができない。

引用文献等一覧
1.特開2004-048676号公報
2.特表2002-518935号公報
3.特開2001-256195号公報
4.特開2003-272289号公報(周知技術を示す文献)
5.西本友成 ほか,サーバ型放送におけるコンテンツのアクセス制御方式,
映像情報メディア学会誌,社団法人映像情報メディア学会,2004年7月1日,
第58巻 第7号,p.1003-1008(周知技術を示す文献)

第3.本願発明について
1.本願の請求項1?本願の請求項15に係る発明(以下,これを「本願発明1?本願発明15」という)は,平成30年2月19日付けの手続補正により補正された特許請求の範囲の請求項1?請求項15に記載された事項により特定されるものであり,そのうち,本願発明1は,次のとおりのものである。

「装置が実行する,ワイヤレス通信システムにおいて1以上の鍵を受信する方法であって,各鍵はある時間期間について有効であり,該方法は,
前記装置のプロセッサが,非鍵データを含むメッセージの受信に応答して,前記1以上の鍵を要求すべきかどうかを決定することと,
前記プロセッサが,前記1以上の鍵の送付をサーバに要求することと,
前記プロセッサが,前記サーバによって次にスケジュールされていた非鍵データメッセージを受信するためのスケジュールされた接続期間中に,前記要求に応答して前記次にスケジュールされていた非鍵データメッセージに前記サーバによって添付された,前記1以上の鍵を受信することと,
を備える方法。」

2.本願発明2?本願発明15について
本願の請求項2?本願の請求項10及び本願の請求項15は,本願の請求項1を直接・間接に引用するものであって,本願発明2?本願発明10は,本願発明1を減縮した発明である。
また,本願発明11は,本願発明1と,発明のカテゴリが相違する発明であり,
本願の請求項12?本願の請求項14は,本願の請求項11を引用するものであって,本願発明12?本願発明14は,本願発明11を減縮した発明である。

第4.引用文献に記載の事項及び引用文献に記載の発明
1.引用文献1について
原審拒絶査定の拒絶の理由に引用された上記引用文献1には,図面とともに次の事項が記載されている。

A.「【0026】
図1を参照すると,デジタル著作権管理システム(DRMS)の図が示されている。図からわかるように,コンテンツ10が,アクセス権/コンテンツ使用条件12と共にパッケージ化され,メディア・サーバ14にロードされる。コンテンツにアクセスするのに使用される鍵は,コンテンツとは別のコンポーネントとしてPC18にダウンロードされる。
具体的には,ダウンロード時またはレンダリング時のいずれかに,ライセンス・サーバ16にアクセスして,コンテンツおよび対応する使用条件の説明へのアクセスの許可を受け取らなければならない。
ウェブ・サーバ20は,メディア・サーバ14のコンテンツにアクセスするステップを顧客に進ませるウェブ・ページを提供する。図からわかるように,コンテンツは,ストリーミング配信を介して(たとえばファイルが大きい場合に)配信される。
【0027】
上で示したように,DRMSは,コンテンツと,そのコンテンツを暗号化するのに使用された鍵との同期配信ができない。すなわち,ライセンス・サーバ16に,別途アクセスしなければならない。そのような形で鍵を提供する時に,適当な鍵が暗号化済みコンテンツと一致しない,あるいは単一の鍵が使用され,セキュリティが弱まる可能性がある。さらに,ライセンス・サーバ16から鍵を提供するために,バック・チャネルが必要である。」

B.「【0040】
図8を参照すると,本発明の下での,タイトル鍵の暗号化および暗号化済みコンテンツへの添付が示されている。図からわかるように,圧縮されたコンテンツからなる基本コンテンツ・ストリーム100が,コンテンツ・ユニット102に区分される。各コンテンツ・ユニットに,ヘッダ104およびコンテンツ・パケット106が含まれる。ヘッダ104には,タイム・スタンプ,コンテンツの種類すなわちビデオ,オーディオ,またはそれ以外など,コンテンツを識別するのに役立つ情報が含まれる。ヘッダ104は,たとえば,サウンド・データとビデオ・データの同期化に特に役立つ。区分された時に,各コンテンツ・ユニット102のヘッダ104が,コンテンツ・パケット106から構文解析され,コンテンツ・パケット106が,タイトル鍵108を用いて暗号化されて,暗号化済みコンテンツ・パケット114が作られる。その後,鍵暗号化鍵110を使用して,タイトル鍵108を暗号化し,ヘッダ104と共にコンテンツ・パケット106に添付する。その後,結果の処理されたコンテンツ・ユニット116を,受信側に送信することができる。すなわち,暗号化済みコンテンツ・ユニット,ヘッダ,およびヘッダ拡張(暗号化済みタイトル鍵を含む)を,単一の一体化されたデータ・ストリームとして受信側に配信するか,受信側が保管することができる。したがって,受信側は,コンテンツを解読するのに必要なすべての情報と一緒に,暗号化済みコンテンツを受信または保管する。これによって,前のシステムに関連する同期化問題が回避されるだけではなく,コンテンツのランダム・アクセスも提供される。上で示したように,DRMSとCASの両方が,コンテンツのランダム・アクセスを提供する際に固有の待ち時間(たとえば遅延)を有する。具体的には,本発明の下で送信される各コンテンツ・パケットは,それを暗号化するのに使用されたタイトル鍵と共に「パッケージ化」されるので,受信側は,どのパケットでも,コンテンツ・ストリームにアクセスし,解読することができる。」

C.「【0041】
本発明は,コンテンツ・ユニットに区分されなければならない基本コンテンツ・ストリームの受信に制限されないことを理解されたい。そうではなく,本発明の教示は,コンテンツがコンテンツ・ユニットとして(たとえば事前に区分されて)受信されるシナリオに適用することができる。また,図8に,図を明瞭にするだけのために1つのコンテンツ・ユニット102だけの処理が示されていることと,通常の実施形態で,複数のコンテンツ・ユニット102がこの形で処理されることを理解されたい。さらに,複数のコンテンツ・ユニット102が処理される時に,各コンテンツ・パケットの暗号化に同一のタイトル鍵を使用する必要がないことを諒解されたい。そうではなく,各コンテンツ・パケットを,異なるタイトル鍵を用いて暗号化することができる。この範囲で,基本コンテンツ・ストリーム100の暗号化に使用されるタイトル鍵の量は,問題にはならない。というのは,各タイトル鍵が,対応する暗号化済みコンテンツ・パケットに添付される(たとえば暗号化された形で)からである。さらに,図示されてはいないが,図5および6に図示し,それに関して説明したように,コンテンツ使用条件を,暗号化の前にタイトル鍵と組み合わせることができることを諒解されたい。そのような場合には,コンテンツ使用条件およびタイトル鍵の暗号化された組合せが,ヘッダ拡張として暗号化済みコンテンツに添付される。」

(1)上記Aの「コンテンツを暗号化するのに使用された鍵との同期配信ができない」という記載,及び,上記Bの「図8を参照すると,本発明の下での,タイトル鍵の暗号化および暗号化済みコンテンツへの添付が示されている」という記載から,
引用文献1に記載されているのは,
“暗号化済みコンテンツとコンテンツを暗号化するのに使用された鍵との同期配信を行う方法”であることが読み取れる。

(2)上記Aの「具体的には,ダウンロード時またはレンダリング時のいずれかに,ライセンス・サーバ16にアクセスして,コンテンツおよび対応する使用条件の説明へのアクセスの許可を受け取らなければならない。ウェブ・サーバ20は,メディア・サーバ14のコンテンツにアクセスするステップを顧客に進ませるウェブ・ページを提供する」という記載から,
“ユーザが,コンテンツのダウンロードを要求するために,メディアサーバにアクセスする”ことが読み取れる。

(3)上記Bの「各コンテンツ・ユニットに,ヘッダ104およびコンテンツ・パケット106が含まれる」という記載,及び,同じく上記Bの「コンテンツ・パケット106が,タイトル鍵108を用いて暗号化されて,暗号化済みコンテンツ・パケット114が作られる。その後,鍵暗号化鍵110を使用して,タイトル鍵108を暗号化し,ヘッダ104と共にコンテンツ・パケット106に添付する」という記載,並びに,同じく上記Bの「暗号化済みコンテンツ・ユニット,ヘッダ,およびヘッダ拡張(暗号化済みタイトル鍵を含む)を,単一の一体化されたデータ・ストリームとして受信側に配信する」という記載から,
“受信側に,暗号化済みコンテンツ・ユニット,ヘッダ,暗号化済みタイトル鍵を含むヘッダ拡張が,配信される”ことが読み取れる。

(4)上記Cの「そうではなく,各コンテンツ・パケットを,異なるタイトル鍵を用いて暗号化することができる」という記載と,上記(3)において検討した事項から,
“受信側は,複数の暗号化済みコンテンツが配信される場合は,同時に複数の暗号化済みタイトル鍵も配信される”ことを読み取ることができる。
よって,上記(3),及び,(4)において検討した事項を併せると,上記B,及び,Cで引用した記載からは,
“受信側は,1以上の暗号化済みコンテンツ・ユニットを受信する間に,1以上の暗号化済みタイトル鍵を受信する”ことが読み取れる。

そして,上記(2)で検討した事項における「ユーザ」とは,上記(3),及び,(4)において検討した事項における「受信側」に相当するものであるから,
以上(1)?(4)において検討した事項から,引用文献1には,次の発明(以下,これを「引用発明」という)が記載されていると認める。

暗号化済みコンテンツとコンテンツを暗号化するのに使用された鍵との同期配信を行う方法であって,
受信側が,コンテンツのダウンロードを要求するために,メディアサーバにアクセスし,
受信側は,1以上の暗号化済みコンテンツ・ユニットを受信する間に,1以上の暗号化済みタイトル鍵を受信する,方法。

2.引用文献2について
原審拒絶査定の拒絶の理由に引用された上記引用文献2には,図面とともに次の事項が記載されている。

D.「【0015】
【実施例】
(詳細な説明)
以下の説明はセルラ式無線電話システムに関して書かれているが,出願人の発明はその環境に限定されないということは理解されるであろう。また,以下の説明はTDMAセルラ式通信システムであるIS-136規格準拠という環境において記載されるが,(上述の通り)本発明が例えばGSMやPDC,さらにIS-95のようなCDMAを用いるような他の標準に従って設計された他のディジタル通信アプリケーションにおいても実施可能であることは本発明の当業者には理解されよう。」

E.「【0025】
本発明は移動局120のような従来のリモート端末にも確かに適用可能であるけれども,他のタイプのリモート受信装置に対しても適用可能である。例えば,本発明はリモート装置が受信及び送信能力の両方を持っているようなシステムに適用可能である一方,受信専用の装置,例えば伝統的な呼び出しリモート装置に対しても適用可能である。実際,(1)報知サービスが記述される情報の形式,例えばスポーツスコア,証券相場等はそれ自体リモート装置の電送能力を供給しないこと,(2)送信機能を除去することによりリモート装置のさらなる小型化及び低価格化が可能であることを考慮すると,少なくともいくつかの受信専用のリモート装置を提供することは実体的な動機が存在する。」

F.「【0044】
状態変数B-SAC実施例は利用の容易性とアクセス制御との有益なバランスをもたらすが,いくつかのサーブビスプロバイダ/システムオペレータはさらなるアクセス制御及び,この種の報知サービスに調和された,あるレベルのデータの完全性を希望するだろう。従って,本発明の別の実施例によれば,サービスプロバイダによって報知される情報は暗号化されてよい。リモート装置は,例えば毎月毎に変更可能な復号(サービス)鍵をダウンロード可能である。ダウンロードのための特別なテレサービスを開発してもよいし,EIA/TIA IS-136に示されるOTAテレサービス(Over-the-Air Activation TeleService: OATS)における追加エレメントであってもよい。復号鍵に加え,有効時間も含まれていて良い。あるいは,キーインデックスが供給される。報知情報サービスチャネルそれ自身(例えば証券相場)又はBCCHの汎用位置(general place)において,現在のキーインデックス又は有効時間が供給される。これによって,リモート装置が自らが有するサービス鍵が有効であることを判定することが可能になる。キーインデックス又は有効時間が装置内にストアしたデータと一致しない場合,ユーザは警告を受ける。」

したがって,引用文献2には,“セルラ式無線電話システムの移動装置が,コンテンツを復号するための鍵を受信する”という技術的事項が記載されている。

3.引用文献3について
原審拒絶査定の拒絶の理由に引用された上記引用文献3には,図面とともに次の事項が記載されている。

G.「【0122】ダウンロード管理プログラム728は,代理サーバ503からコンテンツ鍵またはコンテンツをダウンロードするとき,そのダウンロードの処理が正常に終了したか否かを判定し,ダウンロードの処理が正常に終了していないと判定された場合,代理サーバ503にコンテンツ鍵またはコンテンツの再送を要求する。ダウンロード管理プログラム728は,ダウンロードの処理が正常に終了したと判定された場合,配信終了通知を代理サーバ503に送信する。」

したがって,引用文献3には,“代理サーバからコンテンツ鍵またはコンテンツをダウンロードするとき,そのダウンロードの処理が正常に終了したか否かを判定し,ダウンロードの処理が正常に終了していないと判定された場合,代理サーバにコンテンツ鍵またはコンテンツの再送を要求する”という技術的事項が記載されている。

4.引用文献4について
原審拒絶査定の拒絶の理由に引用された上記引用文献4には,図面とともに次の事項が記載されている。

H.「【0031】このデバイス鍵Dでタイトル鍵Tをタイトル鍵暗号部25で暗号化し,暗号化タイトル鍵T’ファイル17としてハードディスクドライブHDDに記録する。」

したがって,引用文献4には,“暗号化タイトル鍵をファイルとしてハードディスクドライブに記録しておく”という技術的事項が記載されている。

5.引用文献5について
原審拒絶査定の拒絶の理由に引用された上記引用文献5には,図面とともに次の事項が記載されている。

I.「3.開発したRMPシステム
開発したRMPシステムの概要を図1に示す.
放送受信時は,現行BS/CSデジタル放送で使用しているCASを利用してコンテンツを保護する.コンテンツをスクランブルする・ための鍵は,暗号時と復号時で同じ鍵を用いる共通鍵暗号化方式をとり,秒単位で異なる鍵でコンテンツをスクランブルするスクランブル鍵Ks,放送事業者個別のワーク鍵Kw,受信機のセキュリティモジュールに固有のマスター鍵Kmの三つの暗号鍵により,放送受信時のコンテンツを保護する.
本RMPシステムでは,コンテンツを放送受信時に視聴制御できるだけでなく,蓄積コンテンツ再生時にも制御可能とする.このために,現行BSデジタル放送のCASに対して以下の方式拡張を行った.
(1)コンテンツ単位の視聴制御を実現するために,コンテンツ鍵Kcを導入し鍵構造を4重化する
(2)セキュリティモジュール固有鍵Km’を導入し,コンテンツを蓄積する際にはKcをKm’で再暗号化して蓄積する
(3)放送事業者が付与したコンテンツの利用条件情報であるRMPI(RMPInformation:利用可能期間など)にしたがってスクランブル鍵Ksを復号化し,コンテンツをデスクランブルする
蓄積コンテンツ再生時は,Ks,Kw,Kmにコンテンツ鍵Kcを加え,四つの暗号鍵によりコンテンツを保護する(以下,4重鍵方式).
コンテンツ鍵Kcは,コンテンツに対して固有の鍵であり,RMPIと併せて,共通情報であるECM(Entitlement Control essage)セクション(以下,Kc配布用ECM)としてコンテンツに多重化する.RMPIは,蓄積したコンテンツの利用期間を制御するために,コンテンツ鍵Kcの利用可能期間を設定する.予めワーク鍵Kwが付与されている複数の受信機に対して,Kc配布用ECMを同時に送出することができるので,本方式は,1対多のコンテンツ伝送である放送に適している.このECMには,暗号化部内に改竄検出用コードがあり,鍵情報などを不正に改竄することが困難な構造となっている(図2).
コンテンツを蓄積する場合,受信したKc配布用ECMを,セキュリティモジュール内で復号化し,固有鍵Km’で再暗号化して,暗号化したコンテンツと併せて蓄積装置に蓄積する.なお,スクランブル鍵Ksは,コンテンツ鍵Kcで暗号化されたECM(以下,ECM-Kcとする)として多重化する.固有鍵Km’で再暗号イヒすることで,受信機に共通の共通情報として配信されたコンテンツ鍵Kcを受信機固有の鍵情報にすることができる.また,Kc配布用ECMと併せて,現行のデジタル放送で用いられているECM(以下,ECM-Kwとする)を送出することで,放送受信と蓄積後視聴時,双方のコンテンツ保護を実現する.
蓄積したコンテンツを再生する場合は,再暗号化したKc配布用ECMをセキュリティモジュール内で復号してコンテンツ鍵Kcを取得し,ECM-Kcを復号してスクランブル鍵Ksをセキュリティモジュールから得ることで,視聴可能となる.その際,セキュリティモジュールは,RMPI内のコンテンツ鍵Kcの利用可能期間を抽出して現在日時と比較し,利用可能期間を超過している場合は,復号されたスクランブル鍵Ksの受信機への送出を停止する.このRMPIは,コンテンツ鍵Kcと共に暗号化されているため,不正にRMPIを削除・改竄することは困難である.」(1004(134)頁右欄4行?1005(135)頁左欄37行)

したがって,引用文献5には,“蓄積したコンテンツの利用期間を制御するために,コンテンツの利用条件情報であるRMPIによりコンテンツ鍵の利用可能期間を設定する”という技術的事項が記載されている。

第5.本願発明と引用発明との対比及び相違点についての判断
1.本願発明1について
(1)対比
ア.引用発明において,「受信側」が,何らかの“装置”である態様を含むことは明らかであり,引用発明における「暗号化済みコンテンツとコンテンツを暗号化するのに使用された鍵との同期配信を行う方法」は,「受信側」が,「1以上の暗号化済みタイトル鍵を受信する」態様を含むものであるから,
本願発明1における「装置が実行する,ワイヤレス通信システムにおいて1以上の鍵を受信する方法」と,
“装置が実行する,1以上の鍵を受信する方法”である点で共通する。

イ.上記ア.で検討したとおり,引用発明は,「受信側」が,「装置」である態様を含むものであるから,「受信側」が,「プロセッサ」を構成要素として含む態様を含むものである。
そして,引用発明において,「受信側が,コンテンツのダウンロードを要求するために,メディアサーバにアクセス」する際には,受信側は,1以上の「コンテンツのダウンロードを要求する」態様を含むことになるので,前記工程は,「受信側」が,どの「コンテンツのダウンロードを要求」するか“選択する”工程を含むことは明らかである。そして,引用発明においては,「コンテンツのダウンロードの要求をする」ことで,該「コンテンツを暗号化するのに使用された鍵」も一緒に「ダウンロード」されることになるから,引用発明においては,「コンテンツのダウンロードを要求する」ことと,「コンテンツの暗号化するのに使用された鍵」の「ダウンロードを要求する」こととは同じことであると言える。
そうであるとすると,引用発明における「受信側」が,本願発明1における「装置のプロセッサ」に相当するので,
引用発明における「受信側が,コンテンツのダウンロードを要求するために,メディアサーバにアクセス」すること,
本願発明1における「装置のプロセッサが,前記1以上の鍵を要求するか否かを決定することと
装置のプロセッサが,前記1以上の鍵の送付をサーバに要求すること」こととは,
“装置のプロセッサが,1以上の鍵を要求することを選択することと,
前記プロセッサが,前記1以上の鍵の送付をサーバに要求すること”である点で共通する。

ウ.引用発明における「暗号化済みコンテンツ」が,本願発明1における「非鍵データ」に相当し,引用発明において「1以上の暗号化済みタイトル鍵」は,「1以上の暗号化済みコンテンツ・ユニットを受信する間」,即ち,「受信側」と,「メディアサーバ」とが,“接続されている期間中”に受信されるものであるから,
引用発明における「受信側が,コンテンツのダウンロードを要求するために,メディアサーバにアクセスし,
受信側は,1以上の暗号化済みコンテンツ・ユニットを受信する間に,1以上の暗号化済みタイトル鍵を受信する」と,
本願発明1における「サーバによって次にスケジュールされていた非鍵データメッセージを受信するためのスケジュールされた接続期間中に,前記要求に応答して前記次にスケジュールされていた非鍵データメッセージに前記サーバによって添付された,前記1以上の鍵を受信する」とは,
“プロセッサが,非鍵データを受信するためにスケジュールされた接続期間中に前記1以上の鍵を受信する”点で共通する。

エ. 以上,ア.?ウ.において検討した事項から,本願発明1と,引用発明との,一致点,及び,相違点は,次のとおりである。

[一致点]
“装置が実行する,1以上の鍵を受信する方法であって,
前記装置のプロセッサが,1以上の鍵を要求することを選択することと,
前記プロセッサが,前記1以上の鍵の送付をサーバに要求すること
前記プロセッサが,非鍵データを受信するためにスケジュールされた接続期間中に前記1以上の鍵を受信することと,
を備える方法。”

[相違点1]
“1以上の鍵を受信する”ことに関して,
本願発明1においては,「ワイヤレス通信システム」において行われるものであるのに対して,
引用発明においては,「ワイヤレス通信システム」である点についての言及がない点。

[相違点2]
“鍵”に関して,
本願発明1においては,「各鍵はある時間期間について有効であ」るのに対して,
引用発明においては,「暗号化するのに使用された鍵」の“有効期限”については,特に言及されていない点。

[相違点3]
本願発明1においては,「装置のプロセッサが,非鍵データを含むメッセージの受信に応答して,前記1以上の鍵を要求すべきかどうかを決定する」のに対して,
引用発明においては,「鍵を要求すべきかどうかを決定する」点について言及されていない点。

[相違点4]
“非鍵データを受信するためにスケジュールされた接続期間”に関して,
本願発明1においては,「サーバによって次にスケジュールされていた非鍵データメッセージを受信するためのスケジュールされた接続期間」であるのに対して,
引用発明においては,「1以上の暗号化済みタイトル鍵」を,“次にスケジュールされていた1以上の暗号化済みコンテンツ・ユニットを受信するためのスケジュールされた期間”に受信することについては,特に言及されていない点。

(2)相違点についての当審の判断
上記[相違点4]について検討すると,上記「第4.引用文献に記載の事項及び引用文献に記載の発明」において記載を引用した,引用文献2?引用文献5の何れにも,[相違点4]に係る構成に関して記載されておらず,当業者といえども,引用発明及び引用文献2?引用文献5に記載された技術的事項から,[相違点4]に係る構成を容易に想到することはできない。
したがって,他の相違点について判断するまでもなく,本願発明1は,当業者であっても,引用発明及び引用文献2?引用文献5に記載された技術的事項に基づいて容易に発明できたものとはいえない。

2.本願発明2?本願発明10及び本願発明15について
本願発明2?本願発明10及び本願発明15も,本願発明1における[相違点4]に係る構成を有するものであるから,本願発明1と同じ理由により,当業者であっても,引用発明及び引用文献2?引用文献5に記載された技術的事項に基づいて容易に発明できたものとはいえない。

3.本願発明11?本願発明14について
本願発明11?本願発明14は,本願発明1,本願発明2,本願発明4,及び,本願発明5に対応する方法の発明であり,本願発明1の[相違点4]に係る構成を備えるものであるから,本願発明1と同様の理由により,当業者であっても,引用発明及び引用文献2?引用文献5に記載された技術的事項に基づいて容易に発明できたものとはいえない。

第6.むすび
以上のとおり,本願発明1?本願発明15は,当業者が引用発明及び引用文献2?引用文献5に記載された技術的事項に基づいて容易に発明をすることができたものではない。したがって,原査定の理由によっては,本願を拒絶することはできない。
また,他に本願を拒絶すべき理由を発見しない。

よって,結論のとおり審決する。
 
審決日 2018-11-28 
出願番号 特願2016-181616(P2016-181616)
審決分類 P 1 8・ 121- WY (H04L)
最終処分 成立  
前審関与審査官 青木 重徳  
特許庁審判長 仲間 晃
特許庁審判官 石井 茂和
須田 勝巳
発明の名称 鍵を送付するための方法および装置  
代理人 岡田 貴志  
代理人 蔵田 昌俊  
代理人 中丸 慶洋  
代理人 福原 淑弘  
代理人 井関 守三  

プライバシーポリシー   セキュリティーポリシー   運営会社概要   サービスに関しての問い合わせ