【事件の表示】
　特願２００２−５９０６９７「移動インスタント・メッセージング及びプレゼンス・サービス」拒絶査定不服審判事件〔平成１４年１１月２１日国際公開、ＷＯ０２／９３９５９、平成１６年１０月２１日国内公表、特表２００４−５３２４７８〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯 
　本願は、２００２年５月１０日（パリ条約による優先権主張外国庁受理２００１年５月１１日、米国、２００１年１１月７日、フィンランド共和国）を国際出願日とする出願であって、平成１９年２月１日付けで拒絶査定がされ、これに対して同年５月７日に審判請求がなされ、その後、当審において平成２２年５月２５日付けで拒絶理由が通知され、これに対して同年１１月１７日付けで意見書が提出されるとともに、手続補正がなされたものである。
　
２．本願発明 
 　本願の請求項１１に係る発明（以下、「本願発明」という。）は、平成２２年１１月１７日付け手続補正書に記載された特許請求の範囲の請求項１１に記載された次のとおりのものと認める。 
　
「移動メッセージング・システムのための移動クライアント装置であって、
　属性名称によって識別される複数のプレゼンス属性種類によって分類されるプレゼンス情報をプレゼンス属性としてサーバに送信する手段（４０６）を備える移動クライアント装置において、
　前記属性の使用を指定する1つかそれ以上のパラメータを備える修飾子をプレゼンス属性に追加する手段（４１６）をさらに備えることを特徴とする移動クライアント装置。」
　
３．引用例
　当審における拒絶の理由で引用したH. Sugano、外４名、“Privacy-enhanced Presence Protocol (PePP)draft-sugano-impp-proposal-pepp-00.txt”、INTERNET-DRAF、２０００年６月、[検索日２００６年９月２５日]インターネット、ＵＲＬ：http://web.archive.org/web/20000831210603/http://ietf.org/internet-drafts/draft-sugano-impp-proposal-pepp-00.txt（以下、「引用例」という。）には、図面とともに、以下の事項が記載されている。（括弧内は当審訳。）
　
（ａ）「3.     Protocol Overview
　
3.1.   Architecture
　
PePP is designed for scalable and secure Instant Messaging and Presence (IM/P) Services.  Because IM/P Services is usually provided as an integrated service, we have designed PePP as a single protocol for both services.
　
The PePP architecture involves two kinds of components; clients and servers.  Clients may serve as user agents to the IM/P services, but may also be other software entity to utilize the services.  Servers may or may not be different for IM and Presence services, but we assume in this document that a single Home Server provides both service for a user.」（第６頁第１行〜１２行）
　
（３．　プロトコル概要
　
３．１．　アーキテクチャー
　
PePPはスケーラブルで安全なインターネットメッセージサービスとプレゼンスサービス（IM/P）のためにデザインされている。IM/Pサービスは通常は統合されたサービスとして提供されるので、我々は両方のサービスのために単一のプロトコルとして、PePPをデザインした。
　
PePPアーキテクチャーは２種類の構成要素、クライアントとサーバーを含む。クライアントはIM/Pサービスに対してユーザエージェントとして動作するが、サービスを利用するために他のソフトウェアのエンティティにもなる可能性がある。サーバーはIMとプレゼンスサービスで異なることもあるし、異ならないこともある。しかしながら、このドキュメントでは１つの「ホームサーバー」がユーザに両方のサービスを提供すると仮定している。）
　
（ｂ）「3.2.1. Privacy Requirements
　
The IMPP Requirements document [Reqts] stipulates a variety of privacy requirements which IM/Presence services must meet.  In addition to confidentiality as the most basic requirement, it states that a means for controlling privacy is necessary based on the observation that users are inclined to hide their activities from the public, and further they sometimes want to block a particular user from subscribing to their activity without letting the subscriber know their intention. This is a requirement for so-called Polite Blocking (5.1.15 [Reqts]).
　
Another requirement for the Presence Service is that users want to show themselves differently to different watchers (5.2.3 [Reqts]), which is considered as a variation on Polite Blocking.   We call this a requirement for Personae.
　
These requirements lead our design practice to have multiple pieces of presence information that can be selectively shown to different subscribers.
　
3.2.2. Presence Sections
　
The PePP model considers Presence Information contained in a PePP resource as a collection of several pieces, each of which is called a presence section.  A presence section may contain a status information of a communication means, that of the user, or any other. A presence section can be considered as an embodiment of the notion of a PRESENCE TUPLE, which is defined by the Model document [Model].
　
The notion of presence sections is intended to be a unit for individual control of publication and filtering.  For publication control, PePP allows the user controlling a PRESENTITY to set an access control list per section.  For filtering control, PePP allows a WATCHER trying to subscribe to a PePP resource is capable of selecting presence sections to be notified their presence change.
　
Considering the privacy requirements such as Polite Blocking and Personae, there may be a case such that the user controlling a PRESENTITY wants to hide completely which presence sections are shown to the WATCHERS. To realize this in PePP, each presence section has a section name as an identifier for the WATCHERS in addition to its unique identifier section ID.  The section ID is used to manipulate the content or control information of the presence section and it is not shown to WATCHERS.  Instead, a section name is shown to WATCHERS.
　
An example of a structure of Presence Information (PI) in a PePP resource is shown in Fig.2.  Here, an entire PI consists of several sections and each section contains a section ID, a section name, status, note, and an optional communication address.  The syntax given here is temporary and the actual syntax of PI is defined in Section 9.
　
             +---- section(ID:xxx1, name:user-status)
             |        +--- status(busy)
             |        +--- note(Don't Call until 18:00pm.)
             |
             +---- section(ID:xxx2, name:user-status)
             |        +--- status(available)
             |        +--- note()
             |
         PI--+---- section(ID:xxx3, name:IM)
             |        +--- status(idle)
             |        +--- address(pepp://pepp.fujitsu.com/suga/iibox)
             |  .     +--- note:(Meeting.)
             |  .
             |  .
             |
             +---- section(ID:xxxZ, name:email)
                      +--- status(available)
                      +--- address(mailto:suga@sub.fujitsu.com)
                      +--- note:()
　
         Fig.2: Presence Information as a set of Presence Sections
　
3.2.3. Section based Access Control
　
Access control in the Presence Service typically controls how to treat requests from WATCHERS.  As stated above, PePP assumes the Presence Information consists of multiple presence sections, and each presence section can have different access control list (ACL).
　
When a request for subscription to a resource is received, the presence server evaluates the ACL of the resource to determine which sections should be shown to the WATCHER.  Because several sections MAY have the same section name, this mechanism can be used for implementing a feature of Personae.
　
In the example of Fig.2, the sections xxx1 and xxx2 have the same section name user-status.  Consider these sections have ACLs such that the section xxx1 accepts user A but denies user B, and the section xxx2 accepts user B but denies user A. When a user A and user B try to subscribe to this resource, user A receives the section xxx1 as user-status and user B receives the section xxx2 with the same name.
　
A WATCHER may receive several sections with the same name according to the ACCESS RULE, and we do not eliminate this situation in the protocol level.  Individual implementation MAY select one of those sections with the same name.
　
Note that ACLs for the requests other than that for subscription is not set for a section, but for a resource.」（第７頁第１３行〜第９頁第２２行）
　
（3.2.1. プライバシー必要条件
　
IMPP要件ドキュメント[Reqts]は、IM/プレゼンスサービスが満たさなければならない種々のプライバシー要求を規定する。その中で、最も基本的な要求としての「機密性」へ加えて、ユーザが公衆からその活動を隠す傾向があるという観察に基づいて、プライバシーをコントロールするための手段が必要ということが書かれている。また、さらに、ユーザは時々特定のユーザが自分の行動を取得することを、その特定のユーザにその意図を知られることなしに阻止したいことがある。
　
プレゼンスサービスの別の要求は、ユーザは異なるWATCHER （参照ユーザ）(5.2.3の[Reqts])に対して、異なるように自分を見せたいということである。それは、「Polite Blocking」(5.1.15 [Reqts])の１つのバリエーションと見なされる。私たちはこれを「Personae」のための要求と読んでいる。
　
これらの要件により、我々の実際の設計で、異なる参照ユーザに選択的に示される多様なプレゼンス情報を持たせることができる。
　
3.2.2. プレゼンスセクション
　
PePPモデルでは、PePPリソースに含まれるプレゼンス情報を、それぞれの要素が「プレゼンス・セクション」と呼ばれるいくつかの要素の集まりとみなす。プレゼンス・セクションはコミュニケーション手段のステータス情報、ユーザのステータス情報又はそれら以外のステータス情報を含んでいる。プレゼンスセクションは、モデルドキュメント[Model]によって定義される「PRESENCE TUPLE」の概念の具体化と見なすことができる。
　
プレゼンスセクションは、公開とフィルタリングについて個別にコントロールするための1つのユニットであるように意図される。公開のコントロールのため、「PRESENTITY」をコントロールするユーザがセクション毎にアクセスコントロールリストを設定することをPePPは許可する。フィルタリングのコントロールのためにPePPは、PePPリソースを参照しようとするWATCHER（参照ユーザ）に対して、プレゼンス情報が変わったことの通知を受けるためのプレゼンスセクションを選択することを可能にする。
　
「Polite Blocking」や「Personae」等のプライバシー要件を考慮すれば、「PRESENTITY」をコントロールするユーザは、どのプレゼンスセクションをWATCHERに参照させるかについて完全に隠しておきたい場合があるかもしれない。PePPの中でこれを実現するために、各プレゼンスセクションは唯一の識別子の「セクションID」に加えてWATCHERのための識別子としての「セクション名」を有している。セクションIDはプレゼンスセクションのコンテンツやコントロール情報を操作するために用いられ、WATCHER には示されない。その代わりセクション名がWATCHER に示される。
　
PePPリソースでのプレゼンス情報(PI)の構造の例をFig.2に示す。ここで、全PI（プレゼンス情報）はいくつかのセクションから成り、各セクションはセクションID及びセクション名、ステータス、ノート、オプションである通信アドレスを含んでいる。ここでの構文は仮のもので、PIの実際の構文はセクション9で定義される。
   
             +---- section(ID:xxx1, name:user-status)
             |        +--- status(busy)
             |        +--- note(Don't Call until 18:00pm.)
             |
             +---- section(ID:xxx2, name:user-status)
             |        +--- status(available)
             |        +--- note()
             |
         PI--+---- section(ID:xxx3, name:IM)
             |        +--- status(idle)
             |        +--- address(pepp://pepp.fujitsu.com/suga/iibox)
             |  .     +--- note:(Meeting.)
             |  .
             |  .
             |
             +---- section(ID:xxxZ, name:email)
                      +--- status(available)
                      +--- address(mailto:suga@sub.fujitsu.com)
                      +--- note:()
　
            Fig.2:　プレゼンスセクションの１つのセットとしてのプレゼンス情報
　
3.2.3. セクションに基づいたアクセス・コントロール
　
プレゼンスサービス中のアクセス・コントロールは典型的にはWATCHERSからのリクエストをどのように扱うかをコントロールする。上述したように、プレゼンス情報は多数のプレゼンスセクションから構成され、各プレゼンスセクションは異なるアクセスコントロールリスト(ACL)を持つことができると、PePPは仮定する。
　
リソースの参照の要求を受けた場合、プレゼンスサーバーはどのセクションをWATCHERSに見せるかを決めるためにリソースのACLを評価する。いくつかのセクションは同じセクション名を持っているかもしれないので、このメカニズムは「Personae」の特徴を実行するために使用される。
　
Fig.2の例では、セクション、「xxx1」及び「xxx2」は同じセクション名を持っている。  これらのセクションが、セクション「xxx1」はユーザAを受け入れるが、ユーザBを拒否し、そして、セクション「xxx2」はユーザBを受け入れるが、ユーザAを拒否するというようなACLを持っていると考える。ユーザAとユーザBがこのリソースを参照しようとするとき、ユーザAは「ユーザ・ステータス」として「xxx1」を受け取り、ユーザBは同じ名前でセクション「xxx2」を受け取る。
　
WATCHERは、アクセスルールに従って同じ名前でいくつかのセクションを受け取るかもしれない。また、私たちはプロトコルレベルでこの状況を排除しない。個々の実装では、同じ名前を持ったそれらのセクションのうちの1つを選択する。
　
注意：参照以外の要求のためのACLは、セクションのセットではなく、リソースのセットである。）
　
（ｃ）「4.3.   Wireless
　
Wireless devices usually have limited computing and communication resources.  As a result, more concise protocols are better and binary formats can be most efficient. However, PePP has adopted text-based formats for readability, extensibility, and ease of debugging.
　
PePP's section-based presence format offers opportunities to reduce the size of tranferred content. For example, PePP allows selective subscription, which allows SUBSCRIBERs to receive only an interesting subset of all presence information sections. We think this selectivity is especially desirable for a wireless environment.」（第２３頁第２５行〜３４行）
　
　（４．３　ワイヤレス
　
ワイヤレスデバイスは通常限られた計算処理能力と通信リソースを有する。結果として、より簡潔なプロトコルが良く、バイナリフォーマットは最も効率的にできる。しかしながら、PePPは読みやすさ、拡張性、デバックのしやすさのためテキストベースのフォーマットを採用した。
　
PePPのセクションベースのプレゼンスフォーマットは転送されるコンテンツのサイズを削減することを可能にする。例えば、PePPは選択的に参照することを許可している。それは、SUBSCRIBER（参照ユーザ）に全てのプレゼンス情報のうちの興味ある部分のみ受信することを許可する。我々はこの選択性はワイヤレス環境にとって特に望ましいと考えている。）
　
（ｄ）「7.     PePP Methods
　
This section describes the methods used in the PePP messages.  We use the following notation to specify the allowable modes of connections and the directions of requests for each method.
　
     s-s : Server Connections.
     c-s : Client Connections, Client-to-Server direction.
     s-c : Client Connections, Server-to-Client direction.
     c-c : Direct Connections.」（第３３頁第１０行〜１７行）
　
（７．　PePP手順
このセクションはPePPメッセージで使用される手順を記載している。次の表記をそれぞれの手順のための接続の許可モードと要求の方向を規定するために用いる。
     s-s : サーバー接続
     c-s : クライアント接続、クライアントからサーバーへの方向
     s-c : クライアント接続、サーバからクライアントへの方向
     c-c : 直接接続）
　
（ｅ）「7.6.   CHANGE
　
7.6.1. Command
　
   CHANGE SP PePP-Address
　
7.6.2. Direction
　
     c-s
　
7.6.3. Headers
　
     From
     Section-ID
     Change-Mode
     Content-Length
     [Duration]
     [Content-Type]
　
7.6.4. Description
　
The CHANGE method is used to alter the content stored at a given resource.  A CHANGE request MUST be targeted to a single presence section by specifying the Section-ID header.  Section-ID header is mandatory and its absence causes a '400 Bad Request' error. A successful CHANGE request may cause notifications to subscribers who subscribe to the relevant presence section.」（第３８頁第４行〜第２２行）
　
（7.6.   CHANGE
7.6.1. コマンド
　
   CHANGE SP PePP-Address
　
7.6.2. 方向
　
     c-s
　
7.6.3. ヘッダ
　
     From
     Section-ID
     Change-Mode
     Content-Length
     [Duration]
     [Content-Type]
　
7.6.4. 説明
　
CHANGE手順は与えられたリソースに記憶されたコンテンツを変更するために用いられる。CHANGE要求はセクションＩＤヘッダで規定される１つのプレゼンスセクションに向けられなければならない。セクションＩＤヘッダは義務で、それがない場合「400 Bad Request」エラーを引き起こす。CHANGE要求の成功により、その関連するプレゼンスセクションを参照中の参照ユーザへ通知が行われる。）
　
　以上の記載によれば、この引用例には、以下の発明（以下、「引用発明」という。）が開示されていると認められる。
　
「スケーラブルで安全なインターネットメッセージサービスとプレゼンスサービス（IM/P）のためにデザインされ、２種類の構成要素、クライアントとサーバーを含んだPePPにおいて、
　PePPモデルでは、PePPリソースに含まれるプレゼンス情報を、それぞれの要素が「プレゼンス・セクション」と呼ばれるいくつかの要素の集まりとみなし、プレゼンス・セクションはコミュニケーション手段のステータス情報、ユーザのステータス情報又はそれら以外のステータス情報を含んでおり、全PI（プレゼンス情報）はいくつかのセクションから成り、各セクションはセクションID及びセクション名、ステータス、ノート、オプションである通信アドレスを含んでおり、リソースに記憶されたコンテンツを変更するためにクライアントからサーバへの方向へ、セクションＩＤヘッダで規定される１つのプレゼンス・セクションに向けられてCHANGE要求が送信され、
　各プレゼンス・セクションは異なるアクセスコントロールリスト(ACL)を持つことができ、リソースの参照の要求を受けた場合、プレゼンスサーバーはどのセクションをWATCHERSに見せるかを決めるためにリソースのACLを評価し、
　セクション、「xxx1」及び「xxx2」は同じセクション名を持っており、セクション「xxx1」はユーザAを受け入れるが、ユーザBを拒否し、そして、セクション「xxx2」はユーザBを受け入れるが、ユーザAを拒否するというようなACLを持っていると考えると、ユーザAとユーザBがこのリソースを参照しようとするとき、ユーザAは「ユーザ・ステータス」として「xxx1」を受け取り、ユーザBは同じ名前でセクション「xxx2」を受け取るものであり、
　公開のコントロールのため、ユーザがセクション毎にアクセスコントロールリストを設定することを許可するPePP。」
　
４．対比
　本願発明と引用発明を対比する
　
　引用発明の「PePP」は、「インターネットメッセージサービスとプレゼンスサービス（IM/P）のためにデザインされ」たものであり、引用発明の「PePP」と本願発明の「移動メッセージング・システム」とは、「メッセージング・システム」である点で共通し、引用発明の「クライアント」と本願発明の「移動クライアント装置」は、「クライアント装置」である点で共通する。
　
　引用発明の「プレゼンス情報」は、「コミュニケーション手段のステータス情報、ユーザのステータス情報又はそれら以外のステータス情報を含」むいくつかの「プレゼンス・セクション」から構成されているので、引用発明の「プレゼンス・セクション」は、本願発明の「プレゼンス属性」に相当し、引用発明の「プレゼンス情報」は、複数の「プレゼンス・セクション」という種類によって分類されているといえる。また、引用発明の「セクション名」は、「プレゼンス・セクション」の名前であるから、本願発明の「属性名称」に相当し、プレゼンス・セクションを識別しているといえる。
　
　引用発明において、PePPリソースはプレゼンス情報を含むので、引用発明の「リソース」、「プレゼンス情報」は、本願発明の「プレゼンス情報」に相当する。そして、引用発明では「リソースに記憶されたコンテンツを変更するためにクライアントからサーバへの方向へ、セクションＩＤヘッダで規定される１つのプレゼンス・セクションに向けられてCHANGE要求が送信され」ることから、引用発明において、サーバのプレゼンス・セクション（前段に記載したように本願発明の「プレゼンス属性」に相当する。）のプレゼンス情報は、クライアントから送信されるCHANGE要求により変更されるものである。すなわち、引用発明のクライアントは、プレゼンス情報に変化があった際は、そのプレゼンス情報を、特定のプレゼンス・セクションに対して送信していることは明らかであり、プレゼンス情報をプレゼンス・セクション（本願発明の「プレゼンス属性」に相当。）としてサーバに送信しているといえる。
　
　引用発明において、「アクセスコントロールリスト(ACL)」は、プレゼンス・セクション毎にあり、どのセクションのプレゼンス情報をWATCHERに見せるか決めているので、本願発明の「属性の使用を指定する1つかそれ以上のパラメータを備える修飾子」に相当する。また、この「アクセスコントロールリスト(ACL)」は、クライアントであるユーザが設定してプレゼンスサーバに送信し、サーバにおいて参照されてプレゼンス情報の公開をコントロールしていることは明らかであり、引用発明において、クライアントが「アクセスコントロールリスト(ACL)」をプレゼンス・セクション（本願発明の「プレゼンス属性」に相当。）に追加する手段を備えているといえる。
　
　したがって、両者は、
「メッセージング・システムのためのクライアント装置であって、
　属性名称によって識別される複数のプレゼンス属性種類によって分類されるプレゼンス情報をプレゼンス属性としてサーバに送信する手段（４０６）を備えるクライアント装置において、
　前記属性の使用を指定する1つかそれ以上のパラメータを備える修飾子をプレゼンス属性に追加する手段（４１６）をさらに備えることを特徴とするクライアント装置。」
で一致するものであり、次の点で相違している。
　
・相違点
　本願発明では、クライアント装置は移動メッセージング・システムのための移動クライアント装置であるのに対し、引用発明では、PePPはメッセージング・システムであるものの移動メッセージング・システムであるかどうか、PePPのクライアントは移動クライアント装置であるかどうか明らかではない点。
　
５．当審の判断
　そこで、上記相違点について検討する。
　
　引用例の摘記事項（ｃ）には、PePPでワイヤレスデバイスを用いることが示唆されており、引用発明において、PePPを移動メッセージング・システムとして、クライアントを移動クライアントとすることは当業者が容易に想到し得たものである。したがって、本願発明は引用発明から当業者が容易に想到等し得たものである。
　
　そして、本願発明の作用効果も、引用発明から当業者が予測できる範囲のものである。
　
　なお、請求人は、平成２２年１１月１７日付け意見書の１．（３）において、「審判官殿は、本願発明に係る「修飾子」は、引用文献１に係る「アクセスコントロールリスト（ＡＣＬ）」に相当すると認定されました。しかしながら引用文献１の１１．１章によれば、ＡＣＬは単にプレゼンス情報へのアクセスを許可する又は拒否する加入者のリストに過ぎません。これに対して本願発明に係る修飾子は、［００４４］に記載されているように、修飾子を伴う属性と属性名称が同じだが修飾子のない属性とを機能的に分離できるものであります。さらに、修飾子は、色、フォント等の様々なユーザ・インタフェース設定を決定するためにも用いることができます（［００７０］ご参照）。したがって、ＡＣＬは本願の修飾子とは全く異なるものであります。なお、引用文献１に係る「セクション名」（６．１２章）は本願発明の属性名称と均等なものと考えられますが、このセクション名には修飾子は規定されておりません。したがって本願発明は、引用文献１によって当業者が容易に発明できたものではありません。」と主張している。
　
　しかしながら、本願の請求項１１には、プレゼンス属性に追加する修飾子について、「前記属性の使用を指定する1つかそれ以上のパラメータを備える」と記載されているだけであり、修飾子のない属性があることや、修飾子がフォント等の様々なユーザ・インタフェース設定を決定することは記載されていないので、本願発明の修飾子が「修飾子を伴う属性と属性名称が同じだが修飾子のない属性とを機能的に分離できる」ことや、「色、フォント等の様々なユーザ・インタフェース設定を決定するためにも用いることができます」という請求人の主張は、本願の請求項１１に係る発明の記載に基づくものではない。そして、引用発明の「アクセスコントロールリスト(ACL)」は、プレゼンスセクション（本願発明の「プレゼンス属性」に相当する。）毎にあり、どのセクションのプレゼンス情報をWATCHERに見せるか決めているので、「属性の使用を指定する1つかそれ以上のパラメータを備える修飾子」といえる。したがって、請求人の上記主張は採用できない。
　
６．むすび
　以上のとおり、本願の請求項１１に係る発明は、引用発明に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　
　したがって、その余の請求項について論及するまでもなく、本願は、拒絶すべきものである。
　
　よって、結論のとおり審決する。