【事件の表示】
　特願２００５−　　４１９１「クライアント／サーバシステム、クライアント／サーバシステムにおける暗号化通信方法およびプログラム」拒絶査定不服審判事件〔平成１８年　７月２７日出願公開、特開２００６−１９７００４〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１．手続の経緯
　本願は、平成１７年１月１１日の出願であって、平成１９年６月４日付けで拒絶理由通知がなされ、同年８月８日付けで意見書が提出されると共に手続補正がなされたが、同年９月３日付けで拒絶査定された。これに対し、同年１０月１１日に審判請求がなされ、同年１１月６日付けで手続補正がなされて前置審査に付され、平成２０年３月１８日に審査官より前置報告がなされ、平成２１年８月２５日付けで当審より審尋がなされ、同年１０月２２日付けで回答書が提出されたものである。
　
第２．平成１９年１１月６日付け手続補正の補正却下の決定
［結論］
　平成１９年１１月６日付け手続補正を却下する。
　
［理由］
１．補正の内容
　平成１９年１１月６日付け手続補正（以下、「本件補正」という。）は、平成１９年８月８日付け手続補正により補正された特許請求の範囲に請求項６として記載された以下の発明
「【請求項６】
　サーバ装置が複数のクライアント装置の各々からの要求に応じて所定の暗号鍵でデータを暗号化してクライアント装置に送信するクライアント／サーバシステムにおける暗号化通信方法において、
　前記クライアント装置が、前記サーバ装置に記憶されている暗号鍵に対応する復号鍵であって前記サーバ装置に記憶されている暗号鍵の数よりも少ない数の複数の復号鍵を記憶し、前記サーバ装置にデータを要求する際に、自身が記憶している複数の復号鍵を示す復号鍵情報を前記サーバ装置に対して申告し、
　前記サーバ装置が、前記クライアント装置から復号鍵情報を受信すると、記憶している暗号鍵から、復号鍵情報が示す復号鍵に対応した暗号鍵を選択し、
　前記サーバ装置が、選択した暗号鍵に対応する復号鍵を指定する情報を前記クライアント装置に送信し、
　前記サーバ装置が、選択した暗号鍵で、前記クライアント装置から要求されたデータを暗号化して前記クライアント装置に送信し、
　前記クライアント装置が、前記サーバ装置から指定された復号鍵で前記サーバ装置から受信した暗号化データを復号する
　ことを特徴とするクライアント／サーバシステムにおける暗号化通信方法。」
　
を、新たに請求項５として以下の発明
「【請求項５】
　サーバ装置が複数のクライアント装置の各々からの要求に応じて所定の暗号鍵でデータを暗号化してクライアント装置に送信するクライアント／サーバシステムにおける暗号化通信方法において、
　前記クライアント装置が、前記サーバ装置に記憶されている暗号鍵に対応する復号鍵であって前記サーバ装置に記憶されている暗号鍵の数よりも少ない数の複数の復号鍵を記憶し、前記サーバ装置にデータを要求する際に、自身が記憶している複数の復号鍵を示す復号鍵情報を前記サーバ装置に対して申告し、
　前記サーバ装置が、前記クライアント装置から復号鍵情報を受信すると、同一の暗号鍵がないように予め記憶している暗号鍵のうちから、復号鍵情報が示す復号鍵に対応した暗号鍵を選択し、
　前記サーバ装置が、選択した暗号鍵に対応する復号鍵を指定する情報を前記クライアント装置に送信し、
　前記サーバ装置が、選択した暗号鍵で、前記クライアント装置から要求されたデータを暗号化して前記クライアント装置に送信し、
　前記クライアント装置が、前記サーバ装置から指定された復号鍵で前記サーバ装置から受信した暗号化データを復号する
　ことを特徴とするクライアント／サーバシステムにおける暗号化通信方法。」
　
に補正することを含むものである。
　
２．補正の適否について
（Ｉ）補正の目的について
　当該補正は、サーバ装置に関して
　補正前の「前記サーバ装置が、前記クライアント装置から復号鍵情報を受信すると、記憶している暗号鍵から、復号鍵情報が示す復号鍵に対応した暗号鍵を選択し」を
　「前記サーバ装置が、前記クライアント装置から復号鍵情報を受信すると、同一の暗号鍵がないように予め記憶している暗号鍵のうちから、復号鍵情報が示す復号鍵に対応した暗号鍵を選択し」
と補正したものであり、サーバ装置の暗号鍵の記憶に対して、「同一の暗号鍵がないように」という限定を付したものであるから、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第４項第２号で規定する、特許請求の範囲の減縮（限定的減縮）を目的としたものと解される。
　そこで、当該補正によって補正された請求項５に係る発明（以下、「本件補正後発明」という。）が、特許出願の際独立して特許を受けることができるものであるか否かを以下で検討する。
　
（ＩＩ）独立特許要件について
（ｉ）特許法第３６条第６項第２号について
　本件補正によって補正された請求項５に記載の「サーバ装置が、前記クライアント装置から復号鍵を受信すると、同一の暗号鍵がないように予め記憶している暗号鍵」における「同一の暗号鍵」とは、暗号鍵がどのような点で「同一」であることを意味するのか、例えば、用語の一般的な意義である”同一の内容の暗号鍵”を意味するのか、あるいは”同一のＩＤに対応付けられた暗号鍵”あるいはその他の事項を意味するのかが本願の明細書及び図面の記載並びに出願時の技術常識を参酌しても明確に把握することができないから、同請求項５の記載は明確でない。
　したがって、本件補正によって補正された請求項５の記載は、特許法第３６条第６項第２号に規定する要件を満たしていないから、特許出願の際独立して特許を受けることができるものでない。
　
（ｉｉ）特許法第２９条第２項について
　
（１）引用発明
　原審の拒絶理由に引用された文献である、国際公開第２００４／０９８１４５号（以下、「引用文献１」という。）には、以下の事項が記載されている。
　
（ア）「(57)Abstract:Disclosed is a method of establishing a secured peer-to-peer communication between two communications devices, each communications device having stored a respective set of previously established security associations with other communications devices. The method comprises determining whether the two communications devices have a common security association in their respective sets of established security associations; if the devices have determined a common security association, protecting the communications link between the two communications device based on the determined common security association; otherwise establishing a new security association between the two comrnunications devices, and protecting the communications link based on the new security association; and extending the sets of previously established security associations of the two communications devices to the corresponding other communications device by exchanging corresponding key data.」
（仮訳：当審注、本仮訳は、引用文献１に対応する国内公表公報である特表２００６−５２６３１４号公報によった。以下の仮訳も同じ。）
（５７）【要約】２つの通信装置間にセキュリティ保護されたピアツーピア型の通信を確立する方法。各通信装置は、他の通信装置との間で事前に確立されたセキュリティアソシエーションのセットをそれぞれ格納している。本方法は、確立されたセキュリティアソシエーションのセットにおいて共通のセキュリティアソシエーションを２つの通信装置が有するか否かを判定することを含む。装置が共通のセキュリティアソシエーションを有している判定した場合、共通のセキュリティアソシエーションに基づく２つの通信装置間の通信リンクを保護する。有していると判定しなかった場合、２つの通信装置間に新しいセキュリティアソシエーションを確立し、新しいセキュリティアソシエーションに基づく通信リンクを保護する。また、本方法は、対応する鍵データを交換することにより、２つの通信装置において事前に確立されたセキュリティアソシエーションのセットを対応する他方の通信装置に拡張することを含む。
　
（イ）「Fig. 2 shows a flow diagram illustrating the establishment of a secured peer- to-peer communications link between two communications devices using symmetric-key based security associations. The flow diagram 200 comprises two columns 222 and 223, each column representing one of the two communications devices A and B-that communicate with each other. Boxes representing steps performed by a device A are placed in column 222 while boxes representing steps performed by device B are placed in column 223. 
Boxes representing steps performed by both devices cooperatively cover both columns. 
　
Each of the communications devices A and B comprises an internal database of trusted private keys. Since these keys may be distributed to a number of trusted devices, as described below, these private keys will also be referred to as (trusted) group keys. The databases 214 and 215 each comprise a list of trusted group key records, where each record includes a group key index and a trusted group key corresponding to the index. In the example of fig. 2, the trusted group keys stored in database 214 of device A are denoted KA1,..., KAN, and the corresponding indices are denoted A1,.... AN. 
Correspondingly, the trusted group keys stored in database 215 of device B are denoted KB1, --, KBM, and the corresponding indices are denoted B1,..., BM. For example, during manufacturing, each device may be pre- configured with at least one key index and a corresponding group key. 
Alternatively, the device is shipped with no pre-configured keys. It is further understood that the devices may have stored further keys for other purposes. 
However, the present method applies to a dedicated set of trusted group keys KA1,--, KAN and KB1,..., KBM, respectively, which are intended to be propagated to other trusted devices as a part of the present method. For example, the keys KA1,..., KAN and KB1, -., KBM may be stored in dedicated databases, respectively, or otherwise separated from other keys. 
Alternatively, they may be stored in a database together with other keys, where the trusted group keys intended for the present method are marked as trusted keys intended for the present method. As mentioned above, each of the trusted group keys may be related to a group identifier identifying a specific context, e. g. group o devices, services, or the like, and where the propagation of the corresponding key is limited to that context. 
　
In one embodiment, the key indices may be chosen at random from a predetermined index space. Preferably, the index space is selected large enough to reduce the probability of two different secret keys having the same index. For example, the indices may be selected from a 48-bit index space. It is noted, however, that uniqueness is not a strict requirement for the indices, as they are only used to identify common group keys. If two different keys are erroneously indicated as a common key due to a conflict of their indices, the subsequent establishment of security functions, such as encryption, based on these keys will fail. Hence, in this case an alternative key may be identified or, a manual pairing may be performed. 」
　
（仮訳）
　図２は、対称鍵に基づくセキュリティアソシエーションを使用して、２つの通信装置間にセキュリティ保護されたピアツーピア型の通信リンクを確立する方法を示すフローチャートである。フローチャート２００は、２つの列２２２及び２２３を含む。各列は、相互に通信する２つの通信装置Ａ及びＢのうち一方を表す。装置Ａにより実行されるステップを表すボックスは列２２２に配置されている。装置Ｂにより実行されるステップを表すボックスは列２２３に配置されている。双方の装置により実行されるステップを表すボックスは、双方の列に共有されている。
　
　通信装置Ａ及びＢの各々は、信頼のおける秘密鍵の内部データベースを具備する。これらの鍵は、以下に説明するように、多数の信頼のおける装置に配信されてもよいため、これら秘密鍵は（信頼のおける）グループ鍵とも呼ばれる。データベース２１４及び２１５の各々は、信頼されたグループ鍵のレコードのリストを含む。各レコードは、グループ鍵インデックス及びそのインデックスに対応する信頼されたグループ鍵を含む。図２の例において、装置Ａのデータベース２１４に格納される信頼のおけるグループ鍵は、ＫＡ１，．．．，ＫＡＮで示され、対応するインデックスは、Ａ１，．．．，ＡＮで示される。同様に、装置Ｂのデータベース２１５に格納される信頼のおけるグループ鍵は、ＫＢ１，．．．，ＫＢＭで示される。対応するインデックスは、Ｂ１，．．．，ＢＭで示される。例えば、製造中に、少なくとも１つの鍵インデックス及び対応するグループ鍵が各装置に事前に設定されてもよい。あるいは、装置は、鍵が事前に設定されずに出荷されてもよい。装置が他の目的のためにさらなる鍵が格納されうることも、理解されるべきである。しかしながら、本方法は、信頼のおけるグループ鍵ＫＡ１，．．．，ＫＡＮ及びＫＢ１，．．．，ＫＢＭの専用セットの各々に対して適用されるものとする。これら鍵のセットは、本方法の一部として、他の信頼のおける装置へ伝播されることになる。例えば、鍵ＫＡ１，．．．，ＫＡＮ及びＫＢ１，．．．，ＫＢＭは、それぞれ、専用のデータベースに格納されてもよく、又は、他の鍵から分離されてもよい。あるいは、それらの鍵が他の鍵と共にデータベースに格納されてもよく、本方法のための信頼のおけるグループ鍵が本方法のための信頼鍵としてマークが付与される。上述したように、各信頼のおけるグループ鍵は、装置のグループ又はサービスなどの特定のコンテキストを識別するグループ識別情報に関連付けられてもよい。対応する鍵の伝播は、このコンテキストに限定される。
　
　一実施形態において、鍵インデックスは、所定のインデックス空間から無作為に選択されてもよい。２つの異なる秘密鍵が同一のインデックスを有する可能性を減少させるのに十分な大きさのインデックス空間が選択されることが好ましい。例えば、インデックスは、４８ビットのインデックス空間から選択されてもよい。しかし、インデックスは共通のグループ鍵を識別するためだけに使用されるため、インデックスが固有であることは、厳密な必要条件ではない。２つの異なる鍵がインデックスの競合のために誤って共通の鍵として取り扱われる場合、これらの鍵に基づく暗号化など、次のセキュリティ機能の確立が失敗してしまうだろう。この場合、別の鍵が識別のために使用されてもよいし、あるいはマニュアルで組の形成が実行されてもよい。
　
（ウ）「In the following, the communications devices are assumed to be capable of communicating with each other via a wired or wireless communications medium, e. g. a cable, a radio channel or any other suitable technology. For example, the devices may communicate using a Bluetooth air interface. 
　
When a user would like to connect the two devices A and B for the first time, i. e. the two devices have not previously been in contact with each other, the following steps are performed: In the initial step 201, device A sends the list of key indices A1,..., AN stored in the database 214 of device A to device B. 
　
In step 202, device B compares the received list of indices with the indices B1,..., BM stored in database 215 of device B. If device B identifies a common index, denoted IC, i. e. if there is an IC E {A1,..., AN} n {B1,... BM}, （当審注：「E」は原文では集合に所属することを表す記号であり、「ｎ」は原文では集合の交わり(intersection)を表す記号である。）the process continues at step 203, otherwise the process continues at step 205. If device B identifies more than one common key index, an arbitrary one of the common indices is selected. 
　
In step 203, i. e. if a common index IC was identified in step 202, device B sends the common index IC to device A. 
　
In subsequent step 204, the two devices perform an authenticated key exchange resulting in a shared secret. The authentication is based on the common trusted group key KIC that corresponds to the identified common index IC. The authenticated key exchange may be performed according to any suitable known authenticated key exchange process. In one embodiment, the authenticated key exchange is performed according to the Bluetooth specification, where the common group key KIC is used as PIN or initial key. See for exampleThe Specification of the Bluetooth System, Core, Baseband Specification, version 1.1, December 2000, by the Bluetooth Special Interest Group. Other examples of authenticated key exchanges include an authenticated Diffie-Hellman key exchange. After completion of the authenticated key exchange, the process continues at step 207. 」
　
（仮訳）
 以下において、通信装置は、例えばケーブル、無線チャネル又は他のいずれかの適切な技術など、有線通信媒体又は無線通信媒体を介して、相互に通信可能であるものと仮定される。例えば、通信装置は、Ｂｌｕｅｔｏｏｔｈエアインタフェースを使用して通信してもよい。ユーザが初めて２つの装置Ａ及びＢを接続することを望む場合、すなわち、２つの装置が事前に相互に通信していなかった場合、以下のステップが実行される。
　
　最初のステップ２０１において、装置Ａは、装置Ａのデータベース２１４に格納される鍵インデックスＡ１，．．．，ＡＮのリストを装置Ｂに送信する。
　
　ステップ２０２において、装置Ｂは、受信したインデックスのリストを装置Ｂのデータベース２１５に格納されるインデックスＢ１，．．．，ＢＭと比較する。装置ＢがＩＣで示される共通のインデックスを識別できた場合、すなわち、ＩＣ∈｛Ａ１，．．．，ＡＮ｝∩｛Ｂ１，．．．，ＢＭ｝が存在する場合、ステップ２０３に移行する。一方、共通のインデックスが存在しない場合、ステップ２０５に移行する。装置Ｂが２つ以上の共通の鍵インデックスを識別できた場合、共通のインデックスのうちいずれか１つが選択される。
　
　ステップ２０３において、すなわち、共通のインデックスＩＣがステップ２０２において識別された場合、装置Ｂは、共通のインデックスＩＣを装置Ａに送信する。
　
　次のステップ２０４において、２つの装置は、認証された鍵交換を実行して、共有される秘密情報を取得する。この認証処理は、識別された共通のインデックスＩＣに対応する共通の信頼のおけるグループ鍵ＫＩＣに基づいて実行される。認証された鍵交換は、既知であるいずれかの適切な認証された鍵交換処理に従って実行されてもよい。一実施形態において、認証された鍵交換は、共通のグループ鍵ＫＩＣがＰＩＮ又は初期鍵として使用されるＢｌｕｅｔｏｏｔｈ仕様に従って実行される。例えば、Bluetooth Special Interest Groupによる「The Specification of the Bluetooth System, Core, Baseband Specification」第１．１版、２０００年１２月を参照のこと。認証された鍵交換の他の例は、認証されたDiffie Hellman鍵交換である。認証された鍵交換が完了した後、ステップ２０７に移行する。
　
（ａ）上記（ア）の「(57)Abstract:Disclosed is a method of establishing a secured peer-to-peer communication between two communications devices」との記載、及び、上記（イ）の「Fig. 2 shows a flow diagram illustrating the establishment of a secured peer- to-peer communications link between two communications devices using symmetric-key based security associations. The flow diagram 200 comprises two columns 222 and 223, each column representing one of the two communications devices A and B-that communicate with each other. 」との記載から、引用文献１には
　装置Ａと装置Ｂとを含むシステムにおける通信方法
が記載されたものと解される。
　
（ｂ）上記（イ）の「Each of the communications devices A and B comprises an internal database of trusted private keys. ・・・（中略）・・・The databases 214 and 215 each comprise a list of trusted group key records, where each record includes a group key index and a trusted group key corresponding to the index. In the example of fig. 2, the trusted group keys stored in database 214 of device A are denoted KA1,..., KAN, and the corresponding indices are denoted A1,.... AN. 」
との記載から、引用文献１に記載の装置Ａは、当該装置Ａのデータベースに信頼のおけるグループ鍵KA1,..., KANを格納していること、及び、グループ鍵KA1,..., KANに対応するインデックスがA1,.... ANであることが読み取れる。
　そして、上記（ウ）の「When a user would like to connect the two devices A and B for the first time, i. e. the two devices have not previously been in contact with each other, the following steps are performed: In the initial step 201, device A sends the list of key indices A1,..., AN stored in the database 214 of device A to device B」との記載から、装置Ａと装置Ｂとの通信における最初のステップ２０１として、装置Ａが装置Ｂに対してデータベースに格納している鍵インデックスのリストA1,..., Aを送信することも読み取れることと併せると、引用文献１に記載の通信方法は、
　装置Ａが、当該装置Ａのデータベースに信頼のおけるグループ鍵KA1,..., KANを格納しており、装置Ｂに対して、当該データベースに格納している鍵インデックスのリストA1,..., ANを送信するステップ
を有することが認められる。
　
（ｃ）上記（ウ）の「In step 202, device B compares the received list of indices with the indices B1,..., BM stored in database 215 of device B. If device B identifies a common index, denoted IC, i. e. if there is an IC E {A1,..., AN} n {B1,... BM},（当審注：「E」は原文では、集合に所属することを表す記号であり、「ｎ」は集合の交わり(intersection)を表す記号である。）the process continues at step 203, otherwise the process continues at step 205. If device B identifies more than one common key index, an arbitrary one of the common indices is selected. 」との記載から、引用文献１に記載の通信方法は、装置Ａが鍵インデックスのリストを送信するステップに続くステップとして
　装置Ｂが、鍵インデックスのリストを受信し、装置Ｂのデータベースに格納されている暗号鍵のインデックスB1,..., BMのリストと比較して、共通のインデックスICを選択するステップ
を有することが認められる。
　
（ｄ）上記（ウ）の「In step 203, i. e. if a common index IC was identified in step 202, device B sends the common index IC to device A」との記載から、引用文献１に記載の通信方法は、装置Ｂが共通のインデックスICを選択するステップに続いて、
　装置Ｂが、共通のインデックスICを装置Ａに送信するステップ
を有することが認められる。
　
（ｅ）上記（ウ）の「In subsequent step 204, the two devices perform an authenticated key exchange resulting in a shared secret. The authentication is based on the common trusted group key KIC that corresponds to the identified common index IC. 」との記載から、引用文献１に記載の通信方法は、共通のインデックスICを装置Ａに送信するステップに続いて、
　装置Ａと装置Ｂとが、共通のインデックスICに対応する KICに基づいて鍵交換を行うステップ
を有することが認められる。
　
　したがって、引用文献１には、次の発明（以下、「引用発明」という。）が記載されたものと認められる。
　
　装置Ａと装置Ｂとを含むシステムにおける通信方法であって、
　装置Ａが、当該装置Ａのデータベースに信頼のおけるグループ鍵KA1,..., KANを格納しており、装置Ｂに対して、当該データベースに格納している鍵インデックスのリストA1,..., ANを送信するステップと、
　前記装置Ｂが、鍵インデックスのリストを受信し、装置Ｂのデータベースに格納されている暗号鍵のインデックスB1,..., BMのリストと比較して、共通のインデックスICを選択するステップと、
　前記装置Ｂが、共通のインデックスICを前記装置Ａに送信するステップと、
　前記装置Ａと前記装置Ｂとが、共通のインデックスICに対応する KICに基づいて鍵交換を行うステップと
を有する通信方法。
　
（２）周知技術
　原審の拒絶理由に引用された文献である、国際公開第０２／０７６０１１号（以下、「引用文献２」という。）には、
　第１５頁第２６行乃至第１６頁第２行に、端末装置の復号手段１４は、鍵リストデータ２１のうちのいずれかの暗号鍵データ５１に基づいて、暗号化されたデータを復号するものであることが記載され、
　第１６頁第５行乃至同第７行に、サーバ装置は、複数の端末装置のそれぞれとの間で暗号通信が可能な装置であることが記載され、
　第１６頁第８行乃至第１７頁第１行に、サーバ装置は、各端末装置に割り当てられた暗号鍵データを各端末装置情報に関連付けた暗号鍵データセットを有していることが記載され、
　第１７頁第２行乃至同第５行に、サーバ装置の暗号化手段３３は、通信相手となる端末装置に対応する暗号鍵データセットにおける複数の暗号鍵データ７１のうちのいずれかに基づいて、データを暗号化するものであることが記載され、
　第１８頁第１８行乃至第１９頁第３行に、サーバ装置において、通信相手となる端末装置に対応する暗号鍵データセットにおける複数の暗号鍵データ７１のいずれかを選択し、暗号鍵データ７１の鍵識別子７２を端末装置に送信することが記載され、
　第１９頁第４行乃至同第８行に、端末装置は受信した鍵識別子７２に基づいて、暗号鍵データ５１を読み出すことが記載され、
　第１９頁第２５行乃至第２０頁第７行には、端末装置とサーバ装置とでは同一の共通鍵である暗号鍵データ５１、７１を使用してデータの暗号化および復号が行われて暗号通信が実施されること、及び、サーバ装置から端末装置へ送信されるデータは、サーバ装置の暗号化手段３３で暗号化され、端末装置の復号手段１４で復号されることが記載されている。
　そして、当該記載において、サーバ装置は各端末装置に対応する暗号鍵データセットを有していることから、端末装置に割り当てられた鍵すなわち端末装置の有する鍵は、サーバ装置の有する鍵に対応するものであって、端末装置の有する鍵の数とサーバ装置の有する鍵の数とを比較すると、端末装置の有する鍵の方が少ないことは自明である。
　また、サーバ装置から端末装置へデータを送信するに際しては、暗号鍵データ５１は端末装置の復号手段１４によりデータの復号に使用される”復号鍵”であり、暗号鍵データ７１はサーバ装置の暗号化手段３３によりデータの暗号化に使用される”暗号鍵”であることも明らかであるから、同文献の記載からみて
　複数の端末装置とサーバ装置とを含むシステムにおいて、
　端末装置が、前記サーバ装置が有する暗号鍵に対応する復号鍵であって前記サーバ装置に記憶されている暗号鍵の数よりも少ない数の複数の復号鍵を有していると共に、
　サーバ装置が、端末装置に対応する複数の暗号鍵のいずれかを選択し、当該暗号鍵の鍵識別子を端末装置に送信し、
　サーバ装置が選択された暗号鍵を使用してデータを暗号化して送信し、端末装置はサーバ装置によって選択された暗号鍵に対応する復号鍵を使用して復号する方法
は本願の出願時に周知の技術（以下、「周知技術１」という。）といえる。
　
　また、原審の拒絶理由に引用された文献である、特開平２−４０３７号公報には、
　第１頁左下欄第４行乃至同頁右下欄第１行に、ファイルサーバにおいて、ファイルアクセス情報内のユーザ識別子を識別する手段、ユーザ識別子に対応して所定の暗号鍵を記憶する暗号化鍵記憶手段、該暗号化鍵記憶手段から読み出された暗号化鍵に対応して暗号化を行う暗号化手段とを備え、ＬＡＮからのファイルアクセス要求に対して、ファイルサーバが該ファイルアクセス要求を出したユーザに対応する暗号化により、ファイルをＬＡＮ上に出力することが記載され、
　第３頁右下欄第１１行乃至同第１４行には、ＬＡＮ上を流れる暗号化された信号が、要求元の端末に受信され、その端末を操作しているユーザが、ユーザ識別子で決まる自分専用の復号化鍵を用いることにより復号が可能なことが記載され、
　第５頁の第４図の記載から、端末４０１は複数存在することが読み取れる。
　そして、当該記載において、ＬＡＮからのファイルアクセス要求とは、端末からファイルサーバへのファイルの要求であってファイルアクセス情報を端末からファイルサーバに送信することを意味することは自明であり、また、暗号化記憶手段からの暗号化鍵の読み出しとは、ユーザ識別子に対応する暗号化鍵を選択することを意味することも明らかであり、ユーザ識別子は、ファイルサーバがファイルを暗号化するための暗号化鍵を決定するための情報と解されるから、当該記載からみて、
　複数の端末とファイルサーバを含むシステムにおいて、
　端末が、ファイルサーバへのファイルの要求として、ファイルサーバがファイルを暗号化するための暗号化鍵を決定するための情報であるユーザ識別子を含むファイルアクセス情報を送信し、
　ファイルサーバが、受信したファイルアクセス情報内のユーザ識別子を識別し、当該ユーザ識別子に対応する暗号化鍵を選択し、
　ファイルサーバが、選択した暗号化鍵でファイルを暗号化して端末に送信し、
　端末が、受信したファイルを復号鍵で復号する方法
も、本願出願前に周知の技術事項（以下、「周知技術２」という。）といえる。
　
（３）対比
　本件補正後発明と、引用発明とを対比する。
　引用発明の「装置Ａ」と本件補正後発明の「クライアント装置」とは、”第１の装置”である点で一致し、
　引用発明の「装置Ｂ」と本件補正後発明の「サーバ装置」とは、”第２の装置”である点で一致し、
　引用発明の「システム」と本件補正後発明の「クライアント／サーバシステム」とは、”第１の装置と第２の装置から構成されるシステム”である点で一致し、
　引用発明の「通信方法」は、装置Ａと装置Ｂとの間で「KICに基づいて鍵交換を行う」ものであるから、”暗号化通信方法”といえ、本件補正後発明と、「暗号化通信方法」である点で一致する。
　
　引用発明の「信頼のおけるグループ鍵KA1,..., KAN」と、本件補正後発明の「サーバ装置に記憶されている暗号鍵に対応する復号鍵であって前記サーバ装置に記憶されている暗号鍵の数よりも少ない数の複数の復号鍵」とは、”複数の第１鍵”である点で一致し、引用発明の「装置Ａ」において、信頼のおけるグループ鍵をデータベースに格納することは、装置Ａがグループ鍵を記憶していることを意味するものであるから、引用発明の「装置Ａ」と、本件補正後発明の「クライアント装置」とは、”複数の第１鍵を記憶”している点で一致する。
　引用発明の「データベースに格納している鍵インデックスのリストA1,..., AN」と、本件補正後発明の「自身が記憶している複数の復号鍵を示す復号鍵情報」とは、”自身が記憶している複数の第１鍵を示す鍵情報”である点で一致し、引用発明の「装置Ａ」と、本件補正後発明の「クライアント装置」とは、”自身が記憶している複数の第１鍵を示す鍵情報を、第２の装置に対して送信”している点で一致する。
　
　引用発明の「装置Ｂが、鍵インデックスのリストを受信し、装置Ｂのデータベースに格納されている暗号鍵のインデックスB1,..., BMのリストと比較して、共通のインデックスICを選択する」ことは、装置Ｂが、予め記憶している暗号鍵のうちから、装置Ａから受信した鍵インデックスのリストに対応した暗号鍵を選択することに他ならない。
　そして、本件補正後発明の「同一の暗号鍵がないように」とは、明細書及び図面の記載を参酌して用語の意義を検討すると、暗号鍵管理番号が暗号鍵に一意に対応付けられているものを含む概念であると解されるが、引用発明の「鍵インデックス」も、当該鍵インデックスに対応して暗号鍵が特定されるものであるから、当該鍵インデックスが暗号鍵に一意に対応付けられていることは明らかであって、引用発明の装置Ｂも、暗号鍵を同一の暗号鍵がないように予め記憶したものといえる。
　よって、引用発明の「装置Ｂが、鍵インデックスのリストを受信し、装置Ｂのデータベースに格納されている暗号鍵のインデックスB1,..., BMのリストと比較して、共通のインデックスICを選択する」と、本件補正後発明の「前記サーバ装置が、前記クライアント装置から復号鍵情報を受信すると、同一の暗号鍵がないように予め記憶している暗号鍵のうちから、復号鍵情報が示す復号鍵に対応した暗号鍵を選択し」とは
”第２の装置が、前記第１の装置から鍵情報を受信すると、同一の暗号鍵がないように予め記憶している暗号鍵のうちから、鍵情報が示す第１鍵に対応した暗号鍵を選択”する点で一致する。
　
　引用発明の「共通のインデックスIC」は、装置Ａのデータベースに格納されたグループ鍵のうち、装置Ｂが選択した暗号鍵に対応する鍵を指定する情報に他ならないから、引用発明の「前記装置Ｂが、共通のインデックスICを前記装置Ａに送信するステップ」と、本件補正後発明の「前記サーバ装置が、選択した暗号鍵に対応する復号鍵を指定する情報を前記クライアント装置に送信し」とは、
”第２の装置が、選択した暗号鍵に対応する第１鍵を指定する情報を前記第１の装置に送信”する点で一致する。
　
　引用発明の「前記装置Ａと前記装置Ｂとが、共通のインデックスICに対応する KICに基づいて鍵交換を行うステップ」は、「鍵交換」であることから、装置Ｂが、選択した暗号鍵を用いて装置Ａとの暗号通信を行うこと、及び、装置Ａが、装置Ｂから指定された第１鍵を用いて装置Ｂとの暗号通信を行うことを含むことは明らかである。
　よって、引用発明の「前記装置Ａと前記装置Ｂとが、共通のインデックスICに対応する KICに基づいて鍵交換を行うステップ」と、本件補正後発明の「前記サーバ装置が、選択した暗号鍵で、前記クライアント装置から要求されたデータを暗号化して前記クライアント装置に送信し、
　前記クライアント装置が、前記サーバ装置から指定された復号鍵で前記サーバ装置から受信した暗号化データを復号する」とは、
”第２の装置が、選択した暗号鍵を用いて第１の装置との暗号通信を行い、
　第１の装置が、第２の装置から指定された第１鍵を用いて第２の装置との暗号通信を行う”
点で一致する。
　
　したがって、本件補正後発明と引用発明とは、以下の一致点で一致し、各相違点で相違する。
　
（一致点）
　第１の装置と第２の装置から構成されるシステムにおける暗号化通信方法において、
　前記第１の装置が、複数の第１鍵を記憶し、自身が記憶している複数の第１鍵を示す鍵情報を前記第２の装置に対して送信し、
　前記第２の装置が、前記第１の装置から鍵情報を受信すると、同一の暗号鍵がないように予め記憶している暗号鍵のうちから、鍵情報が示す第１鍵に対応した暗号鍵を選択し、
　前記第２の装置が、選択した暗号鍵に対応する第１鍵を指定する情報を前記第１の装置に送信し、
　前記第２の装置が、選択した暗号鍵を用いて第１の装置と通信し、
　前記第１の装置が、前記第２の装置から指定された第１鍵を用いて第２の装置と通信する
　ことを特徴とする第１の装置と第２の装置から構成されるシステムにおける暗号化通信方法。
　
（相違点１）
　システムに関し、
　本件補正後発明のシステムは、複数のクライアント装置の各々からの要求に応じて所定の暗号鍵でデータを暗号化してクライアント装置に送信し、クライアント装置において受信したデータを復号するクライアント／サーバシステムであるのに対して、引用発明のシステムが当該クライアント／サーバシステムを構成する旨明示はなされていない点。
　
（相違点２）
　第１鍵に関し、
　本件補正後発明の復号鍵は、サーバ装置から受信した暗号化データを復号化する際に用いられる鍵であって、サーバ装置に記憶されている暗号鍵に対応し、またサーバ装置に記憶されている暗号鍵の数よりも少ない数であるのに対し、引用発明のグループ鍵がデータを復号するために用いられる復号鍵であること、装置Ｂに記憶されている暗号鍵に対応するものであること、及び、装置Ｂに記憶されている暗号鍵の数よりも少ない数であることはいずれも明らかではない点。
　
（相違点３）
　鍵情報の送信に関し、
　本件補正後発明は、クライアント装置がサーバ装置にデータを要求する際に復号鍵情報をサーバ装置に対して申告するのに対し、引用発明の鍵インデックスの送信が、装置Ａが装置Ｂにデータを要求する際に行われることが明らかではない点。
　
（相違点４）
　暗号鍵に関し、
　本件補正後発明の暗号鍵は、サーバ装置がクライアント装置から要求されたデータを暗号化するために使用されるものであるのに対して、引用発明の暗号鍵は、装置Ｂが装置Ａから要求されたデータを暗号化するために使用することが明らかではない点。
　
（４）判断
　上記相違点について判断する。
　「（２）周知技術」の項で上記したとおり、
　複数の端末装置とサーバ装置とを含むシステムにおいて、
　端末装置が、前記サーバ装置が有する暗号鍵に対応する復号鍵であって前記サーバ装置に記憶されている暗号鍵の数よりも少ない数の複数の復号鍵を有していると共に、
　サーバ装置が、端末装置に対応する複数の暗号鍵のいずれかを選択し、当該暗号鍵の鍵識別子を端末装置に送信し、
　サーバ装置が選択された暗号鍵を使用してデータを暗号化して送信し、端末装置はサーバ装置によって選択された暗号鍵に対応する復号鍵を使用して復号する方法
は、本願出願前の周知技術（周知技術１）であり、また、
　複数の端末とファイルサーバを含むシステムにおいて、
　端末が、ファイルサーバへのファイルの要求として、ファイルサーバがファイルを暗号化するための暗号化鍵を決定するための情報であるユーザ識別子を含むファイルアクセス情報を送信し、
　ファイルサーバが、受信したファイルアクセス情報内のユーザ識別子を識別し、当該ユーザ識別子に対応する暗号化鍵を選択し、
　ファイルサーバが、選択した暗号化鍵でファイルを暗号化して端末に送信し、
　端末が、受信したファイルを復号鍵で復号する方法も本願出願前の周知技術（周知技術２）であった。
　
　そして、周知技術１及び周知技術２は、いずれも第１の装置と第２の装置とを含むシステムにおいて、第２の装置が、第１の装置に対応する鍵を選択し、当該選択した鍵に基づいて第１の装置と第２の装置とが暗号通信を行う技術である点で引用発明と共通するものである
　
　そうしてみると
（相違点１）及び（相違点４）について
　引用発明に対して、上記周知技術（周知技術２）を考慮することにより、鍵を選択する装置である装置Ｂを、装置Ａからの要求に応じて選択した暗号鍵で要求されたファイルすなわちデータを暗号化して装置Ａに送信するサーバ装置として実現すると共に、装置Ｂと通信する装置Ａを、装置Ｂに対してデータを要求し、装置Ｂから受信したデータを復号する複数の端末すなわち複数のクライアント装置として実現することにより、引用発明のシステムを、データの暗号通信を行うクライアント／サーバシステムとすることは、当業者が容易に想到し得た事項といえる。
　よって、上記相違点１及び４はいずれも格別のものではない。
　
（相違点２）について
　引用発明に対して、上記周知技術（周知技術１）を考慮することにより、装置Ａの有する鍵であって暗号通信に用いるグループ鍵を、装置Ｂが有する暗号鍵に対応し、装置Ｂから送信されたデータを復号するための復号鍵であって、装置Ｂに記憶されている暗号鍵の数よりも少ない数の鍵とすることは、当業者が容易に想到し得た事項といえる。
　よって、上記相違点２は格別のものではない。
　
（相違点３）について
　引用発明に対して、クライアント装置がサーバ装置に対し、データの要求と共に暗号鍵を決定するための情報を申告している上記周知技術（周知技術２の、ファイルサーバがファイルを暗号化するための暗号化鍵を決定するための情報であるユーザ識別子をファイルアクセス情報に含む点）を考慮することにより、装置Ａが装置Ｂに対し、暗号鍵を決定するための情報である鍵インデックスの送信をデータの要求と共に行うよう構成することも当業者が容易に想到し得た事項といえる。
　よって、上記相違点３は格別のものではない。
　
　そして、本件補正後発明の奏する効果についても、引用発明及び周知技術に基づいて当業者が容易に予測し得た程度のものである。
　
　したがって、本件補正後発明は、引用発明及び周知技術に基づいて当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許出願の際に独立して特許を受けることができないものである。
　
（ｉｉｉ）補正却下のむすび
　本件補正後発明は、上記「（ｉ）特許法第３６条第６項第２号について」の項に記載したとおり、特許法第３６条第６項第２項に規定する要件を満たしておらず、また、上記「（ｉｉ）特許法第２９条第２項について」の項に記載したとおり、特許法第２９条第２項の規定により特許出願の際に独立して特許を受けることができないものである。
　したがって、本件補正は、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に違反するので、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。 
　
第３　本願発明について
１．本願発明
　平成１９年１１月６日付け手続補正は上記のとおり補正却下されたので、本願の請求項６に係る発明（以下、「本願発明」という。）は、平成１９年８月８日付け手続補正により補正された特許請求の範囲、明細書及び図面の記載からみて、特許請求の範囲に請求項６として記載された以下のとおりのものと認める。
　
「【請求項６】
　サーバ装置が複数のクライアント装置の各々からの要求に応じて所定の暗号鍵でデータを暗号化してクライアント装置に送信するクライアント／サーバシステムにおける暗号化通信方法において、
　前記クライアント装置が、前記サーバ装置に記憶されている暗号鍵に対応する復号鍵であって前記サーバ装置に記憶されている暗号鍵の数よりも少ない数の複数の復号鍵を記憶し、前記サーバ装置にデータを要求する際に、自身が記憶している複数の復号鍵を示す復号鍵情報を前記サーバ装置に対して申告し、
　前記サーバ装置が、前記クライアント装置から復号鍵情報を受信すると、記憶している暗号鍵から、復号鍵情報が示す復号鍵に対応した暗号鍵を選択し、
　前記サーバ装置が、選択した暗号鍵に対応する復号鍵を指定する情報を前記クライアント装置に送信し、
　前記サーバ装置が、選択した暗号鍵で、前記クライアント装置から要求されたデータを暗号化して前記クライアント装置に送信し、
　前記クライアント装置が、前記サーバ装置から指定された復号鍵で前記サーバ装置から受信した暗号化データを復号する
　ことを特徴とするクライアント／サーバシステムにおける暗号化通信方法。」
　
２．引用発明及び周知技術
　引用発明及び周知技術は、上記「第２．平成１９年１１月６日付け手続補正の補正却下の決定」の項中の「２．補正の適否」の項中の「（ＩＩ）独立特許要件について」の項中の「（ｉｉ）特許法第２９条第２項について」の項中の「（１）引用発明」及び「（２）周知技術」の項でそれぞれ認定したとおりである。
　
３．対比・判断
　本願発明は、上記「第２．平成１９年１１月６日付け手続補正の補正却下の決定」の項中で検討した本件補正後発明における「前記サーバ装置が、前記クライアント装置から復号鍵情報を受信すると、同一の暗号鍵がないように予め記憶している暗号鍵のうちから、復号鍵情報が示す復号鍵に対応した暗号鍵を選択し」から、「同一の暗号鍵がないように予め」という限定を削除すると共に、「暗号鍵のうちから」を「暗号鍵から」としたものであるから、本件補正後発明の上位概念に当たる発明である。
　
　そうしてみると、本願発明の構成要件をすべて含み、さらに他の事項を限定した本件補正後発明が、上記「第２．平成１９年１１月６日付け手続補正の補正却下の決定」の項中の「２．補正の適否」の項中の「（ＩＩ）独立特許要件について」の項中の「（ｉｉ）特許法第２９条第２項について」の項中の「（４）判断」の項に記載したとおり、引用発明及び周知技術に基づいて当業者が容易に発明をすることができたものであるから、本願発明も同様の理由により、当業者が容易に発明をすることができたものである。
　したがって、本願発明は、引用発明及び周知技術に基づいて当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　
第４．平成２１年１０月２２日付け回答書に記載の補正案について
　平成２１年１０月２２日付け回答書には、本件補正後発明の「同一の暗号鍵がないように」を、「同一の暗号番号がないように暗号鍵管理番号に一意に対応させて」と補正することで発明を明確にすることを希望する旨記載されている。
　しかし、引用発明の「鍵インデックス」において、同一の鍵インデックスが別の暗号鍵に対応することがないようにすること、及び、暗号鍵を鍵インデックスに一意に対応付けることは、当該鍵インデックスから特定の暗号鍵が選択されるようにするために当然になされるべき事項であるから、引用発明の「鍵インデックス」も、同一の番号がないように暗号鍵が一意に対応付けられたものある点で、本件における「暗号鍵管理番号」と一致するものであって、本件補正後発明を当該回答書で希望するとおりに明確にした発明も、引用発明及び周知技術に基づいて当業者が容易に発明をすることができたものといえる。
　
第５．むすび
　以上のとおりであって、本願の請求項６に係る発明は引用発明及び周知技術に基づいて当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　
　よって、結論のとおり審決する。