平成２５年４月１１日判決言渡同日原本領収裁判所書記官平成２４年（行ケ）第１０２１４号審決取消請求事件口頭弁論終結日平成２５年３月２１日判決原告リフレクションネットワークス，インコーポレイテッド同訴訟代理人弁理士吉田 匠中島 拓倉内基弘波多野 寛 海被告特許庁長官同指定代理人稲葉和生和田志郎樋口信宏守屋友宏 主文 １ 原告の請求を棄却する。 ２ 訴訟費用は原告の負担とする。 ３ この判決に対する上告及び上告受理の申立てのための付加期間を３０日と定める。 事実及び理由 第１ 請求特許庁が不服２０１０－２１５２７号事件について平成２４年２月１日にした審決を取り消す。 第２ 事案の概要本件は，原告が，後記１のとおりの手続において，特許請求の範囲の記載を後記２とする本件出願に対する拒絶査定不服審判の請求について，特許庁が同請求は成り立たないとした別紙審決書（写し）の本件審決（その理由の要旨は後記３のとおり）には，後記４の取消事由があると主張して，その取消しを求める事案である。 定不服審判の請求について，特許庁が同請求は成り立たないとした別紙審決書（写し）の本件審決（その理由の要旨は後記３のとおり）には，後記４の取消事由があると主張して，その取消しを求める事案である。 １ 特許庁における手続の経緯(1) バーリントンコミュニケーションズインコーポレイテッドは，平成１５年８月１１日，発明の名称を「電子メッセージ受信者へのアクセスを制御するためのシステム及び方法」とする特許を国際出願（パリ条約に基づく優先権主張：平成１４年（２００２年）８月９日，アメリカ合衆国）し，国内移行（特願２００４－５２８０００。請求項の数４。甲３）の後，平成１７年４月１２日付け手続補正書（甲４。請求項の数５２）により手続補正をしたが，平成２２年５月１７日付けで拒絶査定を受けた（甲１３）。 なお，バーリントンコミュニケーションズインコーポレイテッドは，平成１６年４月２６日付けの合併により，リフレクションネットワークソリューションズ，インコーポレイテッドとなったが，平成２１年６月５日には，その名称をリフレクションネットワークス，インコーポレイテッドに変更し，同年７月１日，特許庁長官に対し，出願人名義の変更を届け出た（甲８，９）。 (2) 原告は，平成２２年９月２４日，上記拒絶査定に対する不服の審判を請求するとともに，手続補正（甲１５。以下「本件補正」という。請求項の数３０）をした。 (3) 特許庁は，上記請求を不服２０１０－２１５２７号事件として審理し，平成２４年２月１日，「本件審判の請求は，成り立たない。」との本件審決をし，その謄本は同月１４日，原告に送達された。 ２ 特許請求の範囲の記載本件補正後の特許請求の範囲請求項１の記載は，以下のとおりである。以下，請求項１に係る発明を「本願発明」といい，その明細書（ の謄本は同月１４日，原告に送達された。 ２ 特許請求の範囲の記載本件補正後の特許請求の範囲請求項１の記載は，以下のとおりである。以下，請求項１に係る発明を「本願発明」といい，その明細書（甲３，７）を「本願明細書」という。 電子通信ネットワークに接続された受信者ユーザに対する，該電子通信ネットワークに接続された他のユーザによる通信アクセスを選択的に許可または拒絶するための方法であって，前記受信者ユーザが関連した受信者識別子を有し，Ａ 前記受信者ユーザに関連した複数の別個のプロキシ識別子を生成するステップであって，前記プロキシ識別子の各々が少なくとも３つの関連するセキュリティー状態を有し，前記状態の第１の状態が前記電気通信ネットワークに接続した相手が誰でも前記受信者ユーザに通信アクセスすることを許可することを示し，前記状態の第２の状態が前記電気通信ネットワークに接続した相手が誰でも前記受信者ユーザに通信アクセスすることを拒絶することを示し，さらに，前記状態の第３の状態が，前記プロキシ識別子に関連した予め決められた基準が満たされた場合に，前記電子通信ネットワークに接続した相手のうちの少なくとも１つの相手であって，全ての相手より少ない相手が前記受信者ユーザに通信アクセスすることを許可すること，及び前記基準が満たされていない場合に前記受信者ユーザに対する通信アクセスを拒絶することを条件付で示す該ステップと，Ｂ 前記電子通信ネットワークに接続された送信者ユーザに関連付けられた送信者識別子と，前記複数のプロキシ識別子の１つである前記受信者識別子とを含む該送信者ユーザからのインバウンドメッセージへの応答で，受信者ユーザが変更可能なセキュリティー設定に従い，かつ前記送信者識別子及び受信者識別子を用いて，該インバウ １つである前記受信者識別子とを含む該送信者ユーザからのインバウンドメッセージへの応答で，受信者ユーザが変更可能なセキュリティー設定に従い，かつ前記送信者識別子及び受信者識別子を用いて，該インバウンドメッセージに関連したセキュリティー状態を決定するために該インバウンドメッセージを処理するステップと，Ｃ 前記決定に従い，ⅰ 前記セキュリティー状態が前記第１の状態に該当する場合，前記インバウンドメッセージの前記受信者ユーザへの通信アクセスを許可し，かつ，ⅱ 前記セキュリティー状態が前記第２の状態に該当する場合，前記インバウンドメッセージの前記受信者ユーザへの通信アクセスを拒絶し，かつ，ⅲ 前記セキュリティー状態が前記第３の状態に該当し，かつ前記複数のプロキシ識別子の前記１つの前記セキュリティー状態に少なくとも部分的に関連した１つまたは複数の前記予め決められた基準を満たす場合，前記インバウンドメッセージの前記受信者ユーザへの通信アクセスを許可し，その他の場合に，前記インバウンドメッセージの前記受信者ユーザへの通信アクセスを拒絶することにより，前記インバウンドメッセージの前記受信者ユーザへの通信アクセスを制御するステップとを含む方法 ３ 本件審決の理由の要旨(1) 本件審決の理由は，要するに，本願発明は，引用例（特開２０００－３３９２３６号公報。甲１）に記載された発明に基づいて，当業者が容易に発明をすることができたものであるから，特許法２９条２項の規定により特許を受けることができない，というものである。 (2) 本件審決が認定した引用例に記載された発明（以下「引用発明」という。）並びに本願発明と引用発明との一致点及び相違点は，以下のとおりである。 なお，この認定について，当事者間に争いはない。 ア引用発明：電子 認定した引用例に記載された発明（以下「引用発明」という。）並びに本願発明と引用発明との一致点及び相違点は，以下のとおりである。 なお，この認定について，当事者間に争いはない。 ア引用発明：電子メールのいたずらメールの防止方法であって，メール転送サーバは，ある一定のフォーマットに該当するメールアドレスを全て特定の人に送るようにし，メールアドレスがueda@xxxxx.server.comあるいは，ueda.xxxxx@server.comのようなフォーマットのメールについて，該メールアドレス内の任意の「xxxxx」に該当するメールに対して登録されたメールアドレスへの転送，もしくは該メールに対して登録された特定のメールボックスへの配送を行い，このことにより，ユーザは自分が受け取ると決めた「xxxxx 」を含まないメールアドレスに対するメールを拒否／消去することが簡単にできるようになり，通常の使用では，メールのユーザは自分にメールを出す可能性がある人に対してそれぞれ異なったメールアドレスを通知し，該通知した全てのメールアドレス以外のメールアドレスに届いたメールは捨てるか無視し，さらに，サーバは，メール受付部において，送信されてきたメールのアドレスあるいはアドレスパターンの照合を行った後，メールを再配布あるいはメールボックスに入れる際に，前もって与えられたユーザからの指示に従って，メールの破棄，エラーメールを送出することによるメールの拒否，あるいは，ユーザのメールリーダソフトが処理できるような何らかのフィールドの追加などの処理をし，ユーザは，サーバに対して，指示を行う際に以下のような処理を実施する手段を持ち，・ある特定のメールアドレスと処理方法を指定し，それ以降そのメールアドレスに届いたメールはその方法で処理する 理をし，ユーザは，サーバに対して，指示を行う際に以下のような処理を実施する手段を持ち，・ある特定のメールアドレスと処理方法を指定し，それ以降そのメールアドレスに届いたメールはその方法で処理するこのために，サーバの内部に，指定されたアドレスとそのアドレスに対応する処理方法とを対にして記憶する処理内容記憶部を設け，処理内容記憶部に記憶されるテーブルの１行は，アドレス又はアドレスパターンを格納するフィールド，該アドレス又はアドレスパターンに対応する処理方法を格納するフィールド，及び該処理方法において使用される処理方法のパラメータなどを記憶するオプションを記憶するフィールドからなり，サーバは，届いたメールのアドレスをテーブルに登録されている指定されたアドレス，アドレスパターンと照合し，テーブル内にマッチするアドレス，または，アドレスパターンが存在する場合，そのマッチしたアドレスあるいはアドレスパターンに対応する処理を行い，サーバは，ユーザが処理方法の登録／参照を行うための入出力部を有しており，届いたメールが特定の性質を持ったものかどうか判定し，それによってメールの処理方法を指定するサーバの処理方法を指定する場合は，処理方法記憶部のテーブルに，見分けるべき性質の記述，その性質を持っている場合と持っていない場合の処理方法が登録され，見分けるべき性質と，該性質を持っている場合と持っていない場合の処理方法はオプションとしてテーブルに記憶され，見分けるべき性質は，メールに関する各種情報のパターンマッチ，例えば，Subject が特定の文字列を含むとか，送出した日付が一定の期間内にあるかどうか，あるいは，本文中に特定の文字列が含まれるかどうかなどが考えられ，この処理方法に該当するアドレス宛のメールが届いた場合，そのアドレスに対応した むとか，送出した日付が一定の期間内にあるかどうか，あるいは，本文中に特定の文字列が含まれるかどうかなどが考えられ，この処理方法に該当するアドレス宛のメールが届いた場合，そのアドレスに対応した見分けるべき性質を取り出し，次にそのメールが特定の性質を満たしているかどうか調べ，性質を満たしている場合は，そのための処理を，そうでなければそうでない方の処理を行う，電子メールのいたずらメールの防止方法イ一致点：電子通信ネットワークに接続された受信者ユーザに対する，該電子通信ネットワークに接続された他のユーザによる通信アクセスを選択的に許可または拒絶するための方法であって，前記受信者ユーザが関連した受信者識別子を有し，Ａ 前記受信者ユーザに関連した複数の別個のプロキシ識別子を生成するステップであって，前記プロキシ識別子の各々が少なくとも３つの関連するセキュリティー状態を有し，前記状態の第１の状態が前記電気通信ネットワークに接続した相手が誰でも前記受信者ユーザに通信アクセスすることを許可することを示し，前記状態の第２の状態が前記電気通信ネットワークに接続した相手が誰でも前記受信者ユーザに通信アクセスすることを拒絶することを示し，さらに，前記状態の第３の状態が，前記プロキシ識別子に関連した予め決められた基準が満たされた場合に，特定の処理をすること，及び前記基準が満たされていない場合に別の処理をすることを条件付で示す該ステップと，Ｂ 前記電子通信ネットワークに接続された送信者ユーザに関連付けられた送信者識別子と，前記複数のプロキシ識別子の１つである前記受信者識別子とを含む該送信者ユーザからのインバウンドメッセージへの応答で，受信者ユーザが変更可能なセキュリティー設定に従い，かつ受信者識別子を用いて，該インバウンドメッセージ 別子の１つである前記受信者識別子とを含む該送信者ユーザからのインバウンドメッセージへの応答で，受信者ユーザが変更可能なセキュリティー設定に従い，かつ受信者識別子を用いて，該インバウンドメッセージに関連したセキュリティー状態を決定するために該インバウンドメッセージを処理するステップと，Ｃ 前記決定に従い，ⅰ 前記セキュリティー状態が前記第１の状態に該当する場合，前記インバウンドメッセージの前記受信者ユーザへの通信アクセスを許可し，かつ，ⅱ 前記セキュリティー状態が前記第２の状態に該当する場合，前記インバウンドメッセージの前記受信者ユーザへの通信アクセスを拒絶し，かつ，ⅲ 前記セキュリティー状態が前記第３の状態に該当し，かつ前記複数のプロキシ識別子の前記１つの前記セキュリティー状態に少なくとも部分的に関連した１つまたは複数の前記予め決められた基準を満たす場合，特定の処理をし，その他の場合に，別の処理をすることにより，前記インバウンドメッセージの前記受信者ユーザへの通信アクセスを制御するステップとを含む方法である点ウ相違点１：本願発明の「第３の状態」は，「前記プロキシ識別子に関連した予め決められた基準が満たされた場合に，前記電子通信ネットワークに接続した相手のうちの少なくとも１つの相手であって，全ての相手より少ない相手が前記受信者ユーザに通信アクセスすることを許可すること，及び前記基準が満たされていない場合に前記受信者ユーザに対する通信アクセスを拒絶することを条件付で示す」ものであり，それに対応して，「前記セキュリティー状態が前記第３の状態に該当」するときには，「前記複数のプロキシ識別子の前記１つの前記セキュリティー状態に少なくとも部分的に関連した１つまたは複数の前記予め決められた基準を満たす場合，前記インバ ー状態が前記第３の状態に該当」するときには，「前記複数のプロキシ識別子の前記１つの前記セキュリティー状態に少なくとも部分的に関連した１つまたは複数の前記予め決められた基準を満たす場合，前記インバウンドメッセージの前記受信者ユーザへの通信アクセスを許可し，その他の場合に，前記インバウンドメッセージの前記受信者ユーザへの通信アクセスを拒絶する」処理を行うのに対し，引用発明の「第３の状態」は，基準を満たす場合及び基準を満たさない場合の処理の具体的内容が明確ではない点エ相違点２：本願発明は，インバウンドメッセージに関連したセキュリティー状態を決定するために，「送信者識別子及び受信者識別子」を用いているのに対し，引用発明は，該セキュリティー状態を決定するために「受信者識別子」を用いているものの，「送信者識別子」を用いていない点 ４ 取消事由本願発明の容易想到性に係る判断の誤り第３ 当事者の主張〔原告の主張〕 １ 相違点１及び２について(1) 本件審決は，引用例（【００９５】）に記載された，受信者アドレス「ueda．from．friends」に対する「if（From：friend１@his.domain｜From：friend２@her.domain ）」との処理は，チェック内容に合致したときはメールを配送する処理を，チェック内容に合致しないときはメールの拒絶処理を行うものと認められるところ，そのチェック内容は，メールヘッダのFrom（送信者アドレス）が，「friend１@his.domain」又は「friend２@her.domain」であるかをチェックするものであるから，引用発明において，「addueda.from.friendsif（From：friend １@his.domain ｜From ：frien domain」であるかをチェックするものであるから，引用発明において，「addueda.from.friendsif（From：friend １@his.domain ｜From ：friend ２@her.domain ）」という構文（以下「friends 構文」という。）で処理方法を登録されたサーバのテーブルは，「ueda.from.friends」というメールアドレス（本願発明の用語では「プロキシ識別子」）に関連して，チェック内容（送信者アドレスが「friend１@his.domain」又は「friend２@her.domain」であるか）という基準を定め，その基準が満たされた場合にはメールを許可し，満たされない場合にはメールを拒絶することを条件付きで示すものであり，これは，本願発明の「第３の状態」に相当することが明らかである，そして，このような登録がなされたサーバは，ueda.from.friends 宛てのメールが，「friend１@his.domain」又は「friend２@her.domain」から差し出されたものであるか否かによって，メールを許可又は拒絶するように動作するのであり，かかる動作は，本願発明の「ⅲ 前記セキュリティー状態が前記第３の状態に該当し，かつ前記複数のプロキシ識別子の前記１つの前記セキュリティー状態に少なくとも部分的に関連した１つまたは複数の前記予め決められた基準を満たす場合，前記インバウンドメッセージの前記受信者ユーザへの通信アクセスを許可し，その他 の場合に，前記インバウンドメッセージの前記受信者ユーザへの通信アクセスを拒絶する」ことにほかならず，引用発明が送信者識別子（送信者アドレス）及び受信者識別子（ueda.from.friends）を用いて，インバウンドメッセージに関連したセキュリ ーザへの通信アクセスを拒絶する」ことにほかならず，引用発明が送信者識別子（送信者アドレス）及び受信者識別子（ueda.from.friends）を用いて，インバウンドメッセージに関連したセキュリティー状態を決定するためにインバウンドメッセージを処理していることは明らかであるとして，相違点１及び２に係る本願発明の構成は，引用例から容易に想到し得るものである旨判断した。 しかし，本願発明では，本願明細書（【図３】）のとおり，送信者ユーザからのインバウンドメッセージのセキュリティー状態が，第１の状態に該当する場合でも第２の状態に該当する場合でも，それらのセキュリティー状態を決定するために受信者識別子のみならず，送信者識別子が用いられ，また，インバウンドメッセージのセキュリティー状態が第３の状態に該当するか否かも，送信者識別子及び受信者識別子の両方を用いて判断されるものである。これに対し，引用発明は，インバウンドメッセージに関連したセキュリティー状態を決定する際に，受信者識別子のみでセキュリティー状態を判断しており，送信者識別子及び受信者識別子の両方をチェックするようなことは行われていない。また，引用例には，通信アクセスを許可するセキュリティー状態（第１の状態）と通信アクセスを拒絶するセキュリティー状態（第２の状態）のほかに，予め決められた基準を満たす場合に通信アクセスを許可し，満たさない場合に通信アクセスを拒絶するようなセキュリティー状態は開示されておらず，引用例に記載されたfriends 構文も，送信者識別子及び受信者識別子の両方を用いて決定されたインバウンドメッセージに関連したセキュリティー状態ではなく，かつ，基準を満たす場合に受信者ユーザへの通信アクセスを許可し，満たさない場合は通信アクセスを拒絶するものでもない。 したがって， されたインバウンドメッセージに関連したセキュリティー状態ではなく，かつ，基準を満たす場合に受信者ユーザへの通信アクセスを許可し，満たさない場合は通信アクセスを拒絶するものでもない。 したがって，相違点１及び２に係る本願発明の構成は，引用発明から容易に想到し得るものではない。 (2) 被告の主張についてア被告は，引用発明に対して，friends 構文のような送信者アドレスに応じたif 構文を登録すると，送信者識別子及び受信者識別子の両方を用いて決定されたインバウンドメッセージに関連したセキュリティー状態がもたらされると理解できると主張する。 しかし，if 構文（又はfriends 構文）を登録した後の発明は，本件審決で認定された引用発明ではなく，本件訴訟の審理範囲から外れるものであり，被告の主張は失当である。 イ仮に，引用発明がif 構文を登録した後の発明を含むとしても，本願発明とは異なるものである。 すなわち，引用例中のif 構文（又はfriends 構文）は，受信者識別子に基づくマッチングプロセス（一致か，不一致か）において，一致した場合に実行される処理方法の１つに組み込まれる構文であり，マッチングプロセスで不一致の場合は，通常の配送処理が行われるものである（【００７６】【００７７】）。マッチングプロセスでは，一致又は不一致の２つの状態に分けられるが，この時，送信者識別子は用いられることはない。そして，一致した場合は，処理方法とオプションに従って，メールが処理されるが，その処理方法の１つが送信者識別子を含むif 構文である。このような処理は，本願発明において，送信者識別子及び受信者識別子を用いて，インバウンドメッセージに関連したセキュリティー状態が，第１の状態か第２の状態か第３の状態かを決定する処理とは 構文である。このような処理は，本願発明において，送信者識別子及び受信者識別子を用いて，インバウンドメッセージに関連したセキュリティー状態が，第１の状態か第２の状態か第３の状態かを決定する処理とは全く異なる。 また，本願発明は，インバウンドメッセージに関連したセキュリティー状態が第３の状態に決定した場合に，更に予め決められた基準を満たすか満たさないかをチェックするものである。仮にif 構文が本願発明における「予め決められた基準」に対応するとすれば，「予め決められた基準」をチェックする前の第３の状態を決定するときに，if 構文はチェックされることはない。あるいは，仮に，引用例において，マッチンングとその後の一致した場合のif 構文を含む処理とが，本願発明におけるインバウンドメッセージに関連したセキュリティー状態が第１の状態か第２の状態か第３の状態かを決定する処理に対応するとすれば，第３の状態に決定した場合に，更に予め決められた基準を満たすか満たさないかをチェックする時の「予め決められた基準」は引用例には存在しないこととなる。 さらに，引用例では，マッチングプロセスで不一致の場合は通常の配送処理が行われるため，マッチングプロセスの不一致が本願発明の第１の状態に対応すると考えられるが，この場合，第１の状態の決定に送信者識別子（if 構文）が用いられていないことは明らかである。 したがって，被告の主張は失当である。 ２ 作用効果について(1) 本件審決は，本願発明の構成によって生じる効果は引用発明から当業者が予測し得る範囲内のものであり，格別顕著であるとはいえないと判断した。 しかし，本願発明は，送信者識別子及び受信者識別子を用いてインバウンドメッセージに関連したセキュリティー状態を決定するようにしたため，所望されないメ であり，格別顕著であるとはいえないと判断した。 しかし，本願発明は，送信者識別子及び受信者識別子を用いてインバウンドメッセージに関連したセキュリティー状態を決定するようにしたため，所望されないメッセージがリフレクションシステムで保護されている識別子に伝達されることを優れた正確さで防止でき（【００２２】），外部の送信者からのトラフィックの受信中にメッセージを拒絶するときに，物理的なバンド幅及びそれに関連する費用が節約され（【００２３】），セキュリティーモデルが首尾一貫し，常にユーザ又はホストの組織の統制下に置かれる（【００２４】）との効果が得られる。また，本願発明は，保護された元の識別子の代理として作用する複数のプロキシ識別子の確立及び管理を介して，送信者及び受信者の識別子を使用して参加者の間でメッセージが交換される電子通信の形式のアクセスを制御するためのシステム及び方法であって，プロキシの各々がオリジネーターとの通信のために依存しているメッセージの共同体の一部に対応するアクセスの権利を規定する別個のセキュリティー状態を持つシステム及び方法を提供するということが可能となる（【００１７】）。これらの効果は，引用発明から得ることはできない。 (2) また，本願発明では，受信者ユーザが，受信者識別子及び送信者識別子の組合せそれぞれに対応するユニークな「受信者ユーザが変更可能なセキュリティー設定」を決定し，きめ細かなアクセス制御が行われる。このセキュリティー設定は受信者ユーザが経時的に変更することができ，これにより，本願発明は，受信者ユーザが一方的に採用することができる方法を提供することができる（【００１６】）。 (3) さらに，本願発明では，送信者識別子を用いることにより，送信者ユーザが電子通信ネットワークに接続した相手で ーザが一方的に採用することができる方法を提供することができる（【００１６】）。 (3) さらに，本願発明では，送信者識別子を用いることにより，送信者ユーザが電子通信ネットワークに接続した相手であるか否かを決定することができる。そのため，受信者ユーザがネットワークに接続した送信者ユーザに対して通信アクセスを許可する場合でも，当該送信者ユーザが実際に電子通信ネットワークに接続されているか否かがチェックされるものである。 ３ 小括よって，本願発明の容易想到性に係る本件審決の判断は誤りである。 〔被告の主張〕 １ 相違点１及び２について(1) 原告は，本願明細書の図３を挙げて，本願発明はインバウンドメッセージに関連したセキュリティー状態を決定するために送信者識別子及び受信者識別子を用いていると主張する。 しかし，原告の主張は，要するに，上記図３を根拠として，本願発明のインバウンドメッセージの処理は，第１の状態においても，あるいは，第２の状態においても，受信者識別子によって判断が分岐した後に送信者識別子によっても判断が分岐するというものであるが，かかる主張は，特許請求の範囲の記載に基づかないものである。すなわち，本願発明のインバウンドメッセージの処理の判断に関し，特許請求の範囲には，「前記送信者識別子及び受信者識別子を用いて」としか特定されていない。したがって，処理のどこかに「受信者識別子によって判断が分岐する部分」と「送信者識別子によって判断が分岐する部分」が存在しさえすれば，受信者識別子によって判断が分岐（第１又は第２の状態と判断）した後に送信者識別子にかかわらず判断結果に至る部分があっても構わないものである。 したがって，原告の主張は失当である。 (2) 原告は，引用例には，通信アクセスを許可するセキュ 判断）した後に送信者識別子にかかわらず判断結果に至る部分があっても構わないものである。 したがって，原告の主張は失当である。 (2) 原告は，引用例には，通信アクセスを許可するセキュリティー状態（第１の状態）と通信アクセスを拒絶するセキュリティー状態（第２の状態）のほかに，予め決められた基準を満たす場合に通信アクセスを許可し，満たさない場合に通信アクセスを拒絶するようなセキュリティー状態は開示されていないなどと主張する。 しかし，原告の主張は，引用例の記載内容を正解しないものである。 アすなわち，引用例（【００７８】【００７９】【００８８】～【００９５】）の記載からすると，引用例に記載されたfriends 構文は，「add アドレスコマンド名 [オプション]」形式で記載される「処理方法の登録」コマンドの具体例であって，このコマンドをサーバが受け取って，ユーザの登録された処理方法のリスト（図１（ａ）の処理内容記憶部のテーブル）に加えるものであることが理解できる。また，引用例（【００９４】）に記載されているとおり，上記コマンドで記載が省略されている「非合致時の動作内容」とは，「デフォルトとしてerror コマンドが指定されたものとして，オプション文字列に加えてテーブルに記憶する」というものであり，また，上記コマンドで記載が省略されている「合致時の動作内容」とは，「mail コマンドが指定されたものとしてテーブルに記憶する」というものである。 そうすると，上記コマンドをサーバが受け取ると，図１（ａ）の処理内容記憶部のテーブル，すなわち，引用発明における「処理内容記憶部に記憶されるテーブルの１行」として，friends 構文が記憶されることが理解できる。 イ次に，引用例（【００７４】～【００７７】）の記載からすると，引 すなわち，引用発明における「処理内容記憶部に記憶されるテーブルの１行」として，friends 構文が記憶されることが理解できる。 イ次に，引用例（【００７４】～【００７７】）の記載からすると，引用例において，if コマンドが，処理内容記憶部に記憶されるテーブルの１行として記憶されると，メールを受け取ったサーバは，宛先アドレスの＠より左側の文字列を拡張ユーザ名として記憶し，次に，拡張ユーザ名と，処理方法のリストの各アドレス部とを順に照合して，マッチするかどうか調べ，もしもどれかとマッチした場合，そこに記述された処理方法とオプションに従って，メールを処理することになると理解できる。すなわち，メールのヘッダ部の送信者アドレス（From：）部が，「From：friend１@his.domain｜From：friend２@her.domain」に合致すれば，｛mail｝が実行され，ユーザ名@server.com 宛（ueda@server.com）のメールとして，通常の配送処理が許可される一方，非合致時には，通常処理の中の宛先不明の場合のエラーメール送出と同様に，エラーメールを送出することで，メールが拒絶されるものと認められる。 ウそうすると，引用発明について，friends 構文のような送信者アドレスに応じたif 構文を登録すると，送信者識別子及び受信者識別子の両方を用いて決定されたインバウンドメッセージに関連したセキュリティー状態がもたらされると理解され，また，if 構文のチェック基準を満たす場合には受信者ユーザヘの通信アクセスを許可し，満たさない場合は通信アクセスを拒絶する方法が行われるものと理解される。 エしたがって，引用例には，予め決められた基準を満たす場合に通信アクセスを許可し，満たさない場合に通信アクセスを拒絶す し，満たさない場合は通信アクセスを拒絶する方法が行われるものと理解される。 エしたがって，引用例には，予め決められた基準を満たす場合に通信アクセスを許可し，満たさない場合に通信アクセスを拒絶するようなセキュリティー状態を達成することが可能な技術が開示されていると理解することができるのであり，原告の主張は失当である。 ２ 作用効果について(1) 原告は，本願発明は送信者識別子及び受信者識別子を用いてインバウンドメッセージに関連したセキュリティー状態を決定するようにしたため，本願明細書（【００１７】【００２２】～【００２４】）に記載されるような効果が得られるなどと主張する。 しかし，本願明細書（【００２２】【００２４】）に記載された効果は，引用例（【０００３】【０１１７】）に開示された効果と同じであるか，そこから予測可能な効果にすぎない。 また，本願明細書（【００２３】）に記載された効果は，メッセージ本文を受信する前にメッセージを拒否することによって初めて得られる効果であるが，本願発明は，インバウンドメッセージのヘッダー部分のみを先に受信して（メッセージ本文を受信する前に）インバウンドメッセージを処理する構成を具備しないから，この効果は特許請求の範囲の記載と対応しないものである。なお，ヘッダー部分のみを先に受信して処理することによるバンド幅の節約は周知の効果であり，引用例（【００２３】）においても言及されている。 さらに，本願明細書（【００１７】）の記載は，引用例（【００１７】【０１１６】）に開示された効果と同じであるか，そこから予測可能な効果にすぎない。 (2) 原告は，本願発明では，受信者ユーザが，受信者識別子及び送信者識別子の組合せそれぞれに対応するユニークな「受信者ユーザが変更可能なセキュリティー設定」を決 こから予測可能な効果にすぎない。 (2) 原告は，本願発明では，受信者ユーザが，受信者識別子及び送信者識別子の組合せそれぞれに対応するユニークな「受信者ユーザが変更可能なセキュリティー設定」を決定し，きめ細かなアクセス制御が行われるため，受信者ユーザが一方的に採用可能な方法を提供することができると主張する。 しかし，原告が主張する効果は，friends 構文を登録した後の引用発明が奏する効果にすぎない。 (3) 原告は，本願発明では，送信者識別子を用いることにより，受信者ユーザがネットワークに接続した送信者ユーザに対して通信アクセスを許可する場合でも，当該送信者ユーザが実際に電子通信ネットワークに接続されているか否かがチエックされるなどと主張する。 しかし，原告の主張は，本願の特許請求の範囲の記載に基づかないものである。 すなわち，特許請求の範囲には，「送信者識別子を用いることにより，送信者ユーザが電子通信ネットワークに接続した相手であるか否かを決定する」ようなステップは記載されていない。 仮に，原告が，インバウンドメッセージが「前記電子通信ネットワークに接続された送信者ユーザに関連付けられた送信者識別子」（例えば，電子メールアドレス）を含むことを根拠に，送信者ユーザが電子通信ネットワークに接続した相手であるか否かを決定することができると主張しているのであれば，それは，引用発明も具備する構成であり，また，引用発明が奏する効果である。 ３ 小括よって，本願発明の容易想到性に係る本件審決の判断に誤りはない。 第４ 当裁判所の判断 １ 本願発明について(1) 本願発明は，前記第２の２に記載のとおりであるところ，本願明細書（甲３，７）には，本願発明について，概略，次の記載がある。 ア本願発明は，送信者及び受 判所の判断 １ 本願発明について(1) 本願発明は，前記第２の２に記載のとおりであるところ，本願明細書（甲３，７）には，本願発明について，概略，次の記載がある。 ア本願発明は，送信者及び受信者の識別子を使用して参加者の間でメッセージが交換される，電子通信の形式に対するアクセス制御をするためのシステム及び方法に関するものである（【０００１】）。 イ電子メールの標準プロトコルは送信者のアイデンティティーを認証しないので，電子メール上のアクセス制御を困難な課題にしている。最近，電子メール上のアクセス制御の不十分さは商業的又は他の望まれないメッセージの量を劇的に増大させているところ，本願発明は，保護された元の識別子（オリジネーター）の代理として作用する複数のプロキシ識別子の確立及び管理を介して，送信者及び受信者の識別子を使用して参加者の間でメッセージが交換される電子通信の形式のアクセスを制御するためのシステム及び方法であって，プロキシの各々がオリジネーターとの通信のために依存しているメッセージの共同体の一部に対応するアクセスの権利を規定する別個のセキュリティー状態を持つシステム及び方法を提供するものであり，本願発明の全ての実施例において，少なくとも３つのセキュリティー状態が存在する（【０００２】【００１７】【００１８】）。 ウ本願発明の主要な効果は，所望されないメッセージがリフレクションシステムによって保護されている識別子に伝達されることを優れた正確さで防止できることである（【００２２】）。 本願発明のリフレクションシステムは，電子メールをフィルタリングしないので，リフレクションがインバウンドトラフィック（外部の送信者からのトラフィック）のＳＭＴＰ（非認証標準）受信中にメッセージを拒絶するときに，物理的なバンド幅及び ルをフィルタリングしないので，リフレクションがインバウンドトラフィック（外部の送信者からのトラフィック）のＳＭＴＰ（非認証標準）受信中にメッセージを拒絶するときに，物理的なバンド幅及びそれに関連する費用が節約される（【００２３】）。 また，本願発明のリフレクションは「偽陽性」（正当なメッセージをスパムとして識別）の欠点を有さない。セキュリティーモデルは首尾一貫したもので，常に，ユーザ又はホストの組織の制御下に置かれる（【０００７】【００２４】）。 本願発明のリフレクションは，格納するスパムの数が少なくてすむので，電子メールにかかる費用を節約することができる（【００２５】）。 (2) 以上によれば，本願発明は，受信者ユーザに対する元の識別子の代理として作用する複数のプロキシ識別子の確立及び管理を介して，電子メール等のアクセスを制御するためのシステム及び方法であって，プロキシ識別子の各々について，別個のセキュリティー状態を持つシステム及び方法を提供するものである。そして，本願発明の構成とすることにより，偽陽性の欠点がなく，セキュリティーモデルは首尾一貫したもので，常に，ユーザ又はホストの組織の制御下に置かれるなどの効果を奏するというものである。 ２ 引用発明について(1) 引用発明は，前記第２の３(2)ア記載のとおりであるところ，引用例（甲１）には，引用発明について，概略，次の記載がある。 ア本発明は，いたずらメールの防止方法及び防止装置に関する（【０００１】）。 イ今日では，個人の電子メールアドレスが，予期せぬ相手に漏洩し，不要な電子メールが大量に送られてくるという問題が発生している。スパムと呼ばれる宣伝やいたずらのためのメールの被害を防止するには，スパムにしばしば現れる文字列を検出するなどの方法があるが，こ 洩し，不要な電子メールが大量に送られてくるという問題が発生している。スパムと呼ばれる宣伝やいたずらのためのメールの被害を防止するには，スパムにしばしば現れる文字列を検出するなどの方法があるが，この方法では，本質的な解決にならず，本来受け取りたいメールをスパムと間違えて除いてしまったために読めなくなるという危険もあった。本発明の課題は，いたずらメールの受信を防止することのできる装置及び方法を提供することである（【０００２】～【０００４】【０００８】）。 ウ発明の実施の形態(ア) サーバは，ある一定のフォーマットに該当するメールアドレスを全て特定の人に送る。例えば，メールアドレスが，ueda@xxxxx.server.com 又はueda.xxxxx@server.com のようなフォーマットのメールについて，メールアドレス内の任意の「xxxxx」に該当するメールに対して登録されたメールアドレスへの転送若しくは当該メールに対して登録された特定のメールボックスへの配送を行う。 これにより，ユーザは自分が受け取ると決めた「xxxxx 」を含まないメールアドレスに対するメールを拒否／消去することが簡単にできる。通常の使用では，メールのユーザは自分にメールを出す可能性がある人に対してそれぞれ異なったメールアドレスを通知し，通知した全てのメールアドレス以外のメールアドレスに届いたメールは捨てるか無視すればよい。また，サーバは，メール受付部において，送信されてきたメールのアドレスあるいはアドレスパターンの照合を行った後，メールを再配布あるいはメールボックスに入れる際に，前もって与えられたユーザからの指示に従って，メールの破棄，エラーメールを送出することによるメールの拒否，あるいは，ユーザのメールリーダソフトが処理できるような何らかのフィ ールボックスに入れる際に，前もって与えられたユーザからの指示に従って，メールの破棄，エラーメールを送出することによるメールの拒否，あるいは，ユーザのメールリーダソフトが処理できるような何らかのフィールドの追加などの処理をする（【００１５】【００１７】【００２３】）。 (イ) ユーザは，サーバに対し，指示を行う際に，以下のような処理を実施する手段のどれか１つ以上あるいは全てを持つ。 ・ある特定のメールアドレスと処理方法を指定し，それ以降そのメールアドレスに届いたメールはその方法で処理する。 ・ある特定のメールアドレスのパターンとその処理方法を指定し，それ以降そのパターンにマッチするメールアドレスに届いたメールはその方法で処理する。 ・全てのメールアドレスに対して処理方法を指定し，それ以降の全てのメールはその方法で処理する（【００２４】）。 (ウ) このために，サーバの内部に，指定されたアドレスとそのアドレスに対応する処理方法とを対にして記憶する処理内容記憶部を設ける。図１（ｂ）は，処理内容記憶部に記憶されるテーブルの例である。このテーブルの１行は，アドレス又はアドレスパターンを格納するフィールド，該アドレス又はアドレスパターンに対応する処理方法を格納するフィールド及び該処理方法において使用される処理方法のパラメータなどを記憶するオプションを記憶するフィールドからなる。サーバは，届いたメールのアドレスをテーブルに登録されている指定されたアドレス，アドレスパターンと照合し，テーブル内にマッチするアドレス又はアドレスパターンが存在する場合，そのマッチしたアドレスあるいはアドレスパターンに対応する処理を行う（【００２５】）。 (エ) サーバは，ユーザが処理方法の登録／参照を行うための入出力部を有している（【００２６】）。 (オ) ，そのマッチしたアドレスあるいはアドレスパターンに対応する処理を行う（【００２５】）。 (エ) サーバは，ユーザが処理方法の登録／参照を行うための入出力部を有している（【００２６】）。 (オ) 図６及び７は，届いたメールが特定の性質を持ったものかどうか判定し，それによってメールの処理方法を指定するサーバの処理手順と処理方法の記録例を示す図である。この処理方法を指定する場合は，処理方法記憶部のテーブルに，見分けるべき性質の記述，その性質を持っている場合と持っていない場合の処理方法が登録される。見分けるべき性質と，該性質を持っている場合と持っていない場合の処理方法はオプションとしてテーブルに記憶される。見分けるべき性質は，様々なものが考えられるが，メールに関する各種情報のパターンマッチ，例えば，Subject が特定の文字列を含むとか，送出した日付が一定の期間内にあるかどうか，あるいは，本文中に特定の文字列が含まれるかどうかなどが考えられる。この処理方法に該当するアドレス宛のメールが届いた場合，サーバのメール受付部は，そのアドレスに対応した見分けるべき性質を取り出し，次にそのメールが特定の性質を満たしているかどうか調べ，性質が満たされているか否かを判断する。次に，満たしている場合は，そのための処理を，そうでなければそうでない方の処理を，処理方法記憶部のテーブルのオプション・フィールドあるいはサーバの固定情報記憶域から取り出し，該当する処理を行う（【００４７】～【００５０】）。 エサーバ側でいたずらメールを処理する場合のサーバの機能の具体例を説明する。 (ア) サーバは内部に登録された処理方法のリストを持っている。サーバは，メールを受け取った場合，「user．任意の文字列@server.domain」というメールアドレスを 明する。 (ア) サーバは内部に登録された処理方法のリストを持っている。サーバは，メールを受け取った場合，「user．任意の文字列@server.domain」というメールアドレスを全て「user@server.domain」というメールアドレスに届いたものとして扱うものとする。サーバはメールを受け取ると，宛先アドレスを「宛先」として記憶し，また「＠」より左側の文字列を「拡張ユーザ名」として記憶する。また，拡張ユーザ名の最も左にある「．」よりも左側の文字列を取り出し，この文字列を「ユーザ名」として記憶する。次に，拡張ユーザ名と，処理方法のリストの各アドレス部とを順に照合し，マッチするかどうか調べる。もしもどれともマッチしなければ，「ユーザ名@server.com」宛のメールとして，通常の配送処理を行う（【００７４】～【００７６】）。 もしもどれかとマッチした場合，そこに記述された処理方法とオプションに従って，メールを処理する。メール処理サブプログラムの機能は，次の通りである。 ・処理方法が，「mail」の場合，「ユーザ名@server.com」宛のメールとして，通常の配送処理を行う。 ・処理方法が，「dispose」の場合，単にそのメールを捨てて処理を終了する。 ・処理方法が，「error」の場合，通常処理の中の宛先不明の場合のエラーメール送出のルーチンに行き，該ルーチンの実行によりエラーメールを送出する。 ・処理方法が，「if」の場合，オプション部は以下の項目がつながった文字列であるとする。 …（）で括られた調べるべき性質，{}で括られている，上の性質を満たしたときの処理方法とオプション，{}で括られている，上の性質を満たさないときの処理方法とオプション（【００７７】【００７８】）。 (イ) ＜処理方法の登録＞サー {}で括られている，上の性質を満たしたときの処理方法とオプション，{}で括られている，上の性質を満たさないときの処理方法とオプション（【００７７】【００７８】）。 (イ) ＜処理方法の登録＞サーバは，アドレス名，コマンド，コマンドのオプションを受け取って，これらをユーザの登録された処理方法のリスト（図１（ａ）の処理内容記憶部のテーブル）に加える。具体例としては，・add アドレスコマンド名 [オプション]コマンド名は“dispose ” ，“error ” ，“mark” ，“header” ，“if” ，“decrypt ”，“mail”のどれかを使用する。 アドレス，コマンド名，オプションは空白で区切られ，それらをサーバは分離して，文字列としてユーザにより登録された処理方法のリストとしてテーブルに記憶する（【００８８】～【００９０】）。 (ウ) “if”コマンドはチェック内容とその後の動作をオプションとして与える。 オプション文字列は，メール処理サブプログラムのオプション部で受け付けられる構文とする（【００９３】。 (エ) 非合致時の動作内容は省略でき，その場合，デフォルトとしてerror コマンドが指定されたものとして，オプション文字列に加えてテーブルに記憶する。 合致時の動作内容も省略でき，その場合デフォルトとしてmail コマンドが指定されたものとしてテーブルに記憶する（【００９４】）。 (オ) 登録時の構文は，add のコマンドとオプションを合わせたものである。サーバが受け取るコマンドは，例えば，以下のようになる。 addueda.from.friendsif （From ：friend １@his.domain ｜From ：friend@her.domain）addueda. １month addueda.from.friendsif （From ：friend １@his.domain ｜From ：friend@her.domain）addueda. １month.from.990401if （datebefore 1999/5/1 ）｛mail ｝｛error｝addueda.reportif（Subject ：.*bug.*report*）｛if（From：customer１｜From：customer２｝｛markX-customer-report ：yes｝｛markX-bug-report：yes ｝｝｛mail｝サーバはこれらのコマンドを受け取り，オプション部分の全ての文字列をユーザの指定として加える（【００９５】）。 オ本発明によれば，サーバ側が簡単な方法で無限ないし大量のメールアドレスを有するメールを１つのメールボックスへ配送するようにしたので，使い捨てのメールアドレスを作成したり，特定の相手専用のメールアドレスを作成したり，受信者にしか分からない暗号化された情報を含んだメールアドレスを作成することにより，不本意な相手からのメールを簡単に見分けることが可能になる。この結果，いたずらや宣伝のためのメールを簡単に除外して受け取りたいメールだけを簡単に受け取ることができるようになる。また，このような機能をサーバとクライアントの組合せで行うようにすることにより，サーバの改造をほとんど必要とせずに，現在流通している枠組みのサーバにおいても簡単に実現することができる（【０１１６】【０１１７】）。 ３ 本願発明の容易想到性について(1) 相違点１及び２に係る本願発明の構成の容易想到性についてア前記１及び２のとおり，本願発明と引用発明とは，いずれも望まれない電子 ６】【０１１７】）。 ３ 本願発明の容易想到性について(1) 相違点１及び２に係る本願発明の構成の容易想到性についてア前記１及び２のとおり，本願発明と引用発明とは，いずれも望まれない電子メールの防止方法に関するものであり，技術分野が共通する。また，前記第２の３(2)イ記載のとおり，両者は，受信者ユーザが関連した受信者識別子を有し，受信者ユーザに関連した複数の別個のプロキシ識別子を生成するステップＡにおいて，プロキシ識別子の各々が少なくとも３つの関連するセキュリティー状態を有する点及び電子通信ネットワークに接続された送信者ユーザに関連付けられた送信者識別子と，複数のプロキシ識別子の１つである受信者識別子とを含む送信者ユーザからのインバウンドメッセージへの応答で，受信者ユーザが変更可能なセキュリティー設定に従い，かつ受信者識別子を用いて，インバウンドメッセージに関連したセキュリティー状態を決定するためにインバウンドメッセージを処理するステップＢと，その決定に従い，第１ないし第３の状態に応じた特定の処理をし，その他の場合に，別の処理をすることにより，インバウンドメッセージの受信者ユーザへの通信アクセスを制御するステップＣとを含む方法である点で共通し，さらに，所望されないメッセージを除外することができるという効果の点でも共通するものである。 イそこで，相違点１及び２について検討するに，前記２の引用例の記載からすると，引用例に記載されたfriends 構文は，add アドレスコマンド名 [オプション]形式で記載される「処理方法の登録」コマンドの具体例であって，このコマンドをサーバが受け取って，ユーザの登録された処理方法のリスト（図１（ａ）の処理内容記憶部のテーブル）に加えるものである。また，上記コマンドで記載が省略され ンドの具体例であって，このコマンドをサーバが受け取って，ユーザの登録された処理方法のリスト（図１（ａ）の処理内容記憶部のテーブル）に加えるものである。また，上記コマンドで記載が省略されている「非合致時の動作内容」とは，「デフォルトとしてerror コマンドが指定されたものとして，オプション文字列に加えてテーブルに記憶する」というものであり，上記コマンドで記載が省略されている「合致時の動作内容」とは，「mailコマンドが指定されたものとしてテーブルに記憶する」というものであるから，上記コマンドをサーバが受け取ると，図１（ａ）の処理内容記憶部のテーブルに，処理内容記憶部に記憶されるテーブルの１行として，friends 構文が記憶される。そして，if コマンドが，処理内容記憶部に記憶されるテーブルの１行として記憶されると，メールを受け取ったサーバは，宛先アドレスの＠より左側の文字列を拡張ユーザ名として記憶し，次に，拡張ユーザ名と，処理方法のリストの各アドレス部とを順に照合し，マッチするかどうか調べ，もしもどれかとマッチした場合，そこに記述された処理方法とオプションに従って，メールを処理するというものである。 すなわち，引用発明において，if 構文で処理方法を登録されたサーバは，ueda.from.friends 宛てのメールが，「friend１@his.domain」又は「friend２@her.domain」から差し出されたものであるか否かによって，メールを許可又は拒絶するように動作するものである。 ウそうすると，引用発明について，friends 構文のような送信者アドレスに応じたif 構文を登録すると，送信者識別子及び受信者識別子の両方を用いて決定されたインバウンドメッセージに関連したセキュリティー状態がもたらされ，if 構 iends 構文のような送信者アドレスに応じたif 構文を登録すると，送信者識別子及び受信者識別子の両方を用いて決定されたインバウンドメッセージに関連したセキュリティー状態がもたらされ，if 構文のチェック基準を満たす場合には受信者ユーザヘの通信アクセスを許可し，満たさない場合は通信アクセスを拒絶するという方法が行われるものということができる。かかる動作は，本願発明の「ⅲ 前記セキュリティー状態が前記第３の状態に該当し，かつ前記複数のプロキシ識別子の前記１つの前記セキュリティー状態に少なくとも部分的に関連した１つまたは複数の前記予め決められた基準を満たす場合，前記インバウンドメッセージの前記受信者ユーザへの通信アクセスを許可し，その他の場合に，前記インバウンドメッセージの前記受信者ユーザへの通信アクセスを拒絶する」に相当するものである。 エそして，上記のとおり，引用発明においても，if 構文で処理方法を登録されたサーバは，送信者識別子（送信者アドレス）及び受信者識別子（ueda.from.friends）を用いて，インバウンドメッセージに関連したセキュリティー状態を決定するために当該インバウンドメッセージを処理するものである。 以上のとおり，引用例には，「セキュリティー状態が第３の状態に該当するときには，複数のプロキシ識別子の１つのセキュリティー状態に少なくとも部分的に関連した１つまたは複数の予め決められた基準を満たす場合，インバウンドメッセージの受信者ユーザへの通信アクセスを許可し，その他の場合に，インバウンドメッセージの受信者ユーザへの通信アクセスを拒絶する処理を行うこと」及び「インバウンドメッセージに関連したセキュリティー状態を決定するために，送信者識別子及び受信者識別子を用いていること」が，具体的に記載されている 者ユーザへの通信アクセスを拒絶する処理を行うこと」及び「インバウンドメッセージに関連したセキュリティー状態を決定するために，送信者識別子及び受信者識別子を用いていること」が，具体的に記載されている。そして，本願発明では，ステップＢにおいて，受信者識別子及び送信者識別子を用いて，第１ないし第３のセキュリティー状態の判断を行うものであるのに対し，引用発明においてif 構文で処理方法を登録されたサーバは，受信者識別子を用いて第１のセキュリティー状態又は第２のセキュリティー状態に振り分けた後に，送信者識別子を用いて更に第３のセキュリティー状態に振り分けることを順番に行うものであるが（【００９３】等），その振り分けの結果に違いはなく，いずれの処理手順とするかは，当業者において適宜選択し得るものである。 オしたがって，当業者であれば，引用発明及び引用例に記載された事項に基づき，相違点１及び２に係る本願発明の構成を容易に想到することができるものである。 (2) 作用効果について偽陽性がなく，セキュリティーモデルは首尾一貫したもので，常にユーザ又はホストの組織の制御下に置かれるなどの本願発明の作用効果は，いずれも，当業者であれば，引用例の記載から容易に予測ができるものであるから，本願発明には，格別の作用効果があるということはできない。 (3) 原告の主張についてア原告は，本願発明においては，第１のセキュリティー状態に該当する場合でも，第２のセキュリティー状態に該当する場合でも，受信者識別子と送信者識別子の両方が用いられると主張する。 しかし，本願発明に係る特許請求の範囲の記載では，そのステップＡにおいて，３つの関連するセキュリティー状態について，「前記プロキシ識別子の各々が少なくとも３つの関連するセキュリティー状態を有し」 しかし，本願発明に係る特許請求の範囲の記載では，そのステップＡにおいて，３つの関連するセキュリティー状態について，「前記プロキシ識別子の各々が少なくとも３つの関連するセキュリティー状態を有し」と記載され，プロキシ識別子の各々が少なくとも３つのセキュリティー状態を有するものであるとは記載されているものの，セキュリティー状態が送信者識別子に関連付けられている旨の記載はない。 また，本願発明に係る特許請求の範囲の記載では，そのステップＢにおいて，「送信者識別子及び受信者識別子を用いて，該インバウンドメッセージに関連したセキュリティー状態を決定するために該インバウンドメッセージを処理する」と記載されているが，第１ないし第３のセキュリティー状態のそれぞれについて，送信者識別子及び受信者識別子の両方を用いて決定することまで特定されてはいない。 そして，送信者識別子及び受信者識別子を用いて決定されるセキュリティー状態のうち，第１のセキュリティー状態は，「電気通信ネットワークに接続した相手が誰でも前記受信者ユーザに通信アクセスすることを許可すること」であり，第２のセキュリティー状態は，「電気通信ネットワークに接続した相手が誰でも前記受信者ユーザに通信アクセスすることを拒絶すること」であり，第３のセキュリティー状態は，「プロキシ識別子に関連した予め決められた基準が満たされた場合に，前記電子通信ネットワークに接続した相手のうちの少なくとも１つの相手であって，全ての相手より少ない相手が前記受信者ユーザに通信アクセスすることを許可すること，及び前記基準が満たされていない場合に前記受信者ユーザに対する通信アクセスを拒絶すること」である。すなわち，第３のセキュリティー状態の判断は，「電子通信ネットワークに接続した相手」のうち「全ての相手より少 たされていない場合に前記受信者ユーザに対する通信アクセスを拒絶すること」である。すなわち，第３のセキュリティー状態の判断は，「電子通信ネットワークに接続した相手」のうち「全ての相手より少ない相手が前記受信者ユーザに通信アクセスすることを許可すること」であるから，受信識別子であるプロキシ識別子を判断に用いることに加えて，電子通信ネットワークに接続した相手を特定するための情報である送信者識別子を用いることが必要であると認められる。これに対し，第１及び第２のセキュリティー状態は，電気通信ネットワークに接続した相手のうち所定の条件を満たす相手について，通信アクセスを許可あるいは拒絶することなどが規定されているものではなく，電気通信ネットワークに接続した相手が誰でも，通信アクセスを許可あるいは拒絶することが規定されている。原告が主張するように，送信者ユーザからのインバウンドメッセージのセキュリティー状態が第１の状態に該当する場合でも第２の状態に該当する場合でもそれらのセキュリティー状態を決定するために受信者識別子のみならず送信者識別子が実質的に用いられるとすると，送信者識別子に応じて決定されたセキュリティー状態は，電気通信ネットワークに接続した相手が誰でも，通信アクセスを許可，あるいは拒絶するものとはならないから，これらのセキュリティー状態は，特許請求の範囲に記載された第１のセキュリティー状態及び第２のセキュリティー状態とは異なる状態を意味するものとなる。 したがって，送信者ユーザからのインバウンドメッセージのセキュリティー状態が第１の状態に該当する場合でも第２の状態に該当する場合でもそれらのセキュリティー状態を決定するために受信者識別子のみならず送信者識別子が用いられるとの原告の主張は，特許請求の範囲の記載に基づくものではなく， 態に該当する場合でも第２の状態に該当する場合でもそれらのセキュリティー状態を決定するために受信者識別子のみならず送信者識別子が用いられるとの原告の主張は，特許請求の範囲の記載に基づくものではなく，これを採用することはできない。 イ原告は，if 構文（又はfriends 構文）を登録した後の発明は，本件審決で認定された引用発明ではなく，本件訴訟の審理範囲から外れるものであると主張する。 しかし，本件審決は，前記第２の３(2)ア記載の引用発明を前提とした上で，更に前記２で摘示したような引用例の記載に基づき，引用発明において「friends 構文」の登録がなされたサーバの動作を考慮して，本願発明の進歩性の判断を行っているのであり，実質的には「friends 構文」を登録した後の引用発明について審理しているのであるから，本件訴訟の審理範囲から外れるものではなく，原告の主張を採用することはできない。 なお，本件審決は，引用発明について，相違点の認定では，「引用発明は，セキュリティー状態を決定するために…送信者識別子を用いていない」と記載しているのに対し，相違点１及び２に係る判断では，「引用発明は，送信者識別子…を用いて，インバウンドメッセージに関連したセキュリティー状態を決定するためにインバウンドメッセージを処理している」と記載しており，引用発明がセキュリティー状態を決定するために送信者識別子を用いるのか否かについて，異なる認定をしたかのような記載があり，措辞不適切であるとの批判は免れないが，後者が引用発明においてif 構文が登録されたサーバを指すものであることはその文脈から明らかであるから，審決の結論に影響を及ぼすものではない。 第５ 結論以上の次第であるから，原告の請求は棄却されるべきものである。 知的財 たサーバを指すものであることはその文脈から明らかであるから，審決の結論に影響を及ぼすものではない。 第５ 結論以上の次第であるから，原告の請求は棄却されるべきものである。 知的財産高等裁判所第４部 裁判長裁判官 土肥章大 裁判官 髙部眞規子 裁判官 齋藤巌
▼ クリックして全文を表示