• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 4項1号請求項の削除 特許、登録しない。 G06F
審判 査定不服 4項3号特許請求の範囲における誤記の訂正 特許、登録しない。 G06F
審判 査定不服 2項進歩性 特許、登録しない。 G06F
管理番号 1274209
審判番号 不服2010-21527  
総通号数 163 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2013-07-26 
種別 拒絶査定不服の審決 
審判請求日 2010-09-24 
確定日 2013-05-27 
事件の表示 特願2004-528000「電子メッセージ受信者へのアクセスを制御するためのシステム及び方法」拒絶査定不服審判事件〔平成16年 2月19日国際公開、WO2004/015583、平成17年11月24日国内公表、特表2005-535967〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 1.手続の経緯
本願は、平成15年8月11日(パリ条約に基づく優先権主張2002年8月9日、アメリカ合衆国)を国際出願日とする出願であって、平成22年5月17日付けで拒絶査定がなされ、これに対し、平成22年9月24日に拒絶査定不服審判が請求されるとともに、同時に手続補正がなされたものである。


2.平成22年9月24日付け手続補正書による補正について
平成22年9月24日付け手続補正書による補正(以下、「本件補正」という。)により、補正前の請求項7、8、30、31、34及び36-52が削除され、請求項3の「ユーザ」が「ユーザー」に補正された。
よって、本件補正は、平成18年法律第55号改正附則第3条第1項によりなお従前の例によるとされる同法による改正前の特許法第17条の2第4項第1号及び第3号に規定される「請求項の削除」及び「誤記の訂正」を目的とするものである。


3.本願発明
本願の請求項1に係る発明(以下、「本願発明」という。)は、平成22年9月24日付け手続補正書の特許請求の範囲の請求項1に記載された事項により特定される、以下のとおりのものである。

「 【請求項1】
電子通信ネットワークに接続された受信者ユーザーに対する、該電子通信ネットワークに接続された他のユーザーによる通信アクセスを選択的に許可または拒絶するための方法であって、前記受信者ユーザーが関連した受信者識別子を有し、
A.前記受信者ユーザーに関連した複数の別個のプロキシ識別子を生成するステップであって、前記プロキシ識別子の各々が少なくとも3つの関連するセキュリティー状態を有し、
前記状態の第1の状態が前記電気通信ネットワークに接続した相手が誰でも前記受信者ユーザーに通信アクセスすることを許可することを示し、
前記状態の第2の状態が前記電気通信ネットワークに接続した相手が誰でも前記受信者ユーザーに通信アクセスすることを拒絶することを示し、さらに、
前記状態の第3の状態が、前記プロキシ識別子に関連した予め決められた基準が満たされた場合に、前記電子通信ネットワークに接続した相手のうちの少なくとも1つの相手であって、全ての相手より少ない相手が前記受信者ユーザーに通信アクセスすることを許可すること、及び前記基準が満たされていない場合に前記受信者ユーザーに対する通信アクセスを拒絶することを条件付で示す該ステップと、
B.前記電子通信ネットワークに接続された送信者ユーザーに関連付けられた送信者識別子と、前記複数のプロキシ識別子の1つである前記受信者識別子とを含む該送信者ユーザーからのインバウンドメッセージへの応答で、受信者ユーザーが変更可能なセキュリティー設定に従い、かつ前記送信者識別子及び受信者識別子を用いて、該インバウンドメッセージに関連したセキュリティー状態を決定するために該インバウンドメッセージを処理するステップと、
C.前記決定に従い、
i.前記セキュリティー状態が前記第1の状態に該当する場合、前記インバウンドメッセージの前記受信者ユーザーへの通信アクセスを許可し、かつ、
ii.前記セキュリティー状態が前記第2の状態に該当する場合、前記インバウンドメッセージの前記受信者ユーザーへの通信アクセスを拒絶し、かつ、
iii.前記セキュリティー状態が前記第3の状態に該当し、かつ前記複数のプロキシ識別子の前記1つの前記セキュリティー状態に少なくとも部分的に関連した1つまたは複数の前記予め決められた基準を満たす場合、前記インバウンドメッセージの前記受信者ユーザーへの通信アクセスを許可し、その他の場合に、前記インバウンドメッセージの前記受信者ユーザーへの通信アクセスを拒絶することにより、
前記インバウンドメッセージの前記受信者ユーザーへの通信アクセスを制御するステップとを含む方法。」


4.刊行物
原査定の拒絶の理由に引用された刊行物(特開2000-339236号公報)には、図面と共に、以下の事項が記載されている。

(ア)第0001段落
【0001】
【発明の属する技術分野】本発明は、電子メールに係り、特に、悪戯メールの防止方法及び防止装置に関する。

(イ)第0015段落から第0017段落
【0015】メール転送サーバ1(以下、サーバ1と記載)は、ある一定のフォーマットに該当するメールアドレスを全て特定の人に送るようにする。例えば、メールアドレスが
ueda@xxxxx.server.com
あるいは、ueda.xxxxx@server.com
のようなフォーマットのメールについて、該メールアドレス内の任意の「xxxxx」に該当するメールに対して登録されたメールアドレスへの転送、もしくは該メールに対して登録された特定のメールボックスへの配送を行う。
【0016】「xxxxx 」の部分に任意の長さの文字を許すようにすれば理論的に無限のメールアドレスが可能であり、十分に長い固定長の文字列を許すようにしても非常に多数のメールアドレスから一つのメールボックスへの配送ができる。
【0017】このことにより、ユーザは自分が受け取ると決めた「xxxxx 」を含まないメールアドレスに対するメールを拒否/消去することが簡単にできるようになる。通常の使用では、メールのユーザは自分にメールを出す可能性がある人に対してそれぞれ異なったメールアドレスを通知し、該通知した全てのメールアドレス以外のメールアドレスに届いたメールは捨てるか無視すればよい。

(ウ)第0023段落から第0026段落
【0023】更に、サーバ1は、メール受け付け部3において、送信されてきたメールのアドレスあるいはアドレスパターンの照合を行った後、メールを再配布あるいはメールボックスに入れる際に、前もって与えられたユーザからの指示に従って、メールの破棄、エラーメールを送出することによるメールの拒否、あるいは、ユーザのメールリーダソフトが処理できるような何らかのフィールドの追加などの処理をする。この何らかのフィールドの追加処理では、例えば、米国特許5377354号のような装置を使って、ユーザが容易に無視したり破棄したり、更には読む際の優先度を低くできるようにする。
【0024】ユーザは、サーバ1に対して、指示を行う際に以下のような処理を実施する手段のどれか一つ以上あるいは全てを持つ。
・ある特定のメールアドレスと処理方法を指定し、それ以降そのメールアドレスに届いたメールはその方法で処理する。
・ある特定のメールアドレスのパターンとその処理方法を指定し、それ以降そのパターンにマッチするメールアドレスに届いたメールはその方法で処理する。
・全てのメールアドレスに対して処理方法を指定し、それ以降の全てのメールはその方法で処理する。
【0025】このために、サーバ1の内部に、指定されたアドレスとそのアドレスに対応する処理方法とを対にして記憶する処理内容記憶部2を設ける。同図(b)は、処理内容記憶部2に記憶されるテーブルの例である。このテーブル2aの1行は、アドレス又はアドレスパターンを格納するフィールド、該アドレス又はアドレスパターンに対応する処理方法を格納するフィールド、及び該処理方法に於いて使用される処理方法のパラメータなどを記憶するオプションを記憶するフィールドからなる。サーバ1は、届いたメールのアドレスをテーブル2aに登録されている指定されたアドレス、アドレスパターンと照合し、テーブル2a内にマッチするアドレス、または、アドレスパターンが存在する場合、そのマッチしたアドレスあるいはアドレスパターンに対応する処理を行う。また、全てのメールアドレスに対して処理が指定されている時は、そのユーザへ届いた全てのメールに対して処理を行う。
【0026】サーバ1はまた、ユーザが処理方法の登録/参照を行うための入出力部4を有しており、ユーザから、入出力部4を介して処理方法のリストの参照要求があった時は、そのユーザ名に対応する全ての処理方法のリスト(アドレスパターン、オプションを含む)をユーザに提示する。また、同じく、入出力部4を介するユーザからの処理方法の登録に際しては、
・古い登録の消去、
・登録内容の変更、
・新規の登録
を行う。

(エ)第0047段落から第0050段落
【0047】図6及び図7は、届いたメールが特定の性質を持ったものかどうか判定し、それによってメールの処理方法を指定するサーバ1の処理手順と処理方法の記録例を示す図である。
【0048】この処理方法を指定する場合は、処理方法記憶部2のテーブル2aに、見分けるべき性質の記述、その性質を持っている場合と持っていない場合の処理方法が登録される。見分けるべき性質と、該性質を持っている場合と持っていない場合の処理方法はオプションとしてテーブル2aに記憶される。あるいは、サーバ1の振る舞いを一部固定して、上記性質を持っているメールの場合は何もしないで破棄し、持っていないメールの場合は送り主のアドレスを該メールに記載し、処理方法では性質だけを指定させ、具体的な処理は、サーバ1にオプションとして記憶させるようにしても良い。
【0049】見分けるべき性質は、さまざまなものが考えられるが、メールに関する各種情報のパターンマッチ、例えば、Subject が特定の文字列を含むとか、送出した日付が一定の期間内にあるかどうか、あるいは、本文中に特定の文字列が含まれるかどうかなどが考えられる。
【0050】この処理方法に該当するアドレス宛のメールが届いた場合、サーバ1のメール受け付け部3は、そのアドレスに対応した見分けるべき性質を取り出し、次にそのメールが特定の性質を満たしているかどうか調べ(ステップS10:図6及び図7)、性質が満たされているか否かを判断する(ステップS11:図6及び図7)。次に、満たしている場合は、そのための処理を(ステップS12、S12’)、そうでなければそうでない方の処理を(ステップS13、S13’)、処理方法記憶部2のテーブル2aのオプション・フィールドあるいはサーバ1の固定情報記憶域から取り出し、該当する処理を行う。この処理の方法は、前述した処理方法のいずれであっても良いし、サーバ1によっていくらか制限を加えても良い。あるいは、後述するような処理でも良い。

(オ)第0078段落から第0079段落
【0078】サブプログラム:メールを処理する(処理方法、オプション、メール、拡張ユーザ名、ユーザ名、宛先)
メール処理サブプログラムの機能は、次の通りである。
・処理方法が、「mail」の場合、「ユーザ名@server.com」宛のメールとして、通常の配送処理を行う。
・処理方法が、「dispose 」の場合、単にそのメールを捨てて処理を終了する。
・処理方法が、「error 」の場合、通常処理の中の宛先不明の場合のエラーメール送出のルーチンに行き、該ルーチンの実行によりエラーメールを送出する。
・処理方法が、「header」の場合、オプション部に記憶されている、目印の文字列をメールのヘッダ部に付け加え、「ユーザ名@server.com 」宛のメールとして、通常の配送処理を行う。
・処理方法が、「mark」の場合、メールのヘッダ部分に
X-forwarded-from:宛先
という文字列をつけ加え、「ユーザ名@server.com 」宛のメールとして、通常の配送処理を行う。
・処理方法が、「if」の場合、オプション部は以下の項目がつながった文字列であるとする。
・()で括られた調べるべき性質
・｛｝で括られている、上の性質を満たしたときの処理方法とオプション
・｛｝で括られている、上の性質を満たさないときの処理方法とオプション
調べるべき性質には、以下のいずれかあるいは、それらを＆＆、｜｜、またはつりあった()で括って任意個連結したものとする。
・フィールド名:受理パターン
・フィールド名!非受理パターン
・date before 日付
・date after 日付
ただしパターンは正規表現とする。
【0079】フィールド名はメールのヘッダ部にあるフィールド名で例えばFromあるいは、Subject のようなものである。処理方法とオプションは、メール処理サブプログラムで処理できる処理方法とそのオプションが空白で区切られて並んでいるものとする。ただしオプションがない場合には空白がない場合を許可する。

(カ)第0088段落から第0095段落
【0088】処理方法の登録に際しては、
・古い登録の消去
・登録された処理方法の順位の変更(何番目にそのパターンを調べるか)
・登録内容の変更
・新規の登録
が行えるようになっている。
＜処理方法の登録＞サーバ1は、アドレス名、(サーバ1が解釈できる)コマンド、コマンドのオプションを受け取って、これらをユーザの登録された処理方法のリスト(図1(a)の処理内容記憶部2のテーブル2a)に加える。
【0089】具体例
・add アドレス コマンド名 [オプション]
コマンド名は“dispose ”、“error ”、“mark”、“header”、“if”、“decrypt ”、“mail”のどれかを使用する。
【0090】アドレス、コマンド名、オプションは空白で区切られ、それらをサーバ1は分離して、文字列としてユーザにより登録された処理方法のリストとしてテーブル2aに記憶する。
【0091】ユーザ指定の処理方法がすでにあるときは、新たに追加されたものはリストの最後に置く。“dispose ”、“error ”、“header”はオプションを持たない。
【0092】“mark”コマンドは付加ヘッダ名をオプションとして持つので、サーバ1は以下のようなコマンドを受け付ける。
add アドレス mark ヘッダ名 ヘッダ内容
(例えば、add ueda.broadcast mark X-Possibly-Spam: true)
を受け付け、ヘッダ名(X-Posibly:)とヘッダ内容(true)を文字列としてつなげて、これをオプション部として扱う。
【0093】“if”コマンドはチェック内容とその後の動作をオプションとして与える。オプション文字列は、メール処理サブプログラムのオプション部で受け付けられる構文とする。
【0094】非合致時の動作内容は省略でき、その場合、デフォルトとしてerror コマンドが指定されたものとして、オプション文字列に加えてテーブル2aに記憶する。合致時の動作内容も省略でき、その場合デフォルトとしてmailコマンドが指定されたものとしてテーブル2aに記憶する。ただし非合致時の動作を指定するときは合致時の動作内容は省略できない。
【0095】登録時の構文は、add のコマンドとオプションを合わせたものである。サーバ1が受け取るコマンドは、例えば、以下のようになる。
add ueda.from.friends if (From:friend1@his.domain ｜From:friend2@her.domain )
add ueda.1month.from.990401 if (date before 1999/5/1)｛mail｝｛error ｝
add ueda.report if (Subject :.*bug.*report*)｛if(From:customer1 ｜From:customer2 ｝｛mark X-customer-report :yes ｝｛mark X-bug-report:yes ｝｝｛mail｝
サーバ1はこれらのコマンドを受け取り、オプション部分の全ての文字列をユーザの指定として加える。

以上の刊行物の記載によれば、刊行物には、次の発明(以下、「刊行物記載発明」という。)が記載されていると認められる。

「電子メールの悪戯メールの防止方法であって、
メール転送サーバ1(以下、サーバ1と記載)は、ある一定のフォーマットに該当するメールアドレスを全て特定の人に送るようにし、メールアドレスが
ueda@xxxxx.server.com
あるいは、ueda.xxxxx@server.com
のようなフォーマットのメールについて、該メールアドレス内の任意の「xxxxx」に該当するメールに対して登録されたメールアドレスへの転送、もしくは該メールに対して登録された特定のメールボックスへの配送を行い、このことにより、ユーザは自分が受け取ると決めた「xxxxx 」を含まないメールアドレスに対するメールを拒否/消去することが簡単にできるようになり、
通常の使用では、メールのユーザは自分にメールを出す可能性がある人に対してそれぞれ異なったメールアドレスを通知し、該通知した全てのメールアドレス以外のメールアドレスに届いたメールは捨てるか無視し、
更に、サーバ1は、メール受け付け部3において、送信されてきたメールのアドレスあるいはアドレスパターンの照合を行った後、メールを再配布あるいはメールボックスに入れる際に、前もって与えられたユーザからの指示に従って、メールの破棄、エラーメールを送出することによるメールの拒否、あるいは、ユーザのメールリーダソフトが処理できるような何らかのフィールドの追加などの処理をし、ユーザは、サーバ1に対して、指示を行う際に以下のような処理を実施する手段を持ち、
・ある特定のメールアドレスと処理方法を指定し、それ以降そのメールアドレスに届いたメールはその方法で処理する
このために、サーバ1の内部に、指定されたアドレスとそのアドレスに対応する処理方法とを対にして記憶する処理内容記憶部2を設け、処理内容記憶部2に記憶されるテーブル2aの1行は、アドレス又はアドレスパターンを格納するフィールド、該アドレス又はアドレスパターンに対応する処理方法を格納するフィールド、及び該処理方法に於いて使用される処理方法のパラメータなどを記憶するオプションを記憶するフィールドからなり、サーバ1は、届いたメールのアドレスをテーブル2aに登録されている指定されたアドレス、アドレスパターンと照合し、テーブル2a内にマッチするアドレス、または、アドレスパターンが存在する場合、そのマッチしたアドレスあるいはアドレスパターンに対応する処理を行い、
サーバ1は、ユーザが処理方法の登録/参照を行うための入出力部4を有しており、
届いたメールが特定の性質を持ったものかどうか判定し、それによってメールの処理方法を指定するサーバ1の処理方法を指定する場合は、処理方法記憶部2のテーブル2aに、見分けるべき性質の記述、その性質を持っている場合と持っていない場合の処理方法が登録され、見分けるべき性質と、該性質を持っている場合と持っていない場合の処理方法はオプションとしてテーブル2aに記憶され、見分けるべき性質は、メールに関する各種情報のパターンマッチ、例えば、Subject が特定の文字列を含むとか、送出した日付が一定の期間内にあるかどうか、あるいは、本文中に特定の文字列が含まれるかどうかなどが考えられ、この処理方法に該当するアドレス宛のメールが届いた場合、そのアドレスに対応した見分けるべき性質を取り出し、次にそのメールが特定の性質を満たしているかどうか調べ、性質を満たしている場合は、そのための処理を、そうでなければそうでない方の処理を行う、
電子メールの悪戯メールの防止方法。」


5.対比
本願発明と刊行物記載発明とを以下で対比する。

刊行物記載発明は、「電子メールの悪戯メールの防止方法」であって、「送信されてきたメール」に対して「メールを再配布あるいはメールボックスに入れる際に、前もって与えられたユーザからの指示に従って、メールの破棄、エラーメールを送出することによるメールの拒否、あるいは、ユーザのメールリーダソフトが処理できるような何らかのフィールドの追加などの処理」をするものであるから、本願発明と刊行物記載発明とは、「電子通信ネットワークに接続された受信者ユーザーに対する、該電子通信ネットワークに接続された他のユーザーによる通信アクセスを選択的に許可または拒絶するための方法」である点で一致する。

刊行物記載発明は、「ある一定のフォーマットに該当するメールアドレスを全て特定の人に送るようにし、メールアドレスが
ueda@xxxxx.server.com
あるいは、ueda.xxxxx@server.com
のようなフォーマットのメールについて、該メールアドレス内の任意の「xxxxx」に該当するメールに対して登録されたメールアドレスへの転送、もしくは該メールに対して登録された特定のメールボックスへの配送を行」うものであるから、刊行物記載発明の「ueda@xxxxx.server.com」あるいは「ueda.xxxxx@server.com」というメールアドレスは、受信者に関連する識別子である。
そして、刊行物記載発明は、「メールのユーザは自分にメールを出す可能性がある人に対してそれぞれ異なったメールアドレスを通知」するのであるから、メールの受信者は、複数の別個の識別子を作成して所持していることが明らかである。これらの複数の別個の識別子は、「全て特定の人に送る」ためのものであるから、「特定の人」を代理した識別子であるといえる。
よって、刊行物記載発明の「ueda@xxxxx.server.com」あるいは「ueda.xxxxx@server.com」といった「メールアドレス」は、本願発明の「前記受信者ユーザーが関連した受信者識別子」及び「前記受信者ユーザーに関連した複数の別個のプロキシ識別子」に相当し、本願発明と刊行物記載発明とは、「前記受信者ユーザーが関連した受信者識別子を有」する点及び「前記受信者ユーザーに関連した複数の別個のプロキシ識別子を生成するステップ」を含む点で一致する。

刊行物記載発明は、『ユーザは自分が受け取ると決めた「xxxxx 」を含まないメールアドレスに対するメールを拒否/消去することが簡単にできる』ものであるから、自分が受け取ると決めた「xxxxx 」を含むメールアドレス宛てのメールは、送信者が誰であっても通信が許可される。
よって、刊行物記載発明のこの状態は、本願発明の「前記電気通信ネットワークに接続した相手が誰でも前記受信者ユーザーに通信アクセスすることを許可すること」に相当する。以下、この状態のことを「状態a」という。

刊行物記載発明は、ユーザの指示によって「ある特定のメールアドレスと処理方法を指定し、それ以降そのメールアドレスに届いたメールはその方法で処理する」ような処理を実施する手段を持っており、「前もって与えられたユーザからの指示に従って、メールの破棄、エラーメールを送出することによるメールの拒否」を行うことができるのであるから、このような指示がなされた場合には、刊行物記載発明は、ある特定のメールアドレスに関連して「メールの破棄」又は「メールの拒否」を行い、これはメールの送信者に依存せずに行われる。
よって、刊行物記載発明のこの状態は、本願発明の「前記電気通信ネットワークに接続した相手が誰でも前記受信者ユーザーに通信アクセスすることを拒絶すること」に相当する。以下、この状態のことを「状態b」という。

刊行物記載発明は、「届いたメールが特定の性質を持ったものかどうか判定し、それによってメールの処理方法を指定するサーバ1の処理方法を指定」することができ、「この処理方法に該当するアドレス宛のメールが届いた場合、そのアドレスに対応した見分けるべき性質を取り出し、次にそのメールが特定の性質を満たしているかどうか調べ、性質を満たしている場合は、そのための処理を、そうでなければそうでない方の処理を行う」。
よって、刊行物記載発明のこの状態は、「前記プロキシ識別子に関連した予め決められた基準が満たされた場合に、特定の処理をすること、及び前記基準が満たされていない場合に別の処理をすることを条件(基準が満たされているか否か)付で示」しているといえる。以下、この状態のことを「状態c」という。

以上によれば、刊行物記載発明は、「メールアドレス」(本願発明の用語では「プロクシ識別子」)毎に、状態a、状態b及び状態cの3つの状態を有し得る。
そして、これらの3つの状態は、「悪戯メールの防止」のための状態に相違ないから、「セキュリティー状態」である。
してみると、本願発明と刊行物記載発明とは、「前記プロキシ識別子の各々が少なくとも3つの関連するセキュリティー状態を有し、
前記状態の第1の状態が前記電気通信ネットワークに接続した相手が誰でも前記受信者ユーザーに通信アクセスすることを許可することを示し、
前記状態の第2の状態が前記電気通信ネットワークに接続した相手が誰でも前記受信者ユーザーに通信アクセスすることを拒絶することを示し、さらに、
前記状態の第3の状態が、前記プロキシ識別子に関連した予め決められた基準が満たされた場合に、特定の処理をすること、及び前記基準が満たされていない場合に別の処理をすることを条件付で示す該ステップ」を含む点で一致する。

刊行物記載発明の「メール」は、受信者側の「サーバ1」から見る場合「インバウンドメッセージ」に他ならない。
そして、電子メールは、その規格によって、メールヘッダに送信者のアドレスと受信者のアドレスとが含まれることが規定されている。
してみると、刊行物記載発明の「メール」は、本願発明の「前記電子通信ネットワークに接続された送信者ユーザーに関連付けられた送信者識別子と、前記複数のプロキシ識別子の1つである前記受信者識別子とを含む該送信者ユーザーからのインバウンドメッセージ」に相当する。

刊行物記載発明は、「サーバ1の内部に、指定されたアドレスとそのアドレスに対応する処理方法とを対にして記憶する処理内容記憶部2を設け、処理内容記憶部2に記憶されるテーブル2aの1行は、アドレス又はアドレスパターンを格納するフィールド、該アドレス又はアドレスパターンに対応する処理方法を格納するフィールド、及び該処理方法に於いて使用される処理方法のパラメータなどを記憶するオプションを記憶するフィールドからなり、サーバ1は、届いたメールのアドレスをテーブル2aに登録されている指定されたアドレス、アドレスパターンと照合し、テーブル2a内にマッチするアドレス、または、アドレスパターンが存在する場合、そのマッチしたアドレスあるいはアドレスパターンに対応する処理を行」うものであり、かつ、「サーバ1は、ユーザが処理方法の登録/参照を行うための入出力部4を有して」いるのであるから、刊行物記載発明の「テーブル2a」は、本願発明の「受信者ユーザーが変更可能なセキュリティー設定」に相当し、本願発明と刊行物記載発明とは、「前記電子通信ネットワークに接続された送信者ユーザーに関連付けられた送信者識別子と、前記複数のプロキシ識別子の1つである前記受信者識別子とを含む該送信者ユーザーからのインバウンドメッセージへの応答で、受信者ユーザーが変更可能なセキュリティー設定に従い、かつ受信者識別子を用いて、該インバウンドメッセージに関連したセキュリティー状態を決定するために該インバウンドメッセージを処理するステップ」を含む点で一致する。

上記の対比を総合すると、本願発明と刊行物記載発明とは、「前記決定に従い、
i.前記セキュリティー状態が前記第1の状態に該当する場合、前記インバウンドメッセージの前記受信者ユーザーへの通信アクセスを許可し、かつ、
ii.前記セキュリティー状態が前記第2の状態に該当する場合、前記インバウンドメッセージの前記受信者ユーザーへの通信アクセスを拒絶し、かつ、
iii.前記セキュリティー状態が前記第3の状態に該当し、かつ前記複数のプロキシ識別子の前記1つの前記セキュリティー状態に少なくとも部分的に関連した1つまたは複数の前記予め決められた基準を満たす場合、特定の処理をし、その他の場合に、別の処理をすることにより、
前記インバウンドメッセージの前記受信者ユーザーへの通信アクセスを制御するステップ」を含む点で一致する。

すると、本願発明と刊行物記載発明との一致点及び相違点は、以下のとおりである。

〈一致点〉
「電子通信ネットワークに接続された受信者ユーザーに対する、該電子通信ネットワークに接続された他のユーザーによる通信アクセスを選択的に許可または拒絶するための方法であって、前記受信者ユーザーが関連した受信者識別子を有し、
A.前記受信者ユーザーに関連した複数の別個のプロキシ識別子を生成するステップであって、前記プロキシ識別子の各々が少なくとも3つの関連するセキュリティー状態を有し、
前記状態の第1の状態が前記電気通信ネットワークに接続した相手が誰でも前記受信者ユーザーに通信アクセスすることを許可することを示し、
前記状態の第2の状態が前記電気通信ネットワークに接続した相手が誰でも前記受信者ユーザーに通信アクセスすることを拒絶することを示し、さらに、
前記状態の第3の状態が、前記プロキシ識別子に関連した予め決められた基準が満たされた場合に、特定の処理をすること、及び前記基準が満たされていない場合に別の処理をすることを条件付で示す該ステップと、
B.前記電子通信ネットワークに接続された送信者ユーザーに関連付けられた送信者識別子と、前記複数のプロキシ識別子の1つである前記受信者識別子とを含む該送信者ユーザーからのインバウンドメッセージへの応答で、受信者ユーザーが変更可能なセキュリティー設定に従い、かつ受信者識別子を用いて、該インバウンドメッセージに関連したセキュリティー状態を決定するために該インバウンドメッセージを処理するステップと、
C.前記決定に従い、
i.前記セキュリティー状態が前記第1の状態に該当する場合、前記インバウンドメッセージの前記受信者ユーザーへの通信アクセスを許可し、かつ、
ii.前記セキュリティー状態が前記第2の状態に該当する場合、前記インバウンドメッセージの前記受信者ユーザーへの通信アクセスを拒絶し、かつ、
iii.前記セキュリティー状態が前記第3の状態に該当し、かつ前記複数のプロキシ識別子の前記1つの前記セキュリティー状態に少なくとも部分的に関連した1つまたは複数の前記予め決められた基準を満たす場合、特定の処理をし、その他の場合に、別の処理をすることにより、
前記インバウンドメッセージの前記受信者ユーザーへの通信アクセスを制御するステップとを含む方法。」である点。

〈相違点1〉
本願発明の「第3の状態」は、「前記プロキシ識別子に関連した予め決められた基準が満たされた場合に、前記電子通信ネットワークに接続した相手のうちの少なくとも1つの相手であって、全ての相手より少ない相手が前記受信者ユーザーに通信アクセスすることを許可すること、及び前記基準が満たされていない場合に前記受信者ユーザーに対する通信アクセスを拒絶することを条件付で示す」ものであり、それに対応して、「前記セキュリティー状態が前記第3の状態に該当」するときには、「前記複数のプロキシ識別子の前記1つの前記セキュリティー状態に少なくとも部分的に関連した1つまたは複数の前記予め決められた基準を満たす場合、前記インバウンドメッセージの前記受信者ユーザーへの通信アクセスを許可し、その他の場合に、前記インバウンドメッセージの前記受信者ユーザーへの通信アクセスを拒絶する」処理を行うのに対し、
刊行物記載発明の「第3の状態」は、基準を満たす場合及び基準を満たさない場合の処理の具体的内容が明確ではない点。

〈相違点2〉
本願発明は、インバウンドメッセージに関連したセキュリティー状態を決定するために、「送信者識別子及び受信者識別子」を用いているのに対し、刊行物記載発明は、該セキュリティー状態を決定するために「受信者識別子」を用いているものの、「送信者識別子」を用いていない点。


6.判断

6-1.相違点1及び2について
上記摘記事項(カ)には、ユーザによる処理方法の登録の具体例が記載されている。
第0095段落の「add ueda.from.friends if (From:friend1@his.domain ｜From:friend2@her.domain )」という登録時の構文に注目すると、この構文は、受信者アドレス「ueda.from.friends」に対して、「if (From:friend1@his.domain ｜From:friend2@her.domain )」という処理を登録している。この処理は、テーブル2aに登録される(第0090段落)。
この「if (From:friend1@his.domain ｜From:friend2@her.domain )」は、第0093段落に記載されている「“if”コマンド」であり、第0094段落に説明されている、非合致時及び合致時の動作を省略した形のコマンドであると解釈でき、チェック内容に合致したときはmailコマンドすなわちメールを配送する処理を、チェック内容に合致しないときはerrorコマンドすなわちメールの拒絶処理を行うものと認められる(上記摘記事項(オ)も併せて参照のこと)。
そして、ifコマンドのチェック内容は、「(From:friend1@his.domain ｜From:friend2@her.domain )」であり、メールヘッダのFrom(送信者アドレス)が、「friend1@his.domain」又は「friend2@her.domain」であるかをチェックするものであると認められる。
してみると、刊行物記載発明において、「add ueda.from.friends if (From:friend1@his.domain ｜From:friend2@her.domain )」という構文で処理方法を登録されたサーバ1のテーブル2aは、「ueda.from.friends」というメールアドレス(本願発明の用語では「プロキシ識別子」)に関連して、チェック内容(送信者アドレスが、「friend1@his.domain」又は「friend2@her.domain」であるか)という基準を定め、その基準が満たされた場合にはメールを許可し、満たされない場合にはメールを拒絶することを条件付で示すようになる。これは、本願発明の「第3の状態」に相当することが明らかである。
そして、このような登録がなされたサーバ1は、ueda.from.friends宛てのメールが、「friend1@his.domain」又は「friend2@her.domain」から差し出されたものであるか否かによって、メールを許可又は拒絶するように動作する。この動作は、本願発明の「iii.前記セキュリティー状態が前記第3の状態に該当し、かつ前記複数のプロキシ識別子の前記1つの前記セキュリティー状態に少なくとも部分的に関連した1つまたは複数の前記予め決められた基準を満たす場合、前記インバウンドメッセージの前記受信者ユーザーへの通信アクセスを許可し、その他の場合に、前記インバウンドメッセージの前記受信者ユーザーへの通信アクセスを拒絶する」ことに他ならない。
さらに、刊行物記載発明は、「前記送信者識別子(送信者アドレス)及び受信者識別子(ueda.from.friends)を用いて、該インバウンドメッセージに関連したセキュリティー状態を決定するために該インバウンドメッセージを処理」していることが明らかである。

したがって、相違点1及び相違点2に係る構成は、刊行物の記載から容易になし得る。

6-2.効果について
また、本願発明の構成によって生じる効果も、上記刊行物記載発明から当業者が予測し得る範囲内のもので格別顕著であるとはいえない。


7.むすび
以上のとおり、本願発明は、刊行物記載発明に基いて、当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。

よって、結論のとおり審決する。
 
審理終結日 2012-01-11 
結審通知日 2012-01-17 
審決日 2012-02-01 
出願番号 特願2004-528000(P2004-528000)
審決分類 P 1 8・ 121- Z (G06F)
P 1 8・ 573- Z (G06F)
P 1 8・ 571- Z (G06F)
最終処分 不成立  
前審関与審査官 石井 茂和、高瀬 勤  
特許庁審判長 江口 能弘
特許庁審判官 稲葉 和生
丸山 高政
発明の名称 電子メッセージ受信者へのアクセスを制御するためのシステム及び方法  
代理人 アクシス国際特許業務法人  

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