【事件の表示】
　平成　９年特許願第　２４６４２号「共用データ・ファイルを管理するための方法及びシステム」拒絶査定不服審判事件〔平成　９年　９月１９日出願公開、特開平　９−２４４９３６〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯・本願発明
　本願は、平成９年２月７日（パリ条約による優先権主張１９９６年３月８日、英国）の出願であって、平成１４年１月２１日付けで拒絶査定がなされ、これに対し、同年４月１２日に審判請求及び手続補正がなされたが、当審より、平成１７年１１月２１日付けで拒絶理由が通知され、これに対し、平成１８年５月１２日に手続補正がなされたものであり、その請求項１に係る発明は、特許請求の範囲の請求項１に記載された事項により特定される次のとおりのものと認める。（以下、「本願発明」という。）
　
　「移動通信ネットワークを介して接続可能な、複数のコンピュータ・システム上に保持された共用データ・ファイルの複数のコピーを管理する方法であって、
　ａ）前記複数のうちの一つのコンピュータ・システムに保持された前記共用データ・ファイルのローカル・コピーに対して、当該ローカル・コピーに対して実行された複数の変更の記録を保持するステップであって、前記変更の記録が現在の共用データ・ファイルをロガーによりバックアップ・コピーと周期的に比較して行われる、前記保持するステップと、
　ｂ）前記複数のうちの前記一つのコンピュータ・システムにおいて、前記移動通信ネットワークへの接続を介して、前記複数の他のコンピュータ・システムに保持された前記共用データ・ファイルの他のコピーに対して保持された複数の変更の記録を取り出すステップと、ここで前記複数のうちの前記一つのコンピュータ・システムが、少なくとも該ステップｂ）の間、前記複数の変更の記録を取り出すために前記移動通信ネットワークに接続される、
　ｃ）前記複数のうちの前記一つのコンピュータ・システムにおいて、前記保持された変更の記録及び前記取り出された複数の変更の記録を併合して、変更の順序を生成するステップと、
　ｄ）前記複数のうちの前記一つのコンピュータ・システムにおいて、予め定義された規則を前記変更の順序に適用して、前記変更の順序内での衝突を解決するステップと、及び
　ｅ）前記複数のうちの前記一つのコンピュータ・システムにおいて、前記衝突解決済みの変更の順序にもとづいて、前記共用データ・ファイルのローカル・コピーを変更するステップと、
　を含む、前記方法。」
　
２．当審の拒絶理由
　当審より平成１７年１１月２１日付で通知された前記拒絶理由の理由１．の趣旨は、本件出願は、明細書及び図面の記載に不備があるため、特許法第３６条第４項及び第６項第２号に規定する要件を満たしていない、というものであり、具体的には、次のとおりである。
　
「（１）明細書の段落【００５５】の記載「ロガー４１０は、周期的に、ユーザのデータ・ファイル４２０をバックアップ・ファイル５００と比較し、ユーザにより実行された変更を判断する。」の記載からすると、「データ・ファイル４２０」は、ユーザにより実行された変更が反映された変更後のファイルであると認められる。明細書の段落【００５６】の記載「このようにして検出された変更が、ログ５４０に記憶される。調整時に、ネットワークを通じて同一ファイルの他のコピーから受信されるログ５５０が、マージャ５６０により’優先規則’５７０のセットを用いて、優先順位の順に併合される。」、及び、図５の記載において、マージャ５６０が、ログ５４０とログ５５０とを入力していることからして、マージャ５６０は、ユーザの変更操作により生成されたローカルなログ５４０と、他の計算機から取得したログ５５０とをマージ（併合）している。また、明細書の段落【００５６】の記載「最後に、併合され調整されたログが、ローカル・ファイル・コピー４２０上で実行される。」からすると、併合され、衝突解消により調整されたログは、変更後のデータ・ファイル４２０に適用されるものと認められる。
　これらの記載を併せ考えると、ユーザの操作によりデータ・ファイルを変更し、その変更操作を示すローカルなログは、併合及び調整の対象となっているから、変更後のデータ・ファイルに再び適用されることとなる。つまり、同一の変更操作が同一のデータ・ファイルに２度適用される事態が生じる。また、この処理は、各計算機で実行されるため、図３の、交換、マージ、解決、及び、再実行を実行するたびに、各計算機上で共用されるデータ・ファイルの一貫性が無くなってしまうことは明らかである。
　よって、この点において、請求項１−１９に係る発明は、技術的に見て不明確であり、かつ、発明の詳細な説明は、請求項１−１９に係る発明の技術的な意義を当業者が理解できる程度に明確かつ十分に記載していない。
（２）…（以下略）」
　
３．当審の判断
　本願発明の構成のうち、特に「前記衝突解決済みの変更の順序にもとづいて、前記共用データ・ファイルのローカル・コピーを変更する」について、発明の詳細な説明及び図面に、どのように記載されているのかについて検討する。
　なお、本願発明における「共用データ・ファイルのローカル・コピー」は、請求項１、明細書及び図面の全体の記載からして、「データ・ファイル４２０」に対応したものと認められる。
　
　本願明細書には、上記「データ・ファイル４２０」の変更に関し、次のとおり記載されている。
　
「【００５２】衝突の自動解決において、２つの疑問が回答されねばならない。
【００５３】第１に、２つの衝突する変更を想定し、一方が他方を上書きするように、各変更に優先順位が割当てられる必要がある。この優先順位の割当ては、通常、ファイル・コピーの位置にもとづく。すなわち、切断操作を可能にする幾つかのファイル・システムが、'マスタ・コピー'を定義し、これがあらゆる衝突の際に、他のコピーに勝る優先順位を有する。このアプローチは好適な実施例では取られない。なぜなら、ユーザがマシン間で変化しがちであり、その場合、変更の優先順位を、それが実行された位置に結び付けることが、賢明でないと思われるからである。代わりに、好適な実施例では、ファイルを変更するユーザの識別にもとづき、優先レベルを割当てる。変更と共に記録されるタイム・スタンプもまた、優先順位を割当てるために使用される。早期の変更が後の変更を却下する技法が、好適には採用される。なぜなら、逆の技法は、後に実行される変更ほど、成功裡にコミットされる、より大きな機会を有すると言った、反直観的な状況を招くからである。
【００５４】第２に、衝突する変更の処理が定義される必要がある。本発明の好適な実施例において特に有用な、２つの技法が見い出された。'総無効化技法（Total Invalidation Policy）'により、衝突する低優先順位の変更が完全に無効にされる。これは多くの情報を喪失し得るが、ファイル形式を保存するように保証される。代わりに、低優先順位の変更の衝突部分だけを廃棄する'部分無効化技法（Partial Invalidation Policy）'が定義され得る。明らかに、これは非衝突の変更のセットを導出するために必要な、最少量の情報だけを除去する利点を有するが、ファイル形式を保存しないかもしれない。
【００５５】フレームワーク内において、優先順位割当て規則及び無効化技法の両方が、ユーザにより、モデル４３０内で大域的に定義され得る。図５は、調整プロセス内のこのカストマイズ可能なコンポーネント（'モデル'）の概要を示す。ロガー４１０は、周期的に、ユーザのデータ・ファイル４２０をバックアップ・ファイル５００と比較し、ユーザにより実行された変更を判断する。この目的のために、ロガーは、ファイル形式の概略を記述する'ファイル・モデル'５１０、ユーザにより実行され得る'編集操作'５２０のセット、そして最後に、これらの編集操作をデフォルト指定の挿入及び消去操作の順序に変換する変換規則５３０のセットを使用可能にする。特殊なファイル・タイプ及び形式に対応して、ロガー４１０を指導するために、'ファイル・モデル'、'編集操作'、及び'変換規則'が使用され得る。デフォルト指定により、好適な実施例のロガー４１０は、ほとんど挿入及び消去操作に頼り、一様なファイル形式を想定する。
【００５６】このようにして検出された変更が、ログ５４０に記憶される。調整時に、ネットワークを通じて同一ファイルの他のコピーから受信されるログ５５０が、マージャ５６０により、'優先規則'５７０のセットを用いて、優先順位の順に併合される。次に解決／再実行手段５９０により'無効化規則'５８０が適用され、併合された変更セット内での衝突を検出し、除去する。最後に、併合され調整されたログが、ローカル・ファイル・コピー４２０上で実行される。ロギング・プロセスと同様に、併合及び調整の両方のために、デフォルト指定が使用可能である。しかしながら、ユーザは、別の'優先規則'及び（または）'無効化規則'のセットを提供することにより、両方のプロセスをカストマイズするように決定してもよい。
【００５７】全てのカストマイズ可能なパーツのセットが、'モデル'４３０を形成する。モデルはファイルのセット、例えば特定のファイル・タイプの全てのファイル、または特定ファイルに対して定義され得る。
【００５８】好適な実施例の移動アプリケーション・フレームワークにおいて好適に使用される自動衝突解決アルゴリズムの詳細は、Stefan HildとPeter Robinsonによる論文File Replication in a Mobile Environmentで提供されるが、これは本願の優先権主張日現在では公開されていない。この論文のコピーは、本願の出願における参考として含まれ、この論文の内容が本明細書では参照される。この論文は、編集距離の第１の近似を計算するロギング機構の詳細な概略を提供し、そこで述べられる併合及び調整ステップが実際に、共用ファイルの各ローカル・コピー上で実行され得る衝突の無い特定順序の変更を生成するという、数学的な証明を提供する。更に、この論文は、部分調整の順序、すなわち同時に全てのファイル・コピーが同期されない状況にも、調整プロセスが適用され得ることを証明する。こうした状況は、例えば個々のノードが移動通信ネットワークの収束領域から外れたり、任意の他の理由により使用可能でない場合などに当てはまる。」
　
　段落【００５５】の記載「ロガー４１０は、周期的に、ユーザのデータ・ファイル４２０をバックアップ・ファイル５００と比較し、ユーザにより実行された変更を判断する。」の記載からすると、「データ・ファイル４２０」は、ユーザにより実行された変更が反映された変更後のファイルであると認められる。
　段落【００５６】の記載「このようにして検出された変更が、ログ５４０に記憶される。調整時に、ネットワークを通じて同一ファイルの他のコピーから受信されるログ５５０が、マージャ５６０により’優先規則’５７０のセットを用いて、優先順位の順に併合される。」、及び、図５の記載において、「マージャ５６０」が、ログ５４０とログ５５０とを入力していることからして、「マージャ５６０」は、自コンピュータ・システム内においてユーザの変更実行により生成されたローカルなログ５４０と、他のコンピュータ・システムから取得した複数のログ５５０とを優先順位に従って併合している。
　段落【００５６】の記載「次に解決／再実行手段５９０により'無効化規則'５８０が適用され、併合された変更セット内での衝突を検出し、除去する。」からして、「マージャ５６０」により併合されたログは、「解決／再実行手段５９０」が、無効化規則に基づいて衝突を検出し、無効なものを除去している。
　段落【００５６】の記載「最後に、併合され調整されたログが、ローカル・ファイル・コピー４２０上で実行される。」からすると、併合され調整されたログは、変更後の「データ・ファイル４２０」に適用されて、新たなファイルが生成されている。
　また、「解決／再実行手段５９０」が行う「衝突解決」については、段落【００５８】では、本願の優先日前に公開されていない論文を挙げているが、当該論文は、公開されていないものであるので、その内容をもって、「衝突解決」に係る技術的な裏付けとなすことはできない。　
　
　これらから、「マージャ５６０」は、自コンピュータ・システムにより生成したログ５４０と他のコンピュータ・システムから取得した複数のログ５５０とに含まれる「変更」のそれぞれに対し、ファイル・コピーの位置、ユーザの識別、タイム・スタンプ等に基づいて優先順位を割り当て、「解決／再実行手段５９０」は、前記「変更」の間の衝突を検知し、該優先順位に基づいて、低優先順位の「変更」を無効にすることにより、「衝突解決」を図っている。
　すなわち、「衝突解決」は、生成又は取得したログに含まれる複数の「変更」の間の関係に基づいて、衝突を検知し、これを解決するものであるから、自コンピュータ・システムにより生成したログ５４０に含まれる「変更」は、他の「変更」との間で衝突が無い場合、及び、衝突が検知されたとしても優先度が高い場合は、「マージャ５６０」により併合及び調整された後も有効とされる。
　そうすると、ユーザにより実行された「変更」は、「データ・ファイル４２０」に一旦適用され、「マージャ５６０」及び「解決／再実行手段５９０」を経て再度「データ・ファイル４２０」に適用される態様が排除されず、この場合、正しいコピーを生成することができないことは明らかである。
　また、上記の段落【００５２】〜【００５８】以外の記載を参照しても、明細書及び図面には、本願発明の構成にどのような技術上の意義があるのかについて説明する記述はなく、かつ、技術常識を参酌しても自明とはいえない。
　つまり、本願発明の「前記衝突解決済みの変更の順序にもとづいて、前記共用データ・ファイルのローカル・コピーを変更する」は、「共用データ・ファイルのローカル・コピー」に対して、同じ「変更」を２度適用する態様を含み、かつ、発明の詳細な説明及び図面には、このような態様に、どのような技術上の意義があるのかについて明確かつ十分に記載されていない。
　
　よって、本願明細書及び図面は、本願発明の技術上の意義を明確かつ十分に記載していないから、本件出願は、特許法第３６条第４項に規定する要件を満たしていない。
　
４．請求人の主張
　請求人は、平成１８年５月１２日付の意見書において、主として次のように主張している。
　
「しかし、明細書第００５６段落では、上記優先順位の順に変更されることの次のステップとして、解決／再実行手段５９０により、無効化規則５８０が適用され、併合された変更セット内での衝突を検出し、除去すること、が記載されています。このように、本願発明では、衝突する、すなわち２度適用される事態を生じること、を防ぐために、データ・ファイル４２０ですでに変更された衝突部分が廃棄されます（第００５４段落）。或いは、変更を実行するユーザの識別によって、すでに変更された部分への変更を防ぎます（第００５３段落）。」
　
　この主張でも明らかなように、「解決／再実行手段」が行うことは、「併合された変更セット内での衝突を検出し、除去すること」であり、「併合」された変更セットの中での衝突を検出し、除去することであって、自コンピュータ・システム内のデータ・ファイル４２０に既に適用した「変更」を除去することではないから、請求人の主張は、そもそも上記拒絶理由に対する釈明を成していない。
　また、上記主張の「本願発明では、衝突する、すなわち２度適用される事態を生じること、を防ぐために、データ・ファイル４２０ですでに変更された衝突部分が廃棄されます（第００５４段落）。」と主張しているが、段落【００５４】には、生成又は取得したログの「変更」の中に衝突するものがあることを想定し、各「変更」に優先順位を割り当て、各「変更」の間に衝突が検出された場合、優先順位が低いものを除去すること（例えば、複数のコンピュータ・システムが同じデータに対して変更を行った場合に、いずれかを優先して残りを除去すること）が記載されているが、拒絶理由で指摘した問題を解決するために、自コンピュータ・システムで既に適用した「変更」を再度適用することを防止することについて記載されているとは認められない。
　また、上記主張では、段落【００５３】を参照し、「ユーザの識別によって、すでに変更された部分への変更を防ぎます」と主張しているが、段落【００５３】に記載の「ユーザの識別」は、優先順位を割当てるために用いられている。そして、上記３．でも述べたように、「解決／再実行手段５９０」は、衝突が検出された時のみ優先順位に基づいた除去（無効化）を行っているから、優先順位が低い「変更」が必ず除去されるわけではない。つまり、「ユーザの識別」により、すでに「データ・ファイル４２０」に対してなされた「変更」を防ぐことは不可能である。
　なお、仮に、「解決／再実行手段５９０」が、自コンピュータ・システム内で生成したログ５４０に含まれる「変更」（すなわち、「データ・ファイル４２０」に２度適用されるもの）を除去するように構成されていると仮定すると、必ず除去対象となる「変更」をわざわざ併合することは技術的に矛盾するから、本願発明の技術上の意義が発明の詳細な説明に明確かつ十分に記載されていないことに変わりはない。
　よって、請求人の主張は、本願の発明の詳細な説明の記載に基づいたものではないので、採用できない。
　
５．むすび
　以上のとおり、本件出願は、特許法第３６条第４項に規定する要件を満たしていないので特許を受けることができない。
　よって、結論のとおり審決する。