平成26年 (行ケ) 10212号審決取消請求事件｜特許判例データベース

運営：アスタミューゼ株式会社

【重要】サービス終了のお知らせ

会員機能

ＩＤ登録

パテントビューロIDとは？

判例データベース

審決データベース

パナソニックで一緒に知財の仕事しませんか？

ポートフォリオ機能

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

関連審決	不服2012-16391

この判例の個人情報、企業機密に関する修正依頼をする

元本PDF	裁判所収録の全文PDFを見る

事件	平成 26年 (行ケ) 10212号審決取消請求事件
事件	原告テレフオンアクチーボラゲットエルエムエリクソン（パブル）訴訟代理人弁護士髙梨義幸訴訟代理人弁理士稲葉良幸同佐藤睦同笹本真理子被告特許庁長官Ｘ指定代理人石井茂和同木村貴俊同相崎裕恒同根岸克弘
裁判所	知的財産高等裁判所
判決言渡日	2015/06/11
権利種別	特許権
訴訟類型	行政訴訟
主文	１原告の請求を棄却する。２訴訟費用は原告の負担とする。３この判決に対する上告及び上告受理の申立てのための付加期間を３０日と定める。

事実及び理由
請求特許庁が不服2012-16391号事件について平成26年4月30日にした審決を取り消す。
事案の概要 1 特許庁における手続の経緯等 (1) 原告は,発明の名称を「電気通信システムにおける方法および構成」とする発明について,2008年(平成20年)5月20日(優先権主張日2 007年(平成19年)9月17日,米国)を国際出願日とする特許出願( 特願2010-524820号。以下「本願」という。)をした。原告は,平成24年4月19日付けの拒絶査定(甲7)を受けたため,同年8月23日,拒絶査定不服審判を請求した。 (2) 特許庁は,上記請求を不服2012-16391号事件として審理を行い,平成26年4月30日,「本件審判の請求は,成り立たない。」との審決(出訴期間の付加期間90日。以下「本件審決」という。)をし,同年5 月12日,その謄本が原告に送達された。 (3) 原告は,平成26年9月9日,本件審決の取消しを求める本件訴訟を提起した。 2 特許請求の範囲の記載本願の特許請求の範囲の請求項1の記載は,次のとおりである(以下,請求項1に係る発明を「本願発明」という。甲4)。「【請求項1】次世代パケットシステムEPSのモビリティ管理エンティティ(13)MMEにおいて,ユーザ装置(11)UEと前記UEにサービスするeNｏdeB(12)との間のRRC/UPトラフィックを保護するためにセキュリティキーK_eNBを確立する方法であって,以下の - NASサービス要求を前記UEから受信するステップ(32,52)であって,前記要求が,NASアップリンクシーケンス番号NAS_U_SEQ を示すステップと, - 少なくとも前記受信されたNAS_U_SEQから,および前記UEと共有される,記憶されたアクセスセキュリティ管理エンティティキーK_ASMEから,前記セキュリティキーK_eNBを導出するステップ(33,53)と, - 前記導出されたK_eNBを,前記UEにサービスする前記eNｏdeB(12)に転送するステップ(34)と,を含む,MMEにおける方法。」3 本件審決の理由の要旨(1) 本件審決の理由は,別紙審決書(写し)記載のとおりである。要するに, 本願発明は,本願の優先権主張日前に頒布された刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明,すなわち,「3GPP,U niversal Mobile Telecommunications System (UMTS);Evolved Universal T errestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial R adio Access (E-UTRAN);Overall description;Stage 2(3GPP TS 36.300 ver sion 8.1.0 Release 8),[online],2007年 6月,p.11-15, 58,59 ;URL,http://www.etsi.org/deliver/etsi_ts/136300_136399/136300/0 8.01.00_60/ts_136300v080100p.pdf」(以下「引用刊行物1」又は「3GPP T S 36.300 version 8.1.0 Release 8」という。甲1)に掲載された発明等に基づいて当業者が容易に発明をすることができたものであって,特許法29 条2項の規定により特許を受けることができないから,本願は拒絶すべきものであるというものである。 (2) 本件審決が認定した引用刊行物1に記載された発明(以下「引用発明」という。),本願発明と引用発明の一致点及び相違点は,以下のとおりである。ア引用発明「UEと,UEに対する資源の動的配置,ユーザ・データ・ストリームを暗号化するeNBと,eNBへのページング・メッセージの分配,セキュリティ制御,及び,NAS信号伝達の暗号化と完全性保護を行うMMEとを有する無線通信システムにおいて, UEとMMEは,K_ASMEという名の基本鍵を共有し,前記K_A SMEからK_eNBが得られ, 前記K_eNBを得るために,シーケンス番号が使用され, 前記K_eNBは,MMEから,eNBに送信される,方法。」イ本願発明と引用発明の一致点「次世代パケットシステムEPSのモビリティ管理エンティティMMEにおいて,ユーザ装置UEと前記UEにサービスするeNｏdeBとの間の RRC/UPトラフィックを保護するためにセキュリティキーK_eNB を確立する方法であって, シーケンス番号と,および前記UEと共有される,記憶されたアクセスセキュリティ管理エンティティキーK_ASMEから,前記セキュリティキーK_eNBを導出するステップと, 前記導出されたK_eNBを,前記UEにサービスする前記eNｏde Bに転送するステップ,とを含む方法。」である点。ウ本願発明と引用発明の相違点 “シーケンス番号”に関して, 本願発明においては,「NASサービス要求を前記UEから受信するステップ(32,52)であって,前記要求が,NASアップリンクシーケンス番号NAS_U_SEQを示すステップ」において,「UE」側から「MME」側が受信する「アップリンクシーケンス番号」であるのに対して, 引用発明においては,「シーケンス番号」が,「UE」から,「MME」への「アップリンクシーケンス番号」であるか否かが明確でない点。
当事者の主張 1 原告の主張 (1) 取消事由1(引用発明及び一致点の認定の誤り) 引用刊行物1(甲1)には,「K_eNB」を得るために,「シーケンス番号」(sequence number)が使用される構成についての開示はないから,本件審決が認定した引用発明のうち,「前記K_eNBを得るために,シーケンス番号が使用され」との部分は誤りであり,本件審決が引用発明が上記部分の構成を有することを前提に,「シーケンス番号と,および前記UEと共有される,記憶されたアクセスセキュリティ管理エンティティキーK_ASMEから,前記セキュリティキーK_eNBを導出するステップ」を本願発明と引用発明の一致点と認定したことも誤りである。ア引用発明の認定の誤り本件審決は,引用刊行物1(甲1)の「A given sequence number must only be used once for a given eNB key」との記載を「得られたシーケンス番号は,eNB鍵を得るために使用されるのは,一度のみでなければならない」と和訳(以下「本件和訳」という場合がある。)した上で,上記記載箇所から「“eNB鍵を得るために,シーケンス番号が使用される” ことが読み取れる。」と認定したが,以下のとおり誤りである。 (ア) 引用刊行物1の「A given sequence number must only be used on ce for a given eNB key」との記載は,「所与のあるシーケンス番号は, 所与のあるeNB鍵のために使用されるのは,一度のみでなければならない」と訳すべきである。上記記載中の「for a given eNB key」の部分を本件和訳のように「eNB鍵を得るために」を意味すると解する余地はない。仮に「得るために」と英語表記するのであれば,「to get」,「to o btain」又は「to derive」などの語を用いるはずであるが,そのような語は用いられていない。したがって,本件審決が上記記載箇所について本件和訳をし,上記記載箇所から「“eNB鍵を得るために,シーケンス番号が使用される”ことが読み取れる。」と認定したのは誤りである。 (イ) 次に,「A given sequence number must only be used once for a given eNB key」との記載の前後の文脈からみても,本件和訳は誤りである。 a 引用刊行物1の「14 Security」の「14.1 Overview and Principle s」(「14 セキュリティ」の「14.1 概説及び原則」)には, 以下のとおり,E-UTRANのセキュリティに適用される6つの原則(「第1原則」ないし「第6原則」)が記載されており,「A give n sequence number must only be used once for a given eNB key」との記載は,第5原則の第2文の一部である。「- The eNB keys are cryptographically separated from the EP C keys used for NAS protection (making it impossible to use th e eNB key to figure out an EPC key).」(以下「第1原則」という。) 「- The keys are derived in the EPC/UE from key material tha t was generated by a NAS (EPC/UE) level AKA procedure.」(以下「第2原則」という。) 「- The eNB keys are sent from the EPC to the eNB when the U E is entering LTE_ACTIVE state (i.e. during RRCconnection or S 1 context setup).」(以下「第3原則」という。) 「- Key material for the eNB keys is sent between the eNBs d uring LTE_ACTIVE intra-E-UTRAN mobility.」(以下「第4原則」という。) 「- A sequence number is used as input to the ciphering and integrity protection. A given sequence number must only be use d once for a given eNB key (except for identical re-transmissi on). The same sequence number can be used for both ciphering a nd integrity protection.」(以下「第5原則」という。) 「- A hyper frame number (HFN) (i.e. an overflow counter mec hanism) is used in the eNB and UE in order to limit the actual number of sequence number bits that is needed to be sent over the radio. The HFN needs to be synchronized between the UE an d eNB.」(以下「第6原則」という。)b 引用刊行物1の「14.1 概説及び原則」は,E-UTRANのセキュリティ手続全体の概説及び原則を述べたものである。「14.1 概説及び原則」記載の第1原則ないし第4原則はeNB 鍵の生成や配送について,第5原則は,鍵を用いて暗号化及び完全性保護を実現すること,当該手続にシーケンス番号を用いることについて, 第6原則はHFNの取り決めについてそれぞれ述べたものである。第5原則は,第1文において「A sequence number is used as inpu t to the ciphering and integrity protection.」(「シーケンス番号は,暗号化及び完全性保護のための入力として用いられる。」)と記載し,第3文において「The same sequence number can be used for both ciphering and integrity protection.」(「同一のシーケンス番号が,暗号化と完全性保護の両方に用いることができる。」)と記載しているように,暗号化及び完全性保護の手続,すなわち「鍵を用いる」手続について述べたものであるから,その第2文である「A given sequ ence number must only be used once for a given eNB key」についても,同様に暗号化及び完全性保護の手続について述べたものと理解すべきであり,これを「鍵の生成」について述べたものと理解することは極めて不自然であって,恣意的な解釈であるといわざるを得ない。 c 「14.1 概説及び原則」の最終段落には,「From K_ASME, the N AS, (and indirectly) K_eNB keys are derived. The K_ASME never leaves the EPC, but the K_eNB key is transported to the eNB from the EPC when the UE transitions to LTE_ACTIVE. From the K_eNB, the eNB and UE can derive the UP and RRC keys.」(「K_ASMEから,NAS(そして,間接的に),K_eNBが得られる。K_ASMEは,決して,EPCから離れない。しかしながら,K_eNB鍵は,UEが,LTE_ACTIVEに移行すると,EPCからeNBに運ばれる。K_eNBから,eNB,及び,UEは,UP,及び,RRC鍵を得ることができる。」)との記載がある。この記載から,EPCにおいて得られたK_eNBがeNBに運ばれ,eNB及びUEにおいて,当該K_eNBを基にしてUP鍵及びRRC鍵を得ていることが明らかである。そして,UEとeNB間のプロトコルで用いられる鍵は,引用刊行物1の「Figure 14.1-1」(別紙1参照)に示すとおり,K_eNBの下位の鍵であるKeNB-UP-enc(UP鍵),KeNB-RRC-enc(RRC鍵)及びKeNB-RRC-inｔ(RRC鍵)であり,このうち,KeNB-UP-enc及びKeNB-RRC-encは暗号化に用いられる鍵である。また,引用刊行物1(3GPP TS 36.300 version 8.1.0 Release 8)の後のバージョンの甲8(3GPP TS 36.300 version 8.8.0 Release 8)に「A sequence number (COUNT) is used as input to the cipheringand integrity protection.」との記載があることからすると,第5原則の第2文中の「A given sequence number」にいう「sequence number」とは「COUNT」を意味する。さらに,引用刊行物1の後のバージョンの甲9の1(3GPP TS 36.323 version 1.0.0 Release 8)には,シーケンス番号の一種である「COUNT」が,暗号化及び完全性保護のパラメータとして,KRRCenc,KUPenc及びKRRCinｔのようなeNB鍵の下位の鍵と共に用いられることが示されている。そうすると,第5原則は,第1文において,シーケンス番号が暗号化及び完全性保護の入力として用いられること,第2文において,ある所与のシーケンス番号が,(暗号化及び完全性保護に用いられる際に,) ある所与のeNB鍵を基にして得られたUP鍵(KeNB-UP-enc)及び RRC鍵(KeNB-RRC-enc,KeNB-RRC-inｔ)のために用いられるのは一度でなければならないこと,第3文において,所与のeNB鍵(正確には,その下位のUP鍵及びRRC鍵)が暗号化及び完全性保護の手続に用いられることを述べたものといえる。 d 以上によれば,引用刊行物1の「A given sequence number must on ly be used once for a given eNB key」(第5原則第2文)との記載は,暗号化及び完全性保護の手続について述べたものであって,シーケンス番号がeNB鍵の生成のために用いられることを述べたものではないから,本件審決がした本件和訳は誤りである。 (ウ) 以上のとおり,本件審決が引用刊行物1の「A given sequence numbe r must only be used once for a given eNB key」(第5原則第2文) との記載について本件和訳をし,上記記載箇所から「“eNB鍵を得るために,シーケンス番号が使用される”ことが読み取れる。」と認定したのは誤りである。引用刊行物1には,他に「K_eNB」を導出する手法についての開示はないから,「K_eNBを得るために,シーケンス番号が使用され」る構成についての開示はない。したがって,本件審決が認定した引用発明のうち,「前記K_eNB を得るために,シーケンス番号が使用され」との部分は誤りである。イ一致点の認定の誤り本件審決が,「シーケンス番号と,および前記UEと共有される,記憶されたアクセスセキュリティ管理エンティティキーK_ASMEから,前記セキュリティキーK_eNBを導出するステップ」を本願発明と引用発明の一致点と認定したのは誤りである。 (ア) 前記ア(ウ)のとおり,引用刊行物1には,「K_eNBを得るために,シーケンス番号が使用され」る構成についての開示はないから,引用発明は,「シーケンス番号と,および前記UEと共有される,記憶されたアクセスセキュリティ管理エンティティキーK_ASMEから,前記セキュリティキーK_eNBを導出するステップ」の構成を有するものとはいえない。したがって,本件審決が上記構成を本願発明と引用発明の一致点と認定したのは誤りである。 (イ)a 本願の優先権主張日時点における当業者の技術常識によれば,引用発明における「シーケンス番号」には,本願発明の「NAS_U_ SEQ」は含まれない。すなわち,前記ア(イ)cのとおり,引用刊行物1記載の第5原則の第2文中の「A given sequence number」にいう「sequence number」とは,「COUNT」を意味するものであり,「COUNT」はHFN 及びPDCPシーケンス番号から構成されるものであるから,「NAS _U_SEQ」とは異なるシーケンス番号である。また,第5原則は,「E-UTRAN」すなわち「UE」と「eNB」間のネットワークのセキュリティについて述べたものであるのに対し( 引用刊行物1のFigure4)(別紙1参照),「NAS」は,「UE」と「MME」との間のプロトコルであり(同Figure4.3.2) (別紙1参照), 本願発明と引用発明とは,「シーケンス番号」が用いられるプロトコルが異なるから,「シーケンス番号」の意味が異なることは,当業者にとって自明である。したがって,引用発明における「シーケンス番号」には,本願発明の「NAS_U_SEQ」は含まれないから,本件審決が,「シーケンス番号と,および前記UEと共有される,記憶されたアクセスセキュリティ管理エンティティキーK_ASMEから,前記セキュリティキーK_eNBを導出するステップ」を本願発明と引用発明の一致点と認定したのは誤りである。 b 被告は,これに対し,引用発明における「シーケンス番号」に「NA S_U_SEQ」が含まれる旨主張する。しかしながら,「シーケンス番号」という用語は,様々な場面で用いられるものであり,単に「シーケンス番号」といっても,その意味は一義的ではなく,一般的にシーケンス番号と整理されるものが全て引用発明における「シーケンス番号」に含まれるなどと解することはできない。被告は,単に抽象論を述べるのみで,具体的な論証を一切行っていないから,被告の上記主張は失当である。 (2) 取消事由2(相違点の看過) 本願発明は,「NASサービス要求を前記UEから受信するステップ(3 2,52)であって,前記要求が,NASアップリンクシーケンス番号NA S_U_SEQを示すステップ」の構成を有するが,本件審決は,引用発明が上記構成を有することを認定していないから,上記構成を本願発明と引用発明の相違点として認定すべきであったのに,この相違点の認定を看過した誤りがある。そして,本件審決は,上記相違点の容易想到性について判断を示していない。 (3) 取消事由3(相違点の容易想到性の判断の誤り) 本件審決は,本件審決が認定した相違点について,引用発明,国際公開第 2006/116620号(2006年11月2日公開。以下「引用刊行物 2」という。甲2の1)に記載の発明及び周知技術も共に,無線通信におけるパケット伝送のセキュリティに関するものであるから,「シーケンス番号」を「UE」側から「MME」に送信する必要がある場合に,「シーケンス番号」を「UE」から「MME」に送信するよう構成することは,当業者が適宜なし得る事項であり,本願発明と引用発明との相違点は格別のものではない旨判断したが,以下に述べるとおり,本件審決の上記判断は誤りである。ア(ア) 前記(1)ア(ウ)のとおり,引用刊行物1(甲1)には,「K_eNB を得るために,シーケンス番号が使用され」る構成についての開示はない。同様に,引用刊行物2(甲2の1)及び本件審決が認定した周知技術(「「UE」から,「MME」に対して「RRC/NAS信号」を送信する点」)のいずれにも,「K_eNBを得るために,シーケンス番号が使用され」る構成についての開示も示唆もない。また,仮に引用刊行物1に「K_eNBを得るために,シーケンス番号が使用され」る構成の開示があるとしても,引用刊行物1には,K_ eNBを得るためにNASサービス要求で示される「NAS_U_SE Q」をシーケンス番号として用いることの開示はない。同様に,引用刊行物2及び本件審決が認定した周知技術のいずれにおいても,NASサービス要求で示される「NAS_U_SEQ」をK_eNBの生成のために用いることについての開示や示唆はない。したがって,引用発明に引用刊行物2記載の発明及び本件審決が認定した構成を組み合わせても,当業者が相違点に係る本願発明の構成を容易に想到することができたものとはいえない。 (イ) 被告は,これに対し,乙2,4ないし7の記載を根拠として挙げて, シーケンス番号を使用して鍵を生成することによって効率的に鍵を共有することができることが,セキュリティの分野における技術常識であったこと,UEからのアップリンクにシーケンス番号が含まれていることは広く知られていることからすると,このようなアップリンクに含まれるシーケンス番号のうち,具体的に何を使用するかは,結局のところ,使用できるものの中から適宜選択すべきことにすぎないとして,当業者が相違点に係る本願発明の構成を容易に想到することができた旨主張する。しかしながら,被告の上記主張は,引用刊行物1に全く記載のない事項について,乙2,4ないし7に記載されていることを理由に引用刊行物1に同じことが記載されている旨主張するに等しいものであり,また, 公知の技術について,何らの論証もないまま殊更引用刊行物1に開示された構成を上位概念化するものであって不当である。したがって,被告の上記主張は理由がない。イ本件審決は,本願発明と引用発明との相違点は格別のものではないと判断したが,その判断に際し,本願発明が引用発明と比べて顕著な効果を奏することを考慮していないから,上記判断は誤りである。すなわち,前記ア(ア)のとおり,引用刊行物1には,K_eNBを得るためにNASサービス要求で示される「NAS_U_SEQ」をシーケンス番号として用いることの開示はない。これに対し,本願の願書に添付した明細書(以下,図面を含めて「本願明細書」という。甲4)には,「NAS_D_SEQ」を用いる場合には,「NASメッセージ」の損失に起因する「UEにおける誤ったNAS_D_SEQ」に基づく「K_eNB」生成が行われるおそれがあり(段落【0007】),また,「別個のシーケンス番号」を用いる場合には,「再生攻撃を防ぐために,別個のシーケンス番号をUEおよびMMEの両方において保持しなければならない」といった「特別な複雑さ」を要するが(段落【0008】),本願発明は,「K_eNB」の生成に「NAS_U_SEQ」を使用することにより,「MMEからUEへの明示的なダウンリンクNASサービス受理メッセージまたはシーケンス番号が必要ではないこと,およびNASセキュリティコンテキストの再生保護機能が,RRCおよびUPセキュリティコンテキストにおいて再利用されること」(段落【0011】)といった顕著な効果を奏することが開示されている。しかるところ,本件審決は,本願発明の上記顕著な効果を考慮することなく,本願発明と引用発明との相違点は格別のものではないと判断したのであるから,本件審決の上記判断は誤りである。ウ以上によれば,本件審決における相違点の容易想到性の判断には誤りがある。 (4) まとめ以上によれば,本件審決には,引用発明及び一致点の認定の誤り,相違点の看過,相違点の容易想到性の判断の誤りがあり,その結果,本件審決は, 本願発明は特許法29条2項の規定により特許を受けることができないと誤った判断をしたものである。したがって,本件審決は,違法であるから,取り消されるべきものである。 2 被告の主張(1) 取消事由1(引用発明及び一致点の認定の誤り)に対しア引用発明の認定について (ア) 引用刊行物1がLTEに関する規格として発行された技術文書であることに照らせば,本件審決が,第5原則の第1文と第3文については, 逐語的な直訳を示す一方で,第2文については「eNB鍵を得るために …が使用される」と訳し,逐語的な直訳を示さなかったことは不適切であったものといえる。しかしながら,本件審決は,第5原則の第2文の「A given sequence number must only be used once for a given eNB key」の「for a giv en eNB key」との部分のみから「eNB鍵を得るために」との訳を導いたわけではない。「use」の動詞は,「用いる」ないし「使用する」を意味するが,「use」の目的ないし態様は文脈によって異なる。第2文中の「be used…for a given eNB key」の「eNB鍵のために使用される」との記載が,引用刊行物1の「14.1 概説及び原則」記載のeNB鍵の生成,共有,配送について主として述べている文脈中に存在しており,「eNB鍵の生成のために」使用される趣旨を含むことから,このことを踏まえて意訳し,文脈に即して「eNB鍵を得るために…が使用される」と訳したものであり,誤訳ではない。すなわち,引用刊行物1の「14.1 概説及び原則」には,「E-UTRANのセキュリティに適用される」べき6つの「原則」(第1原則ないし第6原則)が記載されるとともに,AKA(判決注:認証及び鍵共有のためのプロトコル)実行の結果としてEPCとUEがK_ASMEという名称の基本鍵を共有する旨,K_ASMEからK_eNBが得られる旨,K_ASMEはEPCから離れないのに対して,K_eNBは,(UEがLTE_ACTIVEに移行すると)EPCからeNBに運ばれる旨等が「概説」されている。そして,第1原則ないし第3原則は,「概説」された内容をさらに抽象化したものであり,第1原則には,(E-UTRAN(UE/eNB)のセキュリティにおいて用いられる)eNB鍵は,NAS保護のために用いられるEPC鍵から分離されることが,第2原則には,これらの「鍵」が「EPC/UE」において「鍵素材」から得られる(つまりEPCだけでなくUEにおいても鍵生成が行われる)とともに,その「鍵素材」は,「NASレベルAKA手続」によって生成される旨が,第3原則には,UEがLTE_ACTIVE状態に入るとeNB鍵がEPCからeNBに送られる旨がそれぞれ示されており,また,第5原則には,「シーケンス番号」を用いることを前提として,第1文では「暗号化,及び,完全性保護のための入力」という最も抽象的なレベルでの目的ないし態様が示され,第2文では「あるeNB鍵」につき「一度のみ」しか用いることができない旨及び第3文では同じシーケンス番号を暗号化と完全性保護の両方に用いることができる旨が示されているから,引用刊行物1の「14.1 概説及び原則」は,eNB鍵の生成,共有,配送について主として述べたものといえる。また,第5原則は,K_eNBとその派生鍵(eNB鍵)が,NAS保護のために用いられるEPC鍵から分離され,NASレベルで行われる「認証及び鍵共有」のために用いられない旨を示した第1原則を受けて,K_eNBが「認証及び鍵共有」の後の「暗号化」と「完全性保護」のために用いられる旨を述べたものである。要するに,第5原則は,第1原則の裏返しとして,K_eNBが「認証及び鍵共有」のために用いられることはなく,「暗号化」と「完全性保護」のために用いられることを示すとともに,そのようなK_eNBに関して,「暗号化」と「完全性保護」のために入力される「シーケンス番号」を本来独立であるべき複数の「鍵」間で共通に使用してはならないという原則(セキュリティの分野では当たり前のこと)を述べるとともに,「暗号化」のために用いた「シーケンス番号」を当該「暗号化」に用いた鍵と同じ鍵を用いてされる「完全性保護」においても用いることができることを述べたものである。さらに,シーケンス番号を使用して鍵を生成することによって効率的に鍵を共有することができることは,本願の優先権主張日当時,セキュリティの分野における技術常識であったものである。例えば,①乙4(国際公開2007/046376号)の段落【0027】,【0029】及び【0047】には,「所定の契機でカウントアップされる「鍵更新カウンタ値(Nc)」というシーケンス番号を使用して送信の際の暗号化のための暗号鍵Kcと受信の際の復号のための復号鍵Kcを生成していること」が,②乙5(特表2003-529288号公報)の段落【0004】ないし【0006】には,「暗号化送信に用いるキーを発生するにあたって,カウンタのカウント値Rというシーケンス番号を用いていること」が,③乙6(特開平11-109854号公報)の段落【0068】,【0072】,【0073】,【0077】,【008 0】及び【0095】には,「発呼側装置と被呼側装置との間の暗号通信に使用される通信用暗号鍵の生成に用いられる乱数に限らず「シーケンス番号」を用いてもよいこと」が,④乙7(特表平4-505694 号公報)の11頁右上欄5行～12行,11頁左下欄22行～12頁左上欄17行及び図4には,「暗号化のために用いられるキーストリームを発生するためにカウント213,214というシーケンス番号を用いていること」が記載されている。これらの文献は,シーケンス番号を使用して鍵を生成することによって効率的に鍵を共有することができることを示している。以上の引用刊行物1の記載及び技術常識を踏まえれば,当業者であれば,第5原則第2文中の「be used…for a given eNB key」の「eNB 鍵のために使用される」との記載がeNB鍵の生成,共有,配送について主として述べている文脈中に存在しながら,「eNB鍵の生成のために」使用される趣旨を含んでいないと解釈することはできず,むしろ, その趣旨を含むものと解釈するものである。したがって,本件審決がした本件和訳は,逐語的な直訳を示さなかった点では不適切であったものの,誤訳とはいえないから,本件和訳に基づいてした本件審決の引用発明の認定にも誤りはない。 (イ) 原告は,これに対し,引用刊行物1の後のバージョンである甲8及び甲9の1を踏まえると,第5原則の第2文中の「A given sequence nu mber」にいう「sequence number」とは「COUNT」を意味し,第2文は,ある所与のシーケンス番号(「COUNT」)が,(暗号化及び完全性保護に用いられる際に,)ある所与のeNB鍵を基にして得られたUP鍵(KeNB-UP-enc)及びRRC鍵(KeNB-RRC-enc,KeNB-RRC-inｔ)のために用いられるのは一度でなければならないことを述べたものであり,本件和訳は誤訳である旨主張する。しかしながら,本願の優先権主張日前に発行された乙2(3GPP TS 33.102 version 7.1.0 Release 7)には,シーケンス番号には,部分的に時間を基にしたもの,時間を基にしていないもの,完全に時間を基にしたものが存在することが記載されており,上記記載によれば,「シーケンス番号」という用語は,「シーケンス番号」としての属性を有するこれらの様々なものを当該属性に即した上位概念として示す用語であることを理解することができる。そうすると,「シーケンス番号」は,規格として定められた特定のパラメータを指すことが明示されているのであればともかく,そうでない限りは,規格とされた文献あるいは規格とされていない文献における特定のパラメータを示すものということはできない。甲8及び甲9の1は,引用刊行物1の発行後にLTEに関する規格として発行された技術文書であるが,引用刊行物1には「sequence number(シーケンス番号)」が「COUNT」である旨の記載はもちろん,「COUNT」というパラメータの定義自体が存在しないから,引用刊行物1の発行時点では,「COUNT」というパラメータやこのようなパラメータの利用方法が規格とされていなかったものといえるものであり,引用刊行物1に接した当業者が「sequence number シーケンス番号) ( 」が「COUNT」を意味し,他のシーケンス番号ではあり得ないと考えることはない。また,仮に原告が主張するように発行時点より後に規格とされた技術文書の内容を取り込む解釈が許容されることになれば,甲8において「特定的でない参照」として参照されている乙3(3GPP TS33.401 version 8.3.1 Release 8)の図6.2-2(別紙2参照)には, MMEにおいてKASMEからKeNBを生成するに当たって「NAS UP LINK COUNT」という「シーケンス番号」を用いることが図示されているから,引用刊行物1にその旨が記載されていると認定することすら可能であることになる。したがって,原告の上記主張は,理由がない。イ一致点の認定について(ア) 前記ア(ア)のとおり,引用刊行物1の記載からみて,第5原則の第 2文がeNB鍵の生成,共有,配送について主として述べている文脈において「A given sequence number…be used for a given eNB keys…」 (シーケンス番号は…eNB鍵のために使用される…)と記載しているものであって,「eNB鍵のために」使用される旨の記載がeNB鍵の生成,共有,配送について主として述べている文脈中に存在しながら「 eNB鍵の生成のために」使用される趣旨を含んでいないと解釈することはできない。本件審決は,このことを踏まえて,本件和訳をしたものであり,本件和訳に誤りはなく,本件審決の引用発明の認定に誤りはない。したがって,本件審決が「シーケンス番号…から,前記セキュリティキーK_eNBを導出する」点を本願発明と引用発明の一致点と認定したことに誤りはない。 (イ) 原告は,これに対し,引用刊行物1記載の第5原則の第2文中の「A given sequence number」にいう「sequence number」とは,「COUN T」を意味するものであり,「COUNT」はHFN及びPDCPシーケンス番号から構成されるものであるから,「NAS_U_SEQ」とは異なるシーケンス番号である,第5原則は,「E-UTRAN」すなわち「UE」と「eNB」間のネットワークのセキュリティについて述べたものであるのに対し,「NAS」は,「UE」と「MME」との間のプロトコルであり,本願発明と引用発明とは,「シーケンス番号」が用いられるプロトコルが異なるから,「シーケンス番号」の意味が異なることは,当業者にとって自明であるとして,引用発明における「シーケンス番号」には,本願発明の「NAS_U_SEQ」は含まれないから,本件審決の一致点の認定に誤りがある旨主張する。しかしながら,前記ア(イ)のとおり,引用刊行物1の「シーケンス番号」は,「シーケンス番号」としての属性を有する様々なものを当該属性に即した上位概念を示す用語であり,本願発明の「NAS_U_SEQ」が「シーケンス番号」としての属性を有する情報であれば,これが含まれないということはできない。本件審決は,相違点の判断において,「シーケンス番号」とその下位概念である「NAS_U_SEQ」とが区別されることを前提として説示したが,この区別は,「NAS_U_SEQ」がその上位概念である「シーケンス番号」としての属性を有することを前提としたものである。また,前記ア(イ)のとおり,引用刊行物1の発行時点では,「COUNT」というパラメータやこのようなパラメータの利用方法が規格とされていなかったから,引用刊行物1に接した当業者が「sequence number(シーケンス番号)」が「COUNT」を意味し,他のシーケンス番号ではあり得ないと考えることはない。さらに,本願発明の特許請求の範囲(請求項1)の「次世代パケットシステムEPSのモビリティ管理エンティティ(13)MMEにおいて,ユーザ装置(11)UEと前記UEにサービスするeNｏdeB(12)との間のRRC/UPトラフィックを保護するためにセキュリティキーK_eNBを確立する方法」との記載によれば,本願発明は「UE」と「eNB」間のセキュリティに係るものであるから,引用刊行物1が「UE」と「eNB」間のセキュリティについて述べたものであることは, 本願発明と引用発明とが異なるプロトコルについて述べたものであることの根拠にならない。したがって,原告の上記主張は理由がない。ウ小括以上によれば,原告主張の取消事由1は理由がない。 (2) 取消事由2(相違点の看過)に対しア本件審決は,引用刊行物1の摘記箇所において,本願発明の「NASサービス要求を前記UEから受信するステップ」に対応する構成が明記されていないことを踏まえて,これを一致点と認定せずに,相違点と認定した上で,相違点の判断を示している。本件審決は,相違点の判断において,「UE」からのアップリンクに「シーケンス番号」を含ませることも,当業者には知られた技術であると判断している。「UE」からのアップリンクに「シーケンス番号」を含ませることは,「UE」から上位局(UEより「網側」の局)が受信するアップリンクに「シーケンス番号」を含ませることを意味するものであり,「 UE」から様々な「アップリンク」が上位局に送信され,これを上位局が受信することを前提とするものである。したがって,「UE」からのアップリンクに「シーケンス番号」を含ませることも,当業者には知られた技術であるとの本件審決の上記判断には, 「UE」からの「アップリンク」を上位局が受信する技術が当業者に知られた技術であるとの判断が前提に含まれている。イまた,引用刊行物1(甲1,乙1)には,「NASダイレクト・メッセージ」が「UE」から「(MME中の)NAS」へ転送する(transfer)こと(7.1),「初期直接転送(Initial Direct Transfer)」という「NA Sメッセージ(NAS message)」が「RRC接続要求(RRC connection re quest)に結びつけられる (concatenated)こと(7.3)が記載され,さらに,RRCコネクション要求とNASサービス要求とがUEからeNBに送られ,その後にeNBからMMEへ送られた後にS1インターフェース (eNBとMMEとの間の通信)におけるコンテキストセットアップ手順が始まる様子(図19.2.2.3)(別紙1参照)が図示されている。これらによれば,「UE」から「RRCコネクション要求」とともに「 eNB」を経由して送られる「初期直接転送」という「NASメッセージ」ないし「NASサービス要求」を,MMEが受信するものと理解することができる。そうすると,引用刊行物1の上記記載内容に照らせば,「NASサービス要求をUEから受信するステップ」は,本願発明と引用発明との一致点であると整理することもできる。ウ以上によれば,本件審決の相違点の認定に誤りはなく,また,事実上, 「NASサービス要求を前記UEから受信するステップ」に対応する構成を一致点と整理しても,本件審決の論旨の大枠が崩れることはなく,本件審決の結論にも影響しない。したがって,原告主張の取消事由2は理由がない。 (3) 取消事由3(相違点の容易想到性の判断の誤り)に対しア前記(1)ア(ア)のとおり,引用刊行物1には,第5原則第2文において, 「eNB鍵を得るためにシーケンス番号が使用される」構成が開示されている。そして,前記(1)ア(ア)のとおり,シーケンス番号を使用して鍵を生成することによって効率的に鍵を共有することができることは,セキュリティの分野における技術常識であり,また,引用刊行物2(甲2の1)に示されているように,UEからのアップリンクにシーケンス番号が含まれていることは広く知られている。そうすると,このようなアップリンクに含まれるシーケンス番号のうち, 具体的に何を使用するかは,結局のところ,使用できるものの中から適宜選択すべきことにすぎない。しかるところ,前記(2)のとおり,引用刊行物1には「NASサービス要求をUEから受信するステップ」が事実上記載されているということができるところ,このUEからの「NASサービス要求」は,UEとeNBとの暗号化等を用いた通信の前提となるRRCコンテキストがセットアップされる前にRRCコネクションリクエストとともに行われるから,NAS サービス要求に含まれるシーケンス番号は,暗号化等を用いた通信を開始することが可能となる前の段階で追加のコストを要せず必然的にUEとM MEとの双方で利用可能となる。暗号化等に用いる鍵を生成するための情報は,暗号化等を用いた通信を開始する前の段階でUEとMMEの双方においてが利用可能である必要があるが,「NASサービス要求」に含まれるシーケンス番号は,追加のコストを要せずこの要件を満たすものなのであって,その意味では,これを利用することが望ましいものといえる。以上によれば,相違点は格別のものではなく,相違点に係る本願発明の構成は容易想到であるとした本件審決の判断に誤りはない。イ原告は,これに対し,本願明細書には,本願発明は,「K_eNB」の生成に「NAS_U_SEQ」を使用することにより,「MMEからUEへの明示的なダウンリンクNASサービス受理メッセージまたはシーケンス番号が必要ではないこと,およびNASセキュリティコンテキストの再生保護機能が,RRCおよびUPセキュリティコンテキストにおいて再利用されること」(段落【0011】)といった顕著な効果を奏することが開示されているが,本件審決が本願発明と引用発明との相違点は格別のものではないと判断するに際し,本願発明が引用発明と比べて顕著な効果を奏することを考慮していないから,上記判断は誤りである旨主張する。しかしながら,MMEからUEへの明示的なダウンリンクNASサービス受理メッセージが必要でないことは,本願明細書記載の従来技術及び引用刊行物1に記載された技術において既に達成されていた効果であって( 本願明細書の段落【0026】ないし【0028】,図1,引用刊行物1 の「19.2.2.3」参照。),本願発明に特有のものではない。また,「ユーザ装置(11)UEと前記UEにサービスするeNｏde B(12)との間のRRC/UPトラフィックを保護するため」の「セキュリティキーK_eNB」の「確立」のための「別個のシーケンス番号」の必要がなくなることは,シーケンス番号としてNASメッセージに含まれるシーケンス番号(NASセキュリティコンテキストの再生保護機能) を用いたことによる予想どおりの効果にすぎず,格別なものでない。したがって,原告の上記主張は,その前提を欠くものであり,理由がない。 (4) まとめ以上のとおり,原告主張の取消事由はいずれも理由がないから,本願発明は特許法29条2項の規定により特許を受けることができないとした本件審決の判断に誤りはない。
当裁判所の判断 1 取消事由1(引用発明及び一致点の認定の誤り)について (1) 本願明細書の記載事項についてア本願発明の特許請求の範囲(請求項1)の記載は,前記第2の2のとおりである。イ本願明細書(甲4)の「発明の詳細な説明」には,次のような記載がある(下記記載中に引用する図面について別紙本願明細書図面を参照)。 (ア) 「【技術分野】技術分野本発明は,電気通信システムにおける方法および構成に関し,特に, UEによってトリガされたサービス要求のための,EPS(次世代パケットシステム),すなわちE-UTRAN(次世代UMTS地上無線アクセスネットワーク)およびEPC(次世代パケットコアネットワーク) におけるセキュリティソリューションに関する。より具体的には,本発明は,EPS(次世代パケットシステム)用のMME(モビリティ管理エンティティ)およびUE(ユーザ装置)において,RRC/UPトラフィックを保護するためにセキュリティキーを確立する方法および構成に関する。」(段落【0001】)(イ) 「【背景技術】背景 EPSアーキテクチャでは,加入者認証は,UEとMME(モビリティ管理エンティティ)との間で実行され,かつMMEは,例えば,モビリティ,UE識別情報,およびセキュリティパラメータを管理する。E PSにおけるセキュリティ手順を定義するための基礎は,セキュリティキーK_ASMEであり,このキーは,MMEとUEとの間で共有され, かつUEの認証において確立される。ASME(アクセスセキュリティ管理エンティティ)と呼ばれる,EPSアーキテクチャの機能エンティティは,例えばMMEと同じ場所に配置してもよく,ASMEは,ホームネットワークに制限されたCK/IKキーから導出されたセキュリティキーK_ASMEを受信および記憶する。ASMEは,セキュリティキーK_ASMEから,NASシグナリング,すなわち次世代パケットコア(EPC)ネットワークのMMEとUEとの間の非アクセス層シグナリングを保護するために用いられるNASセキュリティコンテキストを導出する。NASセキュリティコンテキストには,K_NAS_en c,K_NAS_inｔなど,NASシグナリングの暗号化および完全性保護用のパラメータ,ならびにNAS_U_SEQおよびNAS_D_SEQなど,アップリンクおよびダウンリンクシーケンス番号が含まれ,シーケンス番号は,暗号化および完全性保護手順への入力だけでなく,古いメッセージの再生を防ぐために用いられる。ASMEは,MMEにNASセキュリティコンテキストを提供し,1つのNASセキュリティコンテキストが,MMEに保持され,対応するNASセキュリティコンテキストが,UEに保持され,再生保護,完全性保護および暗号化は,MMEおよびUEのNASセキュリティコンテキストのシーケンス番号が,再使用されないことに基づいている。」(段落【0002】) 「UEとサービスeNｏdeB(すなわち,EPSアーキテクチャにおける無線基地局)との間のUP/RRCトラフィックを保護するためのセキュリティコンテキストもまた,前記セキュリティキーK_ASMEに基づくのが好ましい。UP/RRCセキュリティコンテキストを確立する手順には,K_eNBと呼ばれるキーであって,これから,暗号化キーK_eNB_UP_encが,UP(ユーザ平面)すなわちEPCおよびE-UTRAN上で転送されるエンドユーザデータを保護するために導出されるキー,ならびにRRC(無線資源制御)を保護するための暗号化キーK_eNB_RRC_encおよび完全性保護キーK_eNB_RRC_inｔを導出することが含まれる。」(段落【0003】) 「図1は,EPSアーキテクチャにおける,UEが開始したアイドルからアクティブへの状態遷移のための従来の例示的なシグナリングフローを示す。アイドルUEは,EPSのEPC(次世代パケットコア)だけに認識されており,UP/RRCセキュリティコンテキストは,eNｏdeBとUEとの間には存在しない。アクティブ状態におけるUEは,EPCおよびEUTRANの両方において認識されており,UP/RRCセキュリティコンテキストが,UEとそのサービスeNｏbeBとの間でUP/RRCトラフィックを保護するために確立された。」(段落【0004】) 「図1は,UE11,eNｏdeB12,MME13,サービスGW(ゲートウェイ)14,PDNゲートウェイ15,およびHSS(ホーム加入者サーバ)16を示す。サービスゲートウェイ14は,EUTRANに向かってインタフェースを終端するEPCのノードであり,PDNゲートウェイは,PDN(パケットデータネットワーク)に向かってインタフェースを終端するEPCのノードである。UEが複数のPDNにアクセスする場合には,そのUEのために複数のPDNゲートウェイがあってもよい。信号S1および信号S2では,NASサービス要求は,UEからMMEへ透過的に転送され,かつNASサービス要求は,NAS_U_SEQに基づいて,完全性が保護される。オプションの信号S3では,UEは,MMEによって認証され,K_ASMEは,HSS(ホーム加入者サーバ)に記憶された加入者データを用いて確立され,MMEは,S4で,初期コンテキストセットアップ要求をeNｏdeBに送信する。信号S5およびS6では,eNｏdeBは,UEとの無線ベアラを確立してアップリンクデータを転送し,信号S7で,初期コンテキストセットアップ完了メッセージをMMEへ返す。信号S8では,MMEは,更新ベアラ要求をサービスGWに送信し,サービスGWは,信号S9で応答する。」(段落【0005】) 「従来のソリューションでは,RRC/UPセキュリティコンテキスト用の,UEおよびMMEによるK_eNBの導出は,例えば,MMEからUEに送信されたNASサービス受理メッセージまたは他の明示的な情報に基づいている。しかしながら,図1における例示的な従来のEPSシグナリングフローに示されているように,MMEは,通常,EPSにおいて,UEからNASサービス要求を受信しても,いかなるNASサービス受理も送信しない。したがって,NASサービス受理メッセージにおける情報からK_eNBを導出することは不可能である。」(段落【0006】) 「例示的な公知のソリューションによれば,K_eNBは,NASサービス受理メッセージにおいてMMEによって用いられるK_ASMEおよびNAS_D_SEQからMMEによって導出され,UEは,NASサービス受理メッセージからシーケンス番号NAS_D_SEQを検索し,かつMMEと同じK_eNB導出を実行することによって,同じK_eNBを導出する。MMEは,それがeNｏdeBへのS1接続を設定する場合に,K_eNBをeNｏdeBに転送する。しかしながら,この公知のソリューションの欠点は,明示的なNASサービス受理メッセージがMMEからUEに対して定義されない場合には,図1における例示的な従来のEPSシグナリングフローにおけるように,UEが,MMEと同じK_eNBを導出することは不可能であることである。たとえUEが,現在のNASダウンリンクシーケンス番号NAS_D_SEQを推定することが技術的に可能であっても,この推定は誤っている可能性がある。なぜなら,MMEは,損失してUEによって決して受信されなかったNASメッセージを送信したかもしれないからである。かかる場合には,MMEは,そのNAS_D_SEQを更新し,UEが,この更新に気づくこともなく,UEにおける誤ったNAS_D_SEQにつながることになろう。」(段落【0007】)「別の例示的な公知のソリューションによれば,K_eNBの導出は,特にK_eNBの導出のために保持される別個のシーケンス番号に基づき,このシーケンス番号は,UEがそれをMMEに送信するかまたはMMEがそれをUEに送信することによって,NASサービス要求手順の間に明示的に同期される。しかしながら,このソリューションの欠点は, 別個のシーケンス番号の特別な複雑さである。なぜなら,再生攻撃を防ぐために,別個のシーケンス番号をUEおよびMMEの両方において保持しなければならないからである。」(段落【0008】)(ウ) 「【発明が解決しようとする課題】概要本発明の目的は,上記で概説した課題に取り組むことであり,この目的および他の目的は,独立請求項による方法および構成ならびに従属請求項による実施形態によって達成される。」(段落【0009】)(エ) 「【課題を解決するための手段】本発明の基本的な考えは,K_eNBが,K_ASMEから,および UEからMMEへのNASサービス要求メッセージのNAS_U_SE Qから導出され,それによって,eNｏdeBにおけるUP/RRCセキュリティコンテキストの確立をトリガするということである。」(段落【0010】) 「MMEからUEへの明示的なダウンリンクNASサービス受理メッセージまたはシーケンス番号が必要ではないこと,およびNASセキュリティコンテキストの再生保護機能が,RRCおよびUPセキュリティコンテキストにおいて再利用されることが,本発明の利点である。」( 段落【0011】) 「一態様によれば,本発明は,次世代パケットシステムEPSのモビリティ管理エンティティMMEにおいて,ユーザ装置UEとUEにサービスするeNｏdeBとの間のRRC/UPトラフィックを保護するためにセキュリティキーK_eNBを確立する方法を提供する。この方法には,UEからNASサービス要求を受信するステップであって,この要求が,NASアップリンクシーケンス番号NAS_U_SEQを示すステップと,少なくとも前記受信されたNAS_U_SEQから,および前記UEと共有される,記憶されたアクセスセキュリティ管理エンティティキーK_ASMEからセキュリティキーK_eNBを導出するステップと,前記導出されたK_eNBを,前記UEにサービスするeNｏdeBに転送するステップと,が含まれる。」(段落【0012】) 「第2の態様によれば,本発明は,次世代パケットシステムEPS用のモビリティ管理エンティティMMEを提供する。MMEは,UEとUEにサービスするeNｏdeBとの間のRRC/UPトラフィックを保護するために,セキュリティキーK_eNBを確立するように構成される。MMEには,UEからNASサービス要求を受信するための手段であって,この要求が,NASアップリンクシーケンス番号NAS_U_SEQを示す手段と,少なくとも前記受信されたNAS_U_SEQから,および前記UEと共有される,記憶されたアクセスセキュリティ管理エンティティキーK_ASMEからK_eNBを導出するための手段と,ならびに,前記導出されたK_eNBを,前記UEにサービスするeNｏdeBに送信するための手段と,が含まれる。」(段落【0013】) 「第1および第2の態様は,さらに,方法および対応する手段を提供し,これらに従って,MMEが,擬似乱数関数PRFを用いてNAS_U_SEQおよびK_ASMEからK_eNBを導出可能になる。MMEは,さらに,受信された下位ビットから完全なNASアップリンクシーケンス番号NAS_U_SEQを再構成し,UEから受信されたNASサービス要求の完全性を検査してもよい。さらに,MMEは,受信されたNAS_U_SEQの通知をUEに返してもよく,NAS_U_SEQは,K_eNBをeNｏdeBに転送するセットアップメッセージに含まれていてもよい。それによって,UEは,MMEに送信されるNAS_U_SEQを覚えている必要がない。」(段落【0014】)(オ) 「【発明を実施するための形態】詳細な説明以下の説明では,本発明の完全な理解を提供するために,特定のアーキテクチャおよびステップシーケンスなどの特定の詳細が記載される。しかしながら,本発明が,これらの特定の詳細から逸脱する可能性がある他の実施形態において実行し得ることは,当業者には明らかである。」 (段落【0020】) 「本発明の概念は,セキュリティキーK_eNBが,アクセスセキュリティ管理エンティティキーK_ASMEから,およびUEからMME に送信されるNASサービス要求メッセージのアップリンクシーケンスカウンタNAS_U_SEQから導出され,それによって,eNｏde BにおいてUP/RRCセキュリティコンテキストの確立をトリガするということである。」(段落【0022】) 「UEがアイドルモードにある場合には,NASセキュリティコンテキストが,存在しかつ例えば,上記のK_NAS_enc,K_NAS _inｔ,NAS_U_SEQ,およびNAS_D_SEQを含み,N ASメッセージは,完全性および場合により機密性を保護される。したがって,NASセキュリティコンテキストにはまた,UEのセキュリティ能力,特に暗号化および完全性アルゴリズムが含まれる。」(段落【 0023】) 「NASメッセージの保護は,NASセキュリティキーK_NAS_ enc,K_NAS_inｔ,ならびにメッセージの方向についてアップリンクおよびダウンリンクシーケンスカウンタNAS_U_SEQまたはNAS_D_SEQに基づいている。完全なシーケンスカウンタは, 通常,NASメッセージと共に送信されず,下位ビットいくつかだけであり,完全なシーケンス番号は,上位ビットの局所推定および受信された下位ビットから,受信端で再構成される。」(段落【0024】) 「図1における従来のシグナリング図のS1およびS2では,NASサービス要求は,アップリンクシーケンスカウンタNAS_U_SEQを含むが,UEからMMEに転送され,NASサービス要求メッセージは,前記NAS_U_SEQに基づいて完全性が保護される。MMEは,メッセージの完全性を検査し,それが再生でない場合には,それを受理し,これによって,NAS_U_SEQが,新しく以前に用いられなかったことが保証される。」(段落【0026】) 「その後,本発明によれば,MMEは,少なくとも,受信されたアップリンクシーケンスカウンタNAS_U_SEQおよびK_ASMEに基づき,従来のキー導出関数を用いて,K_eNBを導出するが,これは,図1に示す従来のシグナリング図には含まれない。したがって,シーケンスカウンタは,認証においてのみリセットしてもよい。MMEは,信号S4のメッセージ,初期コンテキストセットアップ要求(S1-AP)で,またはそこに相乗りして,導出されたK_eNBをeNｏdeBに送信する。」(段落【0027】) 「信号S5では,eNｏdeBは,無線ベアラ確立およびセキュリティ構成メッセージ(セキュリティモードコマンド)をUEに送信する。図1におけるように,これらのメッセージは,2つの別個のメッセージとして,または1つのメッセージに組み合わせて送信してもよく,UEによるこれらのメッセージの受信は,暗黙のうちに,信号S1におけるUEのNASサービス要求の確認になる。セキュリティモードコマンドは,例えば,保護がいつ開始すべきかおよびどのアルゴリズムを用いるべきかを決定する。」(段落【0028】) 「本発明によれば,UEは,信号S5でメッセージを受信すると,以前に実行されていない場合には,少なくともNAS_U_SEQおよび K_ASMEに基づき,従来のキー導出関数を用いて,K_eNBを導出する。その後,eNｏdeBおよびUEは,UP/RRCセキュリティコンテキストを確立するが,これは,図1における従来のシグナリング図には示されていない。」(段落【0029】)(カ) 「図2は,本発明の第1の実施形態を示すが,この場合には,UE は,信号S24におけるK_eNBの導出のために,信号S21における初期NASサービス要求メッセージのNAS_U_SEQを保持する。MMEは,信号S21でUEからNAS_U_SEQを受信するか, またはNAS_U_SEQを示す下位ビットだけを受信し,NAS_U _SEQおよびK_ASMEに基づいてS22においてK_eNBを導出する。MMEは,導出されたK_eNBを信号S23でeNｏdeB に転送する。」(段落【0032】) 「その後,図2には示していないが,eNｏdeBおよびUEは,K _eNBを用いてUP/RRCセキュリティコンテキストを確立するが,UP/RRCセキュリティコンテキストには,UPトラフィックを保護するための暗号化キーK_eNB_UP_enc,ならびにRRC トラフィックの保護のための暗号化キーおよび完全性保護キー,K_e NB_RRC_encおよびK_eNB_RRC_inｔがそれぞれ含まれ,それによって,信号S25において安全なUP/RRCトラフィックを可能にする。」(段落【0033】) 「K_eNBの導出は,従来のキー導出関数によって,例えば擬似乱数関数K_eNB=PRF(K_ASME,NAS_U_SEQ, . ) . . によって,実行される。」(段落【0034】)(キ) 「図3は,本発明による方法を示す流れ図であり,ステップ31において,UE11は,初期NASサービス要求メッセージをMME13 に送信するが,このメッセージは,通常,カウンタの下位ビットだけを送信することによって,NASアップリンクシーケンスカウンタNAS _U_SEQを示す。ステップ32において,MMEは,UEからNA Sサービス要求メッセージを受信し,NAS_U_SEQを取得し,受信された下位ビットから完全なシーケンスを再構成する。ステップ33 において,MMEは,適切なキー導出関数,例えば擬似乱数関数を用いて,少なくとも受信したNAS_U_SEQ,およびASME(アクセスセキュリティモビリティエンティティ)からのK_ASMEから,セキュリティキーK_eNBを導出する。」(段落【0036】) 「その後,MMEは,ステップ34において,UEと共有される完全なUP/RRCセキュリティコンテキストを確立するためにeNｏde Bによって用いられるように,導出されたK_eNBをeNｏdeB1 2に転送する。ステップ35において,前記UEは,少なくとも記憶されたK_ASMEから,およびステップ31においてUEからMMEに送信された初期NASサービス要求メッセージのNAS_U_SEQから,同じK_eNBを導出し,導出されたK_eNBからUP/RRC セキュリティコンテキストを確立する。」(段落【0037】) 「本発明の第1の実施形態では,UEは,初期NASサービス要求メッセージでMMEに送信されたNAS_U_SEQを記憶し,記憶されたシーケンス番号を用いてK_eNBを導出する。」(段落【0038 】)(ク) 「図6aは,本発明に従って,EPS用のMME13(モビリティ管理エンティティ)を示すが,このMME13は,UEとサービスeN ｏdeBとの間のUP/RRCトラフィックを保護するためのセキュリティコンテキスト用のセキュリティキーK_eNBを確立するようにさらに構成される。MMEには,図示していないが,EPSにおけるノードと,例えばS1-MMEインタフェースを介してeNｏdeBｓと通信するための従来の通信手段が設けられる。さらに,図1のMMEでは,ASME(アクセスセキュリティ管理エンティティ)61が,破線によって示されている。なぜなら,EPSのこの機能エンティティは,MMEと同じ場所に配置してもよいからである。」(段落【0043】) 「セキュリティキーK_eNBを確立するための,図6aに示すMME13の手段には,(UEのサービスeNｏdeBを介した)UEからのNAS_U_SEQを含むNASサービス要求メッセージを受信するために受信手段62と,従来のキー導出関数を用い,少なくとも受信されたNAS_U_SEQおよび記憶されたK_ASMEに基づいて,セキュリティキーK_eNBを導出するためのキー導出手段63と,導出されたK_eNBを,UEにサービスするeNｏdeBに送信するための送信手段64と,が含まれる。」(段落【0044】)「図6bは,本発明によるUE11(ユーザエンティティ)を示すが,UEは,EPS用に構成され,さらに,UEのサービスeNｏdeBと交換されるUP/RRCトラフィックを保護するためのセキュリティコンテキスト用のセキュリティキーK_eNBを確立するように構成される。UEには,そのサービスeNｏdeBへのLTE-Uｕインタフェースを介してEPSにおけるノードと通信するための従来の通信手段(図示せず)が設けられる。」(段落【0045】) 「セキュリティキーK_eNBを確立するための,図6bに示すUE11の手段には,サービスeNｏdeBを介して,NASサービス要求メッセージをMMEに送信するための送信手段66であって,この要求が,アップリンクシーケンス番号NAS_U_SEQを示す手段が含まれ,セキュリティキーK_eNBを確立するための手段には,従来のキー導出関数を用い,少なくともNAS_U_SEQおよび記憶されたK_ASMEに基づいて,セキュリティキーK_eNBを導出するためのキー導出手段67が含まれる。」(段落【0046】)ウ前記ア及びイによれば,本願明細書には,本願発明に関し,以下の点が開示されていることが認められる。 (ア) EPS(次世代パケットシステム)においてUEが開始したアイドルからアクティブへの状態遷移のための従来の例示的なシグナリングフロー(別紙本願明細書図面の図1参照)においては,MMEとUEとの間の非アクセス層シグナリングを保護するためにNASセキュリティコンテキストが用いられ,UEとサービスeNｏdeBとの間のUP/R RCトラフィックを保護するためにUP/RRCセキュリティコンテキストが用いられる(段落【0002】ないし【0004】)。UP/R RCセキュリティコンテキストを確立する手順には,K_eNBと呼ばれるキーが導出され,K_eNBから,エンドユーザデータを保護するための暗号化キーK_eNB_UP_enc,RRC(無線資源制御) を保護するための暗号化キーK_eNB_RRC_enc及び完全性保護キーK_eNB_RRC_inｔを導出することが含まれる(段落【 0003】)。従来のソリューションでは,RRC/UPセキュリティコンテキスト用のUE及びMMEによるK_eNBの導出は,例えば,MMEからU Eに送信されたNASサービス受理メッセージ又は他の明示的な情報に基づいているが,従来の例示的なシグナリングフローにおいては,MM Eは,通常,EPSにおいて,UEからNASサービス要求を受信しても,いかなるNASサービス受理も送信しないため,NASサービス受理メッセージにおける情報からK_eNBを導出することは不可能であった(段落【0006】)。また,別の例示的な公知のソリューションによれば,K_eNBの導出は,K_eNBの導出のために保持される別個のシーケンス番号を,UEがMMEに送信するか,または,MME がUEに送信することによって行われるが,別個のシーケンス番号をU E及びMMEの両方において保持しなければならないため,複雑であるという欠点があった(段落【0008】)。 (イ) 本願発明のMMEにおける方法は,従来のRRC/UPセキュリティコンテキスト用のUE及びMMEによるK_eNBの導出における上記課題を解決することを目的とし,K_eNBが,アクセスセキュリティ管理エンティティキーK_ASMEから,及びUEからMMEに送信されるNASサービス要求メッセージのアップリンクシーケンス番号N AS_U_SEQから導出され,それによって,eNｏdeBにおいて UP/RRCセキュリティコンテキストの確立をトリガするようにするため(段落【0022】),NASサービス要求を前記UEから受信するステップ(32)であって,前記要求が,NASアップリンクシーケンス番号NAS_U_SEQを示すステップと,少なくとも前記受信されたNAS_U_SEQから,および前記UEと共有される,記憶されたアクセスセキュリティ管理エンティティキーK_ASMEから,前記セキュリティキーK_eNBを導出するステップ(33)と,前記導出されたK_eNBを,前記UEにサービスする前記eNｏdeB(12) に転送するステップ(34)と,を含む構成を採用した。 (ウ) 本願発明は,MMEからUEへの明示的なダウンリンクNASサービス受理メッセージ又はK_eNBの導出のために保持される別個のシーケンス番号を必要とせず,また,NASセキュリティコンテキストの再生保護機能が,RRC及びUPセキュリティコンテキストにおいて再利用されるという利点を有する(段落【0011】)。 (2) 引用刊行物1の記載事項について引用刊行物1(甲1,乙1)には,次のような記載がある(「図面」については別紙1を参照)。ア「EUTRANのアーキテクチャを,以下の図4に示す。 4.1 機能の分割eNBは,次の機能を実施する:- 無線機能管理のための機能:無線ベアラ制御,無線アドミッション制御,接続モビリティ管理,アップリンクと,ダウンリンクの双方における,UEのための資源の動的配置(スケジューリング);- IPヘッダの圧縮,及び,ユーザ・データ・ストリームの暗号化;- UE接続時の,MMEの選択;注: UE接続時,はじめにMMEは,含まれている,即ち,実質的には,MMEは選択されていると,仮定する。 - サービス・ゲートウェイへのユーザ・プレーン・データのルーティング;注: どのノードがユーザ・プレーン・トンネルを実際に設立するかは,次の検討である。注: ユーザ・プレーン・トンネルの確立が,RRC起動と共に起こるかどうかは,次の検討である。 - (MMEからのものである)ページング・メッセージのスケジューリングと送信;- (MME,或いは,O&Mからのものである)ブロードキャスト情報のスケジューリングと送信;- モビリティ,及び,スケジューリングのための測定と,計測報告の設定.MMEは,次の機能を実施する:- eNBへのページング・メッセージの分配;- セキュリティ制御;- アイドル状態モビリティ制御;- SAEベアラ制御;- NAS信号伝達の暗号化と完全性保護.サービス・ゲートウェイは次の機能を実施する:- ページング理由のための,U-プレーン・パケットの終端(次の検討である);- UEモビリティのサポートのためのU-プレーンの切替.」(甲1抄訳) 「4.3.2 制御プレーン下の図(判決注・図4.3.2)は,制御プレーンのためのプロトコル・スタックを示している,それは,- (ネットワーク側のeNBで終端される)PDCPサブレイヤは,ユーザプレーンと同様のセキュリティ機能を実行するが,ヘッダの圧縮は実行しない;- (ネットワーク側のeNBで終端される)RLCおよびMACサブレイヤは,ユーザプレーンと同様の機能を実行する;- (ネットワーク側のeNBで終端される)RRCは,従属節7に一覧されている機能を実行する,たとえば: - ブロードキャスト; - ページング; - RRC接続管理; - RB制御; - モビリティ機能; - UE測定報告および制御;- (ネットワーク側のMMEで終端されている)NAS制御プロトコルは,とりわけ次を実行する。 - SAEベアラ管理; - 認証; - LTE_IDLE モビリティ・ハンドリング; - LTE_IDLEでのページングの開始; - セキュリティ制御注:NAS制御プロトコルは,このTSの範囲で取り扱われず,情報としてのみ言及される。」(乙1抄訳)イ「7 RRC この従属節は,RRCサブレイヤによって提供されるサービスと機能の概観を提供する。 7.1 サービスと機能RRCサブレイヤの主なサービスと機能は,次を含む: -非アクセス層(NAS)に関連するシステム情報のブロードキャスト ; - アクセス層(AS)に関連するシステム情報のブロードキャスト; - ページング; - 以下を含む,UEとE-UTRAN間のRRC接続の確立,維持,及び, 解除; - UEとE-UTRAN間の一時的な識別子の割当; - RRC接続のための信号無線ベアラの設定: - 低品位SRBと高品位SRB - 以下を含むセキュリティ機能: - RRCメッセージのための完全性保護 - ポイントツーポイント無線ベアラの確立,維持,及び,解除; - 以下を含むモビリティ機能 - セル間,及び,RAT間モビリティのためのUE測定報告,及び, 報告の制御; - セル間ハンドオーバ - UEセル選択と再選択,及び,セルの選択と再選択の制御; - eNB間のコンテキスト転送 - MBMSサービスのための通知(次の検討である); - MBMSサービスのための無線ベアラの確立,配置,維持,及び, 解除(次の検討である); - QｏS管理機能; - UE測定報告,及び,報告の制御; - MBMS制御(次の検討である); - NASダイレクト・メッセージのUEからNASへ/NASからU Eへの転送」「7.3 NASメッセージの転送 E-UTRAN内で,NASメッセージはRRCメッセージに結びつけられるか,結びつけられることなく,RRCに入れられる。初期直接転送は,もし転送ブロックサイズが許せば,RRC接続要求に結びつけられる(次の検討である)。他のNASメッセージは,おそらく,(同期したNAS/RRC手続のための)RRCメッセージ,に結びつけられる。注:NASによって実行された完全性保護と暗号化に加えて,NAS メッセージは,RRCによって完全性が保護され,PDCPによって暗号化されている。」 (以上,乙1抄訳)ウ (原文) 「14 Security14.1 Overview and PrinciplesThe following principles apply to E-UTRAN security:」「- The eNB keys are cryptographically separated from the EPC keys used for NAS protection (making it impossible to use the eNB key to figure out an EPC key).」(第1原則) 「- The keys are derived in the EPC/UE from key material that was generated by a NAS (EPC/UE) level AKA procedure.」(第2原則) 「- The eNB keys are sent from the EPC to the eNB when the UE isentering LTE_ACTIVE state (i.e. during RRCconnection or S1 contextsetup).」(第3原則) 「- Key material for the eNB keys is sent between the eNBs during LTE_ACTIVE intra-E-UTRAN mobility.」(第4原則) 「- A sequence number is used as input to the ciphering and integrity protection. A given sequence number must only be used once for a given eNB key (except for identical re-transmission). The same sequence number can be used for both ciphering and integrity protection.」(第5原則) 「- A hyper frame number (HFN) (i.e. an overflow counter mechanism) is used in the eNB and UE in order to limit the actual numberof sequence number bits that is needed to be sent over the radio.The HFN needs to be synchronized between the UE and eNB.」(第6原則) 「As a result of an AKA run, the EPC and the UE share a base-key named K_ASME. From K_ASME, the NAS, (and indirectly) K_eNB keys are derived. The K_ASME never leaves the EPC,but the K_eNB keyis transported to the eNB from the EPC when the UE transitions toLTE_ACTIVE. From the K_eNB, the eNB and UE can derive the UP andRRC keys. When the UE goes into LTE_IDLE or LTE_DETACHED, the K_eNB, UP and RRC keys are deleted from the eNB. The key hierarchy is depicted on Figure 14.1-1 below:」(概説) 「14 セキュリティ14.1 概説及び原則次の原則は,E-UTRANのセキュリティに適用される:- (EPC鍵を見つけ出すためにeNB鍵を用いることが不可能なように)eNB鍵は,暗号によって,NAS保護のために用いられるEPC鍵から分離される.」(第1原則) 「- その鍵は,EPC/UEにおいて,NAS(EPC/UE)レベルAKA手続によって生成された,鍵素材から得られる。」(第2原則) 「- eNB鍵は,UEが,LTE_ACTIVE状態に入ると(即ち,RRC接続,或いは,S1コンテキスト設定の間),EPCから,eNBに送られる。」(第3原則) 「- eNB鍵のための鍵素材は,LTE_ACTIVE イントラ-E-UTRANモビリティの間に,eNBの間に送られる。」(第4原則) 「- シーケンス番号は,暗号化,及び,完全性保護のための入力として用いられる。所与のあるシーケンス番号は,所与のあるeNB鍵のために使用されるのは,(同一の再送のためを除いて)一度のみでなければならない。同一のシーケンス番号が,暗号化と,完全性保護の両方に用いることができる。」(第5原則) 「- ハイパー・フレーム番号(HFN)(即ち,桁あふれ計数機構)は,無線上に送られるために必要な連続番号ビットの実数を制限するためにeNBとUEの中で使用される。UEとeNBの間でHFNを同期する必要がある。」(第6原則) 「AKA(判決注:認証及び鍵共有のためのプロトコル)実行の結果として,EPCとUEは,K_ASMEという名の基本鍵を共有する。K_A SMEから,NAS(そして,間接的に),K_eNBが得られる。K_ ASMEは,決して,EPCから離れない。しかしながら,K_eNB鍵は,UEが,LTE_ACTIVEに移行すると,EPCからeNBに運ばれる。K_eNBから,eNB,及び,UEは,UP,及び,RRC鍵を得ることができる。UEが,LTE_IDLE,或いは,LTE_DE TACHEDの状態になると,K_eNB,UP,及び,RRC鍵は,e NBから消去される。鍵階層は,下の図14.1-1に描かれている。」 (概説) (以上,甲1抄訳)(3) 引用発明の認定の誤りの有無について原告は,本件審決が,本件審決が引用刊行物1の「A given sequence numb er must only be used once for a given eNB key」(第5原則第2文)との記載について「得られたシーケンス番号は,eNB鍵を得るために使用されるのは,一度のみでなければならない」と和訳(本件和訳)した上で,上記記載箇所から「“eNB鍵を得るために,シーケンス番号が使用される”ことが読み取れる。」と認定したが,本件和訳は誤訳であり,引用刊行物1には,他に「K_eNB」を導出する手法についての開示はないから,「K_ eNBを得るために,シーケンス番号が使用され」る構成についての開示はないとして,本件審決が認定した引用発明のうち,「前記K_eNBを得るために,シーケンス番号が使用され」との部分は誤りである旨主張するので, 以下において判断する。アまず,引用刊行物1記載の第5原則第2文の「 A given sequence numbe r must only be used once for a given eNB key (except for identical re-transmission).」は,その文理からみて,「所与のあるシーケンス番号は,所与のあるeNB鍵のために使用されるのは,(同一の再送のためを除いて)一度のみでなければならない。」(前記(2)ウ)と和訳するのが自然である。そこで,第5原則第2文の「所与のあるシーケンス番号は,所与のある eNB鍵のために使用されるのは,(同一の再送のためを除いて)一度のみでなければならない。」にいう「eNB鍵のために使用される」との意義について検討する。イ前記(2)によれば,引用刊行物1の「14.1 概説及び原則」には,第 1原則としてeNB鍵(K_eNB)はEPC鍵から分離されること,第 2原則としてeNB鍵はEPC/UEにおいてNAS(EPC/UE)レベルAKA手続によって生成された鍵素材から得られること,第3原則としてUEがLTE_ACTIVE状態に入ると,eNB鍵はEPCからe NBに送られること,第4原則としてeNB鍵のための鍵素材はeNB間で送られること,第6原則としてシーケンス番号を構成するハイパー・フレーム番号(HFN)についての記載があり,また,これらの「原則」に引き続き記載されている「概説」には,EPC及びUEが共有するK_A SMEという名称の基本鍵からK_eNBが得られることや,eNB及び UEにおいてK_eNBからUP及びRRC鍵を得られることが記載されている。このように「14.1 概説及び原則」には,第5原則の前後の文脈において,eNB鍵(K_eNB)の「生成」及び「共有」(第2原則,概説),「転送」(第3原則,概説)に関する記載がある。そして,第5原則には,eNB鍵(K_eNB)と「シーケンス番号」との関係に関し,「所与のあるシーケンス番号は,所与のあるeNB鍵のために使用されるのは,(同一の再送のためを除いて)一度のみでなければならない。」(第2文)との記載がある。一方で,第5原則には,「シーケンス番号」に関し,「シーケンス番号」が暗号化及び完全性保護のための入力として用いられること(第1文), 同一の「シーケンス番号」が暗号化と完全性保護の両方に用いることができること(第3文)についての記載があるが,「14.1 概説及び原則」には,第5原則第2文にいう「所与のあるシーケンス番号」が「eNB鍵のために使用される」ことについて,その使用の具体的な態様を明示した記載はない。ウ被告は,この点に関し,シーケンス番号を使用して鍵を生成することによって効率的に鍵を共有することができることは,本願の優先権主張日当時,セキュリティの分野における技術常識であったことを踏まえると,シーケンス番号が「eNB鍵のために使用される」とは,シーケンス番号が「eNB鍵の生成のため」に使用されることを意味する旨主張するので, 以下において,本願の優先権主張日当時におけるシーケンス番号に関する技術常識について検討する。 (ア) 乙6の記載事項 a 乙6には,図1,図5及び図6とともに,以下の記載がある(上記各図面については別紙3を参照)。 (a) 「【発明の属する技術分野】本発明は,通信の安全性を高めるために,暗号を用いて通信する暗号通信装置に関し,特に,暗号通信に先立って行われる暗号鍵伝送時の手間を簡略化できる暗号通信装置に関するものである。」(段落【0001】) (b) 「一方,本実施形態に係る暗号鍵生成部52は,暗号通信に先立って,後述する手順で通信相手の暗号通信装置3bと通信してネゴシエーションする。これにより,暗号鍵生成部52は,送信した暗号化乱数を,上記送信暗号化乱数領域42へ格納すると共に,受信した暗号化乱数を,受信暗号化乱数領域43へ格納する。さらに, 暗号鍵生成部52は,両暗号化乱数に基づき,暗号通信時に使用される通信用暗号化鍵および通信用復号化鍵を生成して暗号処理部51へ通知できる。」(段落【0068】) 「両暗号通信装置3a・3bが通信可能になると,発呼側の暗号通信装置3aは,図5に示すステップS1aにて,乱数A1を生成し,S2aにて,通信相手の暗号通信装置3bへ当該乱数A1を送出する。なお,以下では,発呼側の暗号通信装置3aが実行するステップには,例えば,S1aのように,符号の末尾にaを付して参照し,被呼側の暗号通信装置3bが実行するステップには,S1bのように,符号の末尾にbを付して参照する。」(段落【0072】) 「一方,被呼側の暗号通信装置3bは,S1bにて,暗号通信装置3aから乱数A1を受け取ると,S2bにおいて,予め共有された共有鍵Oを用いて,当該乱数A1を暗号化する。これにより,暗号化乱数A2が生成される。さらに,暗号通信装置3bは,S3bにおいて,発呼側の暗号通信装置3aへ,生成した暗号化乱数A2を送り返す。」(段落【0073】) 「さらに,発呼側と被呼側とを入れ換えて,上記S1a～S5aおよびS1b～S3bと同様のステップが行われる(S11b～S15bおよびS11a～S13a)。これらのステップでは,両暗号通信装置3a・3bは,被呼側の暗号通信装置3bが生成した乱数B1に基づいて,暗号化乱数B2・B3をそれぞれ生成する。これにより,被呼側の暗号通信装置3bは,発呼側の暗号通信装置3aを認証できる。」(段落【0077】)「両暗号通信装置3a・3bが通信相手による認証に成功すると,図6に示すように,上記両暗号化乱数A2・B2に基づいて,暗号通信に使用される通信用暗号鍵が生成される。すなわち,発呼側の暗号通信装置3aは,S21aにおいて,自ら(発呼側)が生成した暗号化乱数B2を共有鍵Oで暗号化して,暗号化データB4を生成する。また,S22aにおいて,受け取った暗号化乱数A2を共有鍵Oで暗号化して,暗号化データA5を生成する。」(段落【0 080】) (c) 「また,本実施形態では,図5のステップS1a・S2a,および,S11b・S12bに示すように,両暗号通信装置3a・3b が乱数を生成して送出する場合について説明したが,これに限るものではない。例えば,日付や時刻,あるいは,シーケンス番号などを用いてもよい。両暗号通信装置3a・3bが通信毎に異なるデータを送出すれば,本実施形態と同様の効果が得られる。」(段落【 0095】) b 前記aの記載事項によれば,乙6には,暗号通信に使用される通信用暗号鍵の生成に,「乱数」や「シーケンス番号」が用いられることが開示されているものと認められる。 (イ) 乙7の記載事項 a 乙7には,第4図とともに,以下の記載がある(第4図については別紙4を参照)。 (a) 「発明の分野本発明は,ディジタル領域式通信システムに関し,特にそのようなシステム内のデータ通信の暗号化用の方法および装置に関する。」 (5頁左下欄4行～7行) (b) 「本発明の特定な実施例の特定な説明をこれから行なう。上述の通り,かつ以下に使用される通り,「キーストリーム」という語は, 未確認アクセス,例えばRFチャネルの影響を受けやすい媒体にある記憶を伝送する前に,ディジタル符号式メツセージまたはデータ信号を暗号化するのに用いられた2進ビットまたはビットのブロックの擬似ランダム・シーケンスを意味する。」(11頁右上欄5行～12行)(c) 「第4図を参照すると,従来技術の日毎定時刻駆動による暗号化システムの略ブロック図を見ることができる。第4図の上半分は, 送信機部分を表わし,下半分はそのような暗号化システムの受信機部分を表わす。送信機部分では,タイム・クロックまたはブロック・カウンタ201はカウント213,例えばタイム・クロックまたはブロック・カウンタ201の入力に加えられる増分215に応じて,32-ビットの出力を発生させる。カウント213は,結合式論理または混合工程202に第1入力として供給される。例えば, 2進記法の値968173であるシークレット・キーは,第2入力 211として,結合式論理または混合工程202の第2入力として供給される。カウント213に対して新しい値が生じるごとに,結合式論理または混合工程202は,シークレット・キー211をカウント213と結合させたり混合して,直列または並列出力209 で複数の擬似ランダム・キーストリーム・ビットを発生させる。キーストリーム出力209は,同時に,モジュロ-2加算器203に入力として供給される。暗号化すべきデータは,モジュロ-2加算器203に第2入力207を形成する。各キーストリーム・ビットは,モジュロ-2加算機203によって特定のデータ・ビットに加えられるモジュロ-2であり,暗号式データは媒体を通して伝送する出力218に供給される。受信機部分では,タイム・クロックまたはクロック・カウンタ2 04は,タイム・クロックまたはブロック・カウンタ201と構造が同じであり,増分215と同じ増分216を供給され,結合式論理または混合工程202と構造が同じである結合式論理または混合工程205にカウント214を供給する。結合式論理または混合工程205は,カウント214を同一なシークレット・キー,すなわち入力212に供給される2進記法の968173と結合させたり混合したりするが,それによって出力210にキーストリームを作り,この出力は出力209で作られたキーストリームと同じである。キーストリーム出力210は,モジュロ-2加算器206によって伝送媒体で受信された暗号式データに少しずつ加えられるモジュロ -2である。モジュロ-2加算およびモジュロ-2減算は同じ操作であり,受信機における同一キー・ストリームのモジュロ-2加算は送信機におけるキーストリームの前の加算を打ち消して,出力2 08で原データの回復をもたらす。しかし,暗号式データのそのような打消しおよび正しい解読は,タイム・クロックまたはブロック・カウンタ2f01,204が相互に完全に同期機構217は,この目的で供給されなければならない。」(11頁左下欄22行～1 2頁左上欄17行) b 前記aの記載事項によれば,乙7には,暗号鍵である「キーストリーム」の生成に,シーケンス番号である「カウント」が用いられることが開示されているものと認められる。 (ウ) 引用刊行物2の記載事項引用刊行物2(甲2の1)のFIG.3A(別紙5)によれば,引用刊行物2には,「Fｕll Seｑｕence Nｕmbeｒ」(フルシーケンス番号)が「Keｙｓｔｒeam」(キーストリーム)の生成に用いられることが開示されているものと認められる。 (エ) 検討以上によれば,本願の優先権主張日当時,暗号鍵の生成に,シーケンス番号が用いられることは,当業者の技術常識であったものと認められる。エ前記イのとおり,引用刊行物1の「14.1 概説及び原則」には,第 5原則第2文にいう「所与のあるシーケンス番号」が「eNB鍵のために使用される」ことについて,その使用の具体的な態様を明示した記載はない。しかるところ,「14.1 概説及び原則」には,第5原則の前後の文脈において,eNB鍵(K_eNB)の「生成」及び「共有」(第2原則, 概説),「転送」(第3原則,概説)に関する記載があり(前記イ),第 5原則は,そのような一連の文脈の中で理解されるべきものであること, 本願の優先権主張日当時,暗号鍵の生成に,シーケンス番号が用いられることは,当業者の技術常識であったこと(前記ウ(エ))に鑑みると,引用刊行物1に接した当業者は,第5原則第2文の「所与のあるシーケンス番号は,所与のあるeNB鍵のために使用されるのは,(同一の再送のためを除いて)一度のみでなければならない。」にいう「eNB鍵のために使用される」とは,暗号鍵である「eNB鍵の生成のために」使用されることを意味し,「第2文」は,「所与のあるeNB鍵」の生成のために一度使用された「所与のあるシーケンス番号」は,当該「所与のあるeNB鍵」の生成のために再度使用してはならないことを記載したものと理解するものと認められる。そうすると,「シーケンス番号」が,「eNB鍵の生成のために使用される」とは,本件審決が認定した引用発明の「K_eNBを得るために, シーケンス番号が使用され」ることと技術的に同じ意味であるといえるから,本件審決が認定した引用発明のうち,「前記K_eNBを得るために, シーケンス番号が使用され」との部分が誤りであるとはいえないというべきである。オ原告は,これに対し,①引用刊行物1(3GPP TS 36.300 version 8.1.0Release 8)の後のバージョンの甲8(3GPP TS 36.300 version 8.8.0 Release 8)に「A sequence number (COUNT) is used as input to the ciphering and integrity protection.」との記載があることからすると,第5原則第2文中の「A given sequence number」にいう「sequence number」とは「COUNT」を意味すること,②引用刊行物1の後のバージョンの甲9の1(3GPP TS 36.323 version 1.0.0 Release 8)には,シーケンス番号の一種である「COUNT」が,暗号化及び完全性保護のパラメータとして, RRCenc, UPenc及びKRRCinｔのようなeNB鍵の下位の鍵と共に用 K Kいられることが示されていることからすると,第5原則は,第1文において,シーケンス番号が暗号化及び完全性保護の入力として用いられること,第2文において,ある所与のシーケンス番号が,(暗号化及び完全性保護に用いられる際に,)ある所与のeNB鍵を基にして得られたUP鍵(KeNB-UP-enc)及びRRC鍵(KeNB-RRC-enc,KeNB-RRC-inｔ)のために用いられるのは一度でなければならないこと,第3文において,所与のeNB鍵(正確には,その下位のUP鍵及びRRC鍵)が暗号化及び完全性保護の手続に用いられることを述べたものであることからすると,第5原則第2文は,暗号化及び完全性保護の手続について述べたものであって,シーケンス番号がeNB鍵の生成のために用いられることを述べたものではない旨主張する。しかしながら,原告の主張は,以下のとおり理由がない。 (ア) 上記①の点について a 甲8には,「- シーケンス番号(COUNT)は,暗号化,及び, 完全性保護のための入力として用いられる。所与のあるシーケンス番号は,所与のあるeNB鍵のために使用されるのは,同一方向における同一の無線ベアラにおいては(同一の再送のためを除いて)一度のみでなければならない。同一のシーケンス番号が,暗号化と,完全性保護の両方に用いることができる。」(原文73頁下から9行～下から7行の訳文)との記載がある。甲8の上記記載と引用刊行物1の「14.1 概説及び原則」の第 5原則第2文とを対比すると,上記記載のうち,「シーケンス番号( COUNT)は,暗号化,及び,完全性保護のための入力として用いられる。」との記載箇所は,第5原則第1文の「シーケンス番号」を「シーケンス番号(COUNT)」としたほかは,第1文と同内容であること,「所与のあるシーケンス番号は,所与のあるeNB鍵のために使用されるのは,同一方向における同一の無線ベアラにおいては (同一の再送のためを除いて)一度のみでなければならない。」との記載箇所は,第5原則第2文に「同一方向における同一の無線ベアラにおいては」の文言を付け加えたほかは,第2文と同内容であること, 「同一のシーケンス番号が,暗号化と,完全性保護の両方に用いることができる。」との記載箇所は第3文と同内容であることが認められる。 b 上記認定事実によれば,引用刊行物1(3GPP TS 36.300 version 8. 1.0 Release 8(2007-06))の公開時(2007年(平成19年)6 月)には,第5原則第1文の「暗号化,及び,完全性保護のための入力」として「シーケンス番号」を用いること自体は決定されていたが, 具体的にどのようなシーケンス番号を用いるのかについては決定されておらず,その後検討が進められた結果,引用刊行物1と同じ規格( 「3GPP TS 36.300」)の後のバージョンである甲8(3GPP TS 36.300 version 8.8.0 Release 8(2009-03))の公開時(2009年(平成 21年)3月)までに,第5原則第1文の「シーケンス番号」として「COUNT」を規格として採用することが決定されたものと推認される。このように引用刊行物1の公開時には,第5原則第1文の「シーケンス番号」として具体的にどのようなシーケンス番号を用いるのかについては決定されていなかったことに照らすと,同様に,第5原則第2文の「所与のあるシーケンス番号」にいう「シーケンス番号」についても,具体的にどのようなシーケンス番号を用いるのかについては決定されていなかったと解するのが自然であるから,これが「C OUNT」として特定されていた旨の原告の主張は採用することができない。 (イ) 上記②の点について a 甲9の1には,次のような記載がある。 (a) 「5.3 暗号化及び復号化暗号化機能はPDCPで実行される。暗号化されるデータユニットは,ヘッダ圧縮が構成される場合はその後のPDCP PDUのデータ部分(Uプレーンデータに関連するPDCPエンティティにのみ適用)(項目6.3.2を参照)及び,可能な場合,MACフィールド(項目6.3.3を参照)である(FFS(要検討))。ユーザプレーン無線ベアラに関連するPDCPエンティティに使用される暗号化アルゴリズム及び鍵は,PDCP PDUが受信/送信された時に上位層[3]によって構成され,[6]で明記した暗号化方法が適用される。ヘッダ圧縮を使用するように構成される場合,PDCP SDUに関連する圧縮パケットのみが,関連するC OUNT値に基づいて暗号化/復号化される。制御プレーン無線ベアラに関連するPDCPエンティティに使用される暗号化アルゴリズム及び鍵は,受信される各PDCP PDU に対して上位層[3]によって構成され,[6]で明記した暗号化方法が適用される。暗号化保護のためにPDCPに要求されるパラメータは[6]で定義され,暗号化アルゴリズムに入力される。上位層[3]によって提供されるPDCPに要求されるパラメータを以下に記載する。 - COUNT- BEARER([5]で無線ベアラ識別子として定義される。 [3]のように,値RBアイデンティティ 1を使用する。)- DIRECTION(送信方向)- CK(暗号鍵)- IBS(入力ビットストリーム)」「5.4 完全性保護完全性保護機能は,制御プレーン無線ベアラに関連するPDCPエンティティに対してPDCPで実行される。 PDCPエンティティに使用される完全性保護アルゴリズム及び鍵は,受信される各PDCP PDUに対して上位層[3]によって構成され,[6]で明記した完全性保護方法が適用される。完全性保護のためにPDCPに要求されるパラメータは[6]で定義され,完全性保護アルゴリズムに入力される。上位層[3]によって提供されるPDCPに要求されるパラメータを以下に記載する。 - COUNT- BEARER([6]で無線ベアラ識別子として定義される。 [3]のように,値RBアイデンティティ 1を使用する。)- DIRECTION(送信方向)- IK(完全性保護鍵)- IBS(入力ビットストリーム:暗号化又は復号化されたデータユニット(FFS(要検討)))- FRESH完全性保護を検証する場合,上記したように,UEは,入力パラメータに基づいてX-MACを計算する。計算したX-MACがMA Cと一致する場合,完全性保護の検査は成功したことになる。X- MACが受信したMACと一致しない場合,対応するパケットは廃棄される。」 (以上,原文12頁19行～13頁15行・訳文1頁～2頁) (b) 「6.3.4 COUNT 暗号化と完全性保護のため,COUNT値は保持される。COU NT値は,HFN及び当該PDCPシーケンス番号から構成される。」 (原文16頁3行～5行・訳文3頁)b 上記aの記載事項によれば,甲9の1には,暗号化機能は,「PD CP」(「NAS」よりも下位の階層(サブレイヤ))で実行され, 暗号化保護のためのパラメータが暗号化アルゴリズムに入力されること,完全性保護機能も,「PDCP」で実行され,完全性保護のためのパラメータが完全性保護アルゴリズムに入力されること,暗号化及び完全性保護のためのパラメータとして,HFN及び当該PDCPシーケンス番号から構成される「COUNT」が用いられることが開示されていることが認められる。しかるところ,甲9の1は,引用刊行物1が公開(2007年(平成19年)6月)された後に公開(同年9月)されたこと(弁論の全趣旨)からすると,上記開示事項は,引用刊行物1の公開当時,「1 4.1 概説及び原則」の第5原則第1文の「暗号化,及び,完全性保護のための入力」として「シーケンス番号」として,「COUNT」が有力候補の一つとして検討されていたことをうかがわせるものであるとしても,その公開時に,「COUNT」を採用することが決定していたことの根拠となるものではないし,同様に,第5原則第2文の「所与のあるシーケンス番号」にいう「シーケンス番号」として「C OUNT」を採用することが決定していたことの根拠となるものでもない。ましてや,甲9の1が,第5原則第2文が「ある所与のシーケンス番号が,(暗号化及び完全性保護に用いられる際に,)ある所与のeN B鍵を基にして得られたUP鍵(KeNB-UP-enc)及びRRC鍵(KeN ,KeNB-RRC-inｔ)のために用いられるのは一度でなければ B-RRC-enc ならないこと」を意味する旨の原告主張の裏付けとなるものではない。 (ウ) 小括以上によれば,第5原則第2文は,暗号化及び完全性保護の手続について述べたものであり,シーケンス番号がeNB鍵の生成のために用いられることを述べたものではないとの原告の主張は,理由がない。 (4) 一致点の認定の誤りの有無について原告は,引用発明における「シーケンス番号」には,本願発明の「NAS _U_SEQ」は含まれないから,本件審決が,「シーケンス番号と,および前記UEと共有される,記憶されたアクセスセキュリティ管理エンティティキーK_ASMEから,前記セキュリティキーK_eNBを導出するステップ」を本願発明と引用発明の一致点と認定したのは誤りである旨主張する。ア引用刊行物1の「14.1 概説及び原則」の第5原則第2文の「所与のあるシーケンス番号は,所与のあるeNB鍵のために使用されるのは, (同一の再送のためを除いて)一度のみでなければならない。」にいう「 eNB鍵のために使用される」とは,「eNB鍵の生成のために」使用されることを述べたものであることは,前記(3)エ認定のとおりである。そして,引用刊行物1の公開時において,第5原則第1文の「シーケンス番号」及び第5原則第2文の「所与のあるシーケンス番号」にいう「シーケンス番号」として具体的にどのようなシーケンス番号を採用するかについて決定されていなかったことは,前記(3)オ(ア)及び(イ)のとおりである。イ前記(2)アの引用刊行物1の記載事項(別紙1の図4.3.2を含む。) には,UE及びMME間の「NAS」のサブレイヤ(レベル),UE及び eNB間の「RRC」,「PDCP」,「RLC」等のサブレイヤ(レベル)における「制御プレーン・プロトコル・スタック」についての記述がある。しかるところ,上記各サブレイヤ(レベル)で送信又は受信されるパケットに,それぞれのサブレイヤ(レベル)に対応する「シーケンス番号」が含まれることは,本願の優先権主張日当時,技術常識であったものである。上記技術常識に加えて,引用刊行物1には,「eNB鍵」は,「EPC /UEにおいて,NAS(EPC/UE)レベルAKA手続によって生成された,鍵素材から得られる。」(第2原則)が記載されていること(前記(2)ウ)を踏まえると,引用刊行物1に接した当業者は,第5原則第2文の「eNB鍵の生成のために」使用される「シーケンス番号」は,UE及びMME間の「NAS」のサブレイヤ(レベル)で送信又は受信されるパケットに含まれるシーケンス番号を意味するものと理解するものと認められる。そして,UEからみて上流側であるeNBやMMEへのパケット送信をアップリンク送信,逆に,MMEやeNBからみて下流側であるUEへのパケット送信をダウンリンク送信と称することは,本願の優先権主張日当時,技術常識であったこと(例えば,引用刊行物2(甲2の1)の段落【 0043】,【0044】,【0074】)に照らすと,本願発明の「N AS_U_SEQ」は,UE及びMME間の「NAS」のサブレイヤ(レベル)で,UEからMMEへの「NASサービス要求」に係るパケットに含まれるアップリンクシーケンス番号であることは自明であるから,第5 原則第2文の「eNB鍵の生成のために」使用される「シーケンス番号」に含まれるものと整理することも許されるというべきである。そうすると,引用発明における「シーケンス番号」は,本願発明の「N AS_U_SEQ」を含む上位概念として整理し,「シーケンス番号と, および前記UEと共有される,記憶されたアクセスセキュリティ管理エンティティキーK_ASMEから,前記セキュリティキーK_eNBを導出するステップ」を本願発明と引用発明の一致点と認定したことに誤りはない。ウ原告は,これに対し,①引用刊行物1には,「K_eNBを得るために, シーケンス番号が使用され」る構成についての開示はないから,引用発明は,「シーケンス番号と,および前記UEと共有される,記憶されたアクセスセキュリティ管理エンティティキーK_ASMEから,前記セキュリティキーK_eNBを導出するステップ」の構成を有するものとはいえない,②引用刊行物1記載の第5原則第2文中の「A given sequence number」にいう「sequence number」とは,「COUNT」を意味するから,「NA S_U_SEQ」とは異なるシーケンス番号である,③第5原則は,「E -UTRAN」すなわち「UE」と「eNB」間のネットワークのセキュリティについて述べたものであるのに対し,「NAS」は,「UE」と「MM E」との間のプロトコルであり,本願発明と引用発明とは,「シーケンス番号」が用いられるプロトコルが異なるから,「シーケンス番号」の意味が異なることは,当業者にとって自明であり,引用発明における「シーケンス番号」には,本願発明の「NAS_U_SEQ」は含まれない旨主張する。しかしながら,引用刊行物1の第5原則第2文にシーケンス番号が「e NB鍵の生成のために」使用されることについての開示があること,引用刊行物1の「シーケンス番号」が「COUNT」に特定又は限定されるものでないことは,前記(3)オで説示したとおりであるから,上記①及び②の点は理由がない。また,前記アのとおり,第5原則第2文の「eNB鍵の生成のために」使用される「シーケンス番号」は,UE及びMME間の「NAS」のサブレイヤ(レベル)で送信又は受信されるパケットに含まれるシーケンス番号を意味するものといえるから,上記③の点も理由がない。したがって,原告の上記主張は,採用することができない。 (5) まとめ以上のとおり,本件審決がした引用発明及び一致点の認定に原告主張の誤りは認められないから,原告主張の取消事由1は理由がない。 2 取消事由2(相違点の看過)について(1) 原告は,本願発明は,「NASサービス要求を前記UEから受信するステップ(32,52)であって,前記要求が,NASアップリンクシーケンス番号NAS_U_SEQを示すステップ」の構成を有するが,本件審決は, 引用発明が上記構成を有することを認定していないから,上記構成を本願発明と引用発明の相違点として認定すべきであったのに,この相違点の認定を看過した誤りがある旨主張する。そこで検討するに,前記1(2)イの引用刊行物1の記載事項(「7.1 サービスと機能」,「7.3 NASメッセージの転送)」)と図19.2. 2.3(別紙1参照)を総合すると,引用刊行物1には,①「NASダイレクトメッセージ」が「UE」から「NAS」へ又は「NAS」から「UE」へ転送(初期直接転送)されること,②「NASサービスリクエスト」(N ASサービス要求)が「UE」から「NAS」によって「eNB」を経て「 MME」へ送信され,「MME」がこれを受信することが記載されていることが認められる。そうすると,引用刊行物1には,「MME」が「NASサービス要求を前記UEから受信するステップ」が開示されているものといえる。そして,「NASサービス要求」のパケットにシーケンス番号(アップリンクシーケンス番号)含まれることは自明であるから,引用刊行物1には, 「NASサービス要求を前記UEから受信するステップであって,前記要求が,NASアップリンクシーケンス番号NAS_U_SEQを示すステップ」の構成が実質的に記載されているに等しいものと認められる。そうすると,上記構成は,本願発明と引用刊行物1記載の方法との間の相違点ではなく,むしろ一致点と認定すべきであったものといえる。したがって,原告の上記主張は理由がない。 (2) 以上によれば,本件審決に相違点の看過の誤りがあるものと認められないから,原告主張の取消事由2は理由がない。なお,本件審決が,本願発明の「NASサービス要求を前記UEから受信するステップであって,前記要求が,NASアップリンクシーケンス番号N AS_U_SEQを示すステップ」の構成と引用刊行物1記載の方法との関係について明示的に認定判断を示さなかったことは,不適切であったものといわざるを得ないが,この点は,審決の結論に影響を及ぼすものではない。 3 取消事由3(相違点の容易想到性の判断の誤り)について(1) 原告は,①引用刊行物1(甲1)には,「K_eNBを得るために,シーケンス番号が使用され」る構成についての開示がなく,また,仮に引用刊行物1に上記構成の開示があるとしても,K_eNBを得るためにNASサービス要求で示される「NAS_U_SEQ」をシーケンス番号として用いることの開示はない,②同様に,引用刊行物2(甲2の1)及び本件審決が認定した周知技術(「「UE」から,「MME」に対して「RRC/NAS信号」を送信する点」)のいずれにおいても,NASサービス要求で示される「NAS_U_SEQ」をK_eNBの生成のために用いることについての開示や示唆はないとして,引用発明に引用刊行物2記載の発明及び本件審決が認定した構成を組み合わせても,当業者が相違点に係る本願発明の構成を容易に想到することができたものとはいえないから,本件審決における相違点の容易想到性の判断に誤りがある旨主張する。ア引用刊行物1の「14.1 概説及び原則」の第5原則第2文の「所与のあるシーケンス番号は,所与のあるeNB鍵のために使用されるのは, (同一の再送のためを除いて)一度のみでなければならない。」にいう「 eNB鍵のために使用される」とは,「eNB鍵の生成のために」使用されることを述べたものであることは,前記1(3)エ認定のとおりである。そして,当業者においては,第5原則第2文の「eNB鍵の生成のために」使用される「シーケンス番号」は,UE及びMME間の「NAS」のサブレイヤ(レベル)で送信又は受信されるパケットに含まれるシーケンス番号を意味するものと理解するものと認められることは,前記1(4)イ認定のとおりである。加えて,引用刊行物1に,「NASサービスリクエスト」(NASサービス要求)が「UE」から「NAS」によって「eNB」を経て「MME」へ送信され,「MME」がこれを受信することが記載されており,また, 「NASサービス要求」にパケットにシーケンス番号(アップリンクシーケンス番号)(「NAS_U_SEQ」)が含まれることが自明であることは,前記2(1)認定のとおりである。以上によれば,引用刊行物1に接した当業者は,第5原則第2文の「e NB鍵の生成のために」使用される「シーケンス番号」は,UE及びMM E間の「NAS」のサブレイヤ(レベル)で送信又は受信されるパケットに含まれるシーケンス番号であることを理解し,そのようなシーケンス番号の中から,引用刊行物1記載の「NASサービスリクエスト」(NAS サービス要求)に含まれるアップリンクシーケンス番号(「NAS_U_ SEQ」)を選択し,これを引用発明に採用することを容易に想到することができたものと認められる。イ原告は,この点に関し,本件審決は,本願発明と引用発明との相違点は格別のものではないと判断したが,その判断に際し,本願発明がNASアップリンクシーケンス番号NAS_U_SEQを採用して,セキュリティキーK_eNBを生成するため,NASダウンリンクシーケンス番号NA S_D_SEQ等の別個のシーケンス番号が不要であり,特別な複雑さを回避することができるという顕著な効果を奏することを考慮していないから,上記判断は誤りである旨主張する。しかしながら,前記ア認定のとおり,引用刊行物1に接した当業者であれば,引用発明において,「eNB鍵の生成のために」使用される「シーケンス番号」としてNASアップリンクシーケンス番号NAS_U_SE Qの構成を採用することを容易に想到することができたものと認められ, この場合に,「ユーザ装置(11)UEと前記UEにサービスするeNｏ deB(12)との間のRRC/UPトラフィックを保護するため」の「セキュリティキーK_eNB」の「確立」のために,NASダウンリンクシーケンス番号NAS_D_SEQ等の別個のシーケンス番号」を必要としないことは,上記構成を採用したことによる予想どおりの効果にすぎないものであり,格別なものではない。したがって,原告の上記主張は,理由がない。 (2) 以上によれば,引用刊行物1に基づいて相違点に係る本願発明の構成を容易に想到することができたものと認められるから,本願発明と引用発明との相違点は格別のものではないとした本件審決における相違点の容易想到性の判断は,結論において誤りはない。したがって,原告主張の取消事由3は理由がない。 4 結論以上の次第であるから,原告主張の取消事由はいずれも理由がなく,本件審決にこれを取り消すべき違法は認められない。したがって,原告の請求は棄却されるべきものである。
追加
(別紙)本願明細書図面【図1】【図2】【図3】【図6a】【図6b】(別紙1)Figｕｒe4(図4)Figｕｒe4.3.2(図4.3.2)Figｕｒe14.1-1(図14.1-1)Figｕｒe19.2.2.3(図19.2.2.3)(訳文)(別紙2)Figｕｒe6.2.2.(図6.2.2)(別紙3)【図1】【図5】【図6】(別紙4)第4図(別紙5)FIG3A(図3A)

裁判長裁判官	富田善範
裁判官	大鷹一郎
裁判官	鈴木わかな

すごい知財EXPO'22

ページ上部へ