【事件の表示】
　特願２００８−１８２８９１「分散タスク処理」拒絶査定不服審判事件〔平成２１年　３月１２日出願公開、特開２００９−　５４１４２〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１　手続の経緯
　
　本件審判請求に係る出願（以下，「本願」という。）は，平成２０年７月１４日（パリ条約による優先権主張外国庁受理２００７年７月３１日（以下，「優先日」という。），米国）を出願日とする出願であって，平成２１年４月１７日付けで審査請求がなされ，平成２４年２月６日付けで拒絶理由通知（同年２月１４日発送）がなされ，同年４月５日付けで意見書が提出されるとともに，同日付けで手続補正がなされ，同年９月７日付けで最後の拒絶理由通知（同年９月１８日発送）がなされ，これに対して，同年１１月１９日付けで意見書が提出されるとともに，同日付けで手続補正がなされたが，同年１２月５日付けで前記平成２４年１１月１９日付け手続補正を却下する旨の補正の却下の決定（同年１２月１１日発送）がなされるとともに，同日付けで拒絶査定（同年１２月１１日謄本送達）がなされたものである。
　これに対して，「原査定を取り消す。本願は特許をすべきものである、との審決を求める。」ことを請求の趣旨として，平成２５年４月１日付けで審判請求がなされるとともに，同日付けで手続補正がなされた。
　そして，平成２５年６月５日付けで審査官により特許法第１６４条第３項に定める報告（前置報告）がなされ，同年１０月４日付けで当審により特許法第１３４条第４項の規定に基づく審尋（同年１０月８日発送）がなされ，同年１２月１１日付けで回答書の提出がなされ，平成２６年４月１１日付けで当審により拒絶理由通知（同年４月１４日発送）がなされ，同年６月１６日付けで意見書が提出されるとともに，同日付けで手続補正がなされ，同年９月２日付けで当審により最後の拒絶理由通知（同年９月８日発送）がなされ，これに対して，同年１２月３日付けで意見書が提出された。
　
２　平成２６年９月２日付け拒絶理由通知書
　
　上記平成２６年９月２日付けで当審により通知した最後の拒絶理由は、以下のとおりである。
　
『　　　　　　　　　　　　　　　理　由 
　
１．この出願の平成２６年６月１６日付けの手続補正は，出願当初の明細書等に記載した範囲内でしたものではないから，特許法第１７条の２第３項に規定する要件を満たしていない。
　
２．この出願は，発明の詳細な説明及び特許請求の範囲の記載が下記の点で，特許法第３６条第４項第１号，第６項第１号に規定する要件を満たしていない。
　
３．この出願の下記の請求項に係る発明は，その出願前日本国内又は外国において頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて，その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができない。
　
　　　　　　　　　　　　　　　　　記
　
（理由１）
　請求項１，１０，１７の「同一の名称および異なるコンテンツを有する製作物が記憶され，同一の名称およびコンテンツを有する製作物が記憶されないように製作物リポジトリ内に記憶された前記製作物」との記載における，「同一の名称および異なるコンテンツを有する製作物が記憶され」るように「製作物リポジトリ内に記憶された前記製作物」との態様は，出願当初の明細書等には記載されていない。
　すなわち，本願の出願当初の明細書等の段落【００１６】に，
「【００１６】
　ある実施形態において，製作物の表現は，タスク構造と並列にソフトウェアによって管理可能である。並列の製作物のシステムは，典型的に，タスクモデル内に含まれる最低限の製作物の表現に基づいて，中央の製作物リポジトリから１つまたは複数のタスクモデルに，異なる製作物および同一の製作物の異なるバージョンを供給および対応付けることができる。」
　との記載があり，当該記載によれば，“中央の製作物リポジトリに，同一及び異なるバージョンの製作物が，供給可能に記憶される”ことは読み取れるが，“同一”の“製作物”であることが，必ずしも「同一の名称」の「製作物」を意味せず，また，“異なるバージョンの製作物”であることが，必ずしも「異なるコンテンツを有する製作物」を意味しないことから，上記引用の本願の出願当初の明細書等の記載から，「同一の名称および異なるコンテンツを有する製作物が記憶され」るように「製作物リポジトリ内に記憶された前記製作物」との態様までは読み取れない。
　
　よって，請求項１，１０，１７の「同一の名称および異なるコンテンツを有する製作物が記憶され，同一の名称およびコンテンツを有する製作物が記憶されないように製作物リポジトリ内に記憶された前記製作物」は，本願の出願当初の明細書等のすべての記載を総合することにより導かれる技術的事項との関係において，新たな技術的事項を導入しないものでない。
　
　よって，平成２６年６月１６日付けの手続補正は，出願当初の明細書等に記載した範囲内でしたものではないから，特許法第１７条の２第３項に規定する要件を満たしていない。
　
　
（理由２）
（１）請求項１，１０，１７の「同一の名称および異なるコンテンツを有する製作物が記憶され，同一の名称およびコンテンツを有する製作物が記憶されないように製作物リポジトリ内に記憶された前記製作物」との記載における，「同一の名称および異なるコンテンツを有する製作物が記憶され」るように「製作物リポジトリ内に記憶された前記製作物」との記載は，本願明細書の発明の詳細な説明のいずれの記載に対応するのか不明である。
（上記（理由１）で述べたように，本願の出願当初の明細書等の段落【００１６】からは，同様の構成についての記載は，読み取れない。）
　請求項１，１０，１７を引用する請求項２−９，１１−１６，１８−２１についても同様である。
（第３６条第６項第１号）
　
（２）請求項１，１０，１７の「同一の名称および異なるコンテンツを有する製作物が記憶され，同一の名称およびコンテンツを有する製作物が記憶されないように製作物リポジトリ内に記憶された前記製作物」との記載における，「同一の名称および異なるコンテンツを有する製作物が記憶され」るように「製作物リポジトリ内に記憶された前記製作物」との構成に関し，本願明細書の発明の詳細な説明は，「製作物リポジトリ内に記憶された前記製作物」について「同一の名称および異なるコンテンツを有する製作物が記憶され」るようにすることで，具体的に，どのような従来技術の課題を，どのように解消し得るかについて，説明が明確かつ十分になされていない。（記憶する「制作物」を，「同一の名称および異なるコンテンツを有する」ものまで含むようにすることに，技術上格別な意義は見出せない。）
　したがって，この出願の発明の詳細な説明は，当業者が請求項１，１０，１７に係る発明を実施することができる程度に明確かつ十分に記載されていないものであるとともに，請求項１，１０，１７に係る発明の技術上の意義を理解するために必要な事項が十分に記載されておらず，特許法第３６条第４項第１号の経済産業省令で定めるところによる記載がされていないものである。（第３６条第４項第１号（実施可能要件違反，委任省令要件違反））
　
　
（理由３）
請求項：１〜２１
　
［引用文献等一覧］
１．E-Trainer.jp，Microsoft Office Project 2003 オフィシャルマニュアル サーバー導入・管理編，日本，日経ＢＰソフトプレス，２００４年　６月２１日，初版，pp.1-421
２．特開２００７−１１４３９号公報
３．特開２００１−２９０６９２号公報
４．MORI, G.etc，“CTTE: Support for Developing and Analyzing Task Models for Interactive System Design”，米国，IEEE Transactions on Software Engineering, vol.28 No.8，２００２年８月，p.797-813，［平成２６年４月７日検索］，インターネット＜URL：http://hiis.isti.cnr.it/attachments/publications/2002-A0-45_0.pdf＞
５．特開２００６−２６０１０１号公報
６．特開平１１−７０７１４号公報
　
備考
　
（１）請求項１，１０，１７について
　引用文献１の，特に，５５頁下から６行〜５７頁末行，５９頁１行〜６０頁３行及びコラム１つ目内の説明，１２５頁１３行〜１６行，２７５頁５行〜２８０頁１行，及び，２８１頁１行〜２８２頁１行の記載，並びに，６０頁，２７８頁，及び，２８０頁の図を踏まえると，引用文献１には，次の発明（以下，「引用発明」という。）が記載されているものと認められる。
　
　Project Serverの管理及び運用方法であって，
　タスクを管理するサーバを構成するProject ServerとProject Web Accessとが連携可能に接続され，
　Project Web Accessから，Project Serverに登録されているタスクに対しリスクをリンクする際に，
　ログインしたProject Web Accessの画面においてユーザ自身のタスクの一覧を表示し，
　ユーザがリスクをリンクするタスクを選択し，一覧表示されるリスクのうちリンクするリスクを選択して変更を保存すると，タスクへリスクがリンクされたことを確認できるProject Web Accessの画面を表示するものであり，
　Project Web Accessから，Project Serverに登録されているタスクに対しメモを添付する際に，
　ログインしたProject Web Accessの画面においてユーザ自身のタスクの一覧を表示し，
　ユーザがメモを添付するタスクを選択し，メモを作成してＯＫをクリックすると，タスクへメモが添付されたことを確認できるProject Web Accessの画面を表示する，
　方法。
　
　本願の請求項に記載された字句どおりのものとして，本願の請求項１に係る発明（以下，「本願発明」という）と引用発明とを対比すると，本願発明と引用発明とは，以下の点で一致し，また，以下の点で相違する。
　
（一致点）
　タスク管理フロントエンドインタフェースを介してタスク情報更新要求を受信すると，前記タスク情報更新要求をタスク管理サーバに転送するステップと，
　前記タスク管理サーバから前記タスク情報更新要求に対する応答を受信すると，前記タスク情報更新要求に対する応答において受信された少なくともいくつかのデータを使用して前記タスク管理フロントエンドインタフェースを更新するステップと，
　を含み，
　記憶された製作物は，１つまたは複数のタスク情報と対応付けされる方法。
　
（相違点１）
　本願発明が，「タスクモデル」を更新要求の対象とし，また，製作物を付属物として対応付けているのに対して，引用発明は，「タスク」を更新要求やメモの対応付けの対象としているものの，「タスクモデル」という構成については言及していない点。
　
（相違点２）
　タスク管理フロントエンドインタフェース更新のためのタスク管理サーバからの応答に関し，本願発明が，タスクモデル更新要求の「成功確認」であるとしているのに対して，引用発明は，タスクの更新要求に対し何らかの応答を受信しているものの「成功確認」であるとは特定していない点。
　
（相違点３）
　製作物の記憶に関し，本願発明が，「同一の名称および異なるコンテンツを有する製作物が記憶され，同一の名称およびコンテンツを有する製作物が記憶されないように」「製作物リポジトリ内」に行うのに対して，引用発明は，メモの記憶方法及び記憶手段について具体的に特定していない点。
　
（相違点４）
　本願発明が，「更新されたタスクモデルの付属物である製作物が前記タスクモデル内で参照を使用して記述されていないならば，前記タスク管理サーバに前記製作物を含む製作物更新要求を送信するステップ」及び，「前記製作物更新要求の成功確認を受信すると，」同一の名称および異なるコンテンツを有する製作物が記憶され，同一の名称およびコンテンツを有する製作物が記憶されないように製作物リポジトリ内に記憶された「前記製作物への参照を前記タスクモデル内に記述するステップ」を有しているのに対して，引用発明は，メモをタスクに対応付けて添付するよう要求を行っているものの，上記のような各ステップを有していない点。
　
　以下で，上記相違点１ないし相違点４について検討する。
　
（相違点１）について
　タスクに文書等の付属物を対応付けること，及び，当該タスクをモデル化してタスクに関する情報をＸＭＬ等のフォーマットで記述することは，周知技術（例えば，引用文献４の特に８００頁右欄１行〜８０１頁左欄５行，８０５頁左欄下から１９行〜下から３行の記載の参照）であり，
　引用発明のタスク管理において，上記周知技術を採用し，更新要求及びタスクの付属物の対応付けの対象を「タスクモデル」とすること，すなわち，相違点１に係る構成とすることは，当業者が容易に想到し得たものである。
　よって，上記相違点１は格別なものではない。
　
（相違点２）について
　引用文献２（特に段落【００５１】〜【００５４】の記載）には，データベース更新要求が成功した場合に，サーバからＸＭＬデータ（本願発明の「成功確認」に相当）を取得して，該ＸＭＬデータに基づいたＤＨＴＭＬ要素を生成してブラウザに出力させることが記載されている。
　引用発明，及び，引用文献２に記載された技術とは，サーバに対して更新要求を送る点で共通の機能を有するものであるから，引用発明に上記引用文献２に記載された技術を適用し，Project Server からタスクへのリスクのリンクの変更保存の反映結果である「成功確認」を受信し，Project Web Access画面を更新するよう構成することは，当業者にとって格別な困難性を要するものではない。
　してみると，引用発明のタスク管理において，タスクモデル更新要求の「成功確認」の受信によって，Project Web Access画面を更新するようにすること，すなわち，相違点２に係る構成とすることは，当業者が容易に想到し得たものである。
　よって，上記相違点２は格別なものではない。
　
 （相違点３）及び（相違点４）について
　引用発明におけるメモは，タスクに対応付けられて何らかの記憶手段に記憶されるものであるところ，当該記憶手段として，リポジトリを採用することは周知技術（例えば，引用文献５の特に【要約】の記載を参照）といえ，また，記憶手段へのファイル等の記憶を，ファイル名や内容によりどのように排他処理するかは，必要により適宜決める設計的事項（例えば，同一のファイル名を有するデータの記憶がされないように処理することは，引用文献３の段落【００４０】〜【００４６】に，また，同一ファイル名でも異なる内容のデータの記憶は行われるように処理することは，引用文献６の段落【００３５】，【００３９】に，それぞれ記載されている。）であり，引用発明におけるメモの記憶に関し，上記周知技術等を採用し，「同一の名称および異なるコンテンツを有する製作物が記憶され，同一の名称およびコンテンツを有する製作物が記憶されないように」「製作物リポジトリ内」に行うようにすることに，格別困難性は認められない。
　また，上記「（相違点１）について」で検討した如く，タスクに文書等を対応付けること，及び，「タスクモデル」として記述することはいずれも周知であるところ，付属物である上記メモについても当該周知の構成を採用することで，タスクモデルのＸＭＬにおける参照という形式により，対応付けられたメモに関する情報を記述することも，格別困難性を要せずに想到し得る程度のことであり，その場合，更新されたタスクに対し，対応するメモがタスクモデル内に記述されていないと判断されれば，メモをタスクモデル内に記述するよう更新要求を行って記述させることは必然的に行う事項であって，当業者であれば容易になし得ることである。
　してみると，引用発明のタスク管理において，「同一の名称および異なるコンテンツを有する製作物が記憶され，同一の名称およびコンテンツを有する製作物が記憶されないように」「製作物リポジトリ内」に行うとともに，「更新されたタスクモデルの付属物である製作物が前記タスクモデル内で参照を使用して記述されていないならば，前記タスク管理サーバに前記製作物を含む製作物更新要求を送信するステップ」及び，「前記製作物更新要求の成功確認を受信すると，」同一の名称および異なるコンテンツを有する製作物が記憶され，同一の名称およびコンテンツを有する製作物が記憶されないように製作物リポジトリ内に記憶された「前記製作物への参照を前記タスクモデル内に記述するステップ」を有するようにすること，すなわち，相違点３及び４に係る構成とすることは，当業者が容易に想到し得たものである。
　よって，上記相違点３及び４は格別なものではない。
　
　そして，本願発明の奏する作用効果は，引用発明，引用文献２に記載の事項，及び，周知技術等の奏する作用効果から予測される範囲内のものにすぎず，格別顕著なものということはできない。
　したがって，本願発明は，引用発明，引用文献２に記載の事項，及び，上記周知技術等から，当業者が容易に発明をすることができたものである。
　
（２）請求項２〜２１について
　請求項２〜２１に係る発明についても，ウェブサービス，ローカルキャッシュ，サブタスク，インターフェース等の周知の構成について限定したものであり，格別な構成はなく，引用発明，引用文献２に記載の事項，及び，上記周知技術等から，当業者が容易に想到し得たことである。』
　
３　平成２６年１２月３日付け意見書の概要
　
　上記平成２６年１２月３日付けで提出された意見書の概要は、以下のとおりである。
（当審注：下線は，参考のために当審で附加したものである。） 
　
『１．理由１（新規事項）について
　理由１では、本願の平成２６年６月１６日付けの手続補正は特許法第１７条の２第３項に規定する要件を満たしていない、と認定されています。『「同一の名称および異なるコンテンツを有する製作物が記憶され」るように「製作物リポジトリ内に記憶された前記製作物」との態様は，出願当初の明細書等には記載されていない。』というご指摘に対し、以下に意見を申し述べます。
　
　製作物を製作物リポジトリ内に保存する処理に関して、段落００６０には、「アプリケーションは含まれる製作物オブジェクトの参照を利用して、物理的な付属物がタスクオブジェクト内で製作物の参照を使用して既に記述されているかどうか検査する（５１０）。
・・・付属物が適切な製作物オブジェクトの参照を通してタスクオブジェクト内で表現されていないならば、製作物ウェブサービスクライアントは、適切な付属物の全てのコンテンツ（バイト）を含みうる製作物更新要求を生成（５１２）および送信（５１４）する。」と記載され、
　段落００６１には、「サーバ上で要求が解析され（５１６）、受信したコンテンツについてチェックサムを作成する（５１８）。そして、製作物がサーバ上に既に存在するかどうか確認するために、サーバ上の既存の製作物が検査される（５２０）。製作物が存在しないならば、製作物は製作物リポジトリ内に保存される（５２４）。製作物が存在するならば、記憶されているデータソースから製作物が取得される（５２６）。」と記載されています。
　そして、製作物リポジトリにおける製作物の管理に関して、段落００４６には、「製作物ウェブサービス１３２は、典型的に、タスク管理バックエンドアプリケーション１２８内で製作物の管理の責任を負う。製作物の管理は、典型的に、クライアントから供給される製作物のコンテンツを製作物リポジトリ１３８内に記憶し、必要に応じて、製作物のコンテンツおよび情報を製作物クライアント１２０に供給することを含む。それによって、製作物ウェブサービス１３２は、製作物の名称および製作物のコンテンツのチェックサム、例えば、製作物のコンテンツをユニークに識別するＣＲＣ３２チェックサムに応じて、異なる製作物のバージョンを識別し、クライアントに供給する。」と記載されています。
この記載から、一例として、製作物リポジトリにおける製作物を特定するために、「製作物の名称」と、製作物のコンテンツをユニークに識別する「製作物のコンテンツのチェックサム」が使用されることが読み取れます。
　そして、段落００２０の「製作物は、典型的に、サーバ上の製作物リポジトリ内に記憶され、それによって、同一の名称を有する各々の利用可能な製作物は、既に存在する製作物について重複して生成されないように、チェックサムにより明示的に検査される。」という記載によれば、製作物が製作物リポジトリ内に記憶された結果として、
同一の名称を有する製作物が既に存在する製作物と重複して生成されないように、チェックサムにより検査されます。
この検査の結果、既に存在する製作物のコンテンツと、同一の名称を有する製作物のコンテンツとが重複する場合、この同一の名称を有する製作物は記憶されません。従って、重複しなければ記憶されると考えられます。
　
　従って、「同一の名称および異なるコンテンツを有する製作物が記憶され」るように「製作物リポジトリ内に記憶された前記製作物」との態様は、出願当初の明細書に記載されていると思料致します。
　
　
２．理由２（記載不備）について
　理由２では、本願は発明の詳細な説明及び特許請求の範囲の記載が特許法第３６条第４項第１号，第６項第１号に規定する要件を満たしていない、と認定されています。ご指摘の（１）、（２）に対し、以下に意見を申し述べます。
　
（１）
『請求項１，１０，１７の・・・「同一の名称および異なるコンテンツを有する製作物が記憶され」るように「製作物リポジトリ内に記憶された前記製作物」との記載は，本願明細書の発明の詳細な説明のいずれの記載に対応するのか不明である。』というご指摘については、理由１に関して説明致しました通りです。
　
（２）『本願明細書の発明の詳細な説明は，「製作物リポジトリ内に記憶された前記製作物」について「同一の名称および異なるコンテンツを有する製作物が記憶され」るようにすることで，具体的に，どのような従来技術の課題を，どのように解消し得るかについて，説明が明確かつ十分になされていない。』というご指摘については次の通りです。
　従来技術の課題について、段落０００２には、「組織の内部プロセスは、一般的に、タスクまたはプロジェクト管理ソフトウェアを使用して追跡される。そのようなソフトウェアはプロジェクトおよびタスクのモデル化を可能とする。これらのモデルは典型的に静的である。しかし、多くの組織内の運用は、予測できない形態で変化しうる、緩く定義された、または、動的なプロセスを利用する。」と記載され、段落０００４には、「プロジェクトファイルの複数の実例が存在するので、プロジェクトファイルは、複数回、複製されなければならない。結果として、プロジェクトのためのファイルは、非常に大きくなりうる。」と記載されています。すなわち、組織内でのタスクまたはプロジェクト管理ソフトウェアの運用において、複製によりプロジェクトのためのファイルが非常に大きくなり得
ます。
　本願発明は、「同一の名称および異なるコンテンツを有する製作物が記憶され、同一の名称およびコンテンツを有する製作物が記憶されないように製作物リポジトリ内に記憶された前記製作物」という構成を有し、この構成により、段落００３０に「製作物のコンテンツは、複製のコンテンツを有する製作物の生成を防止するために役立つようにチェックサムに基づいて検査される。」と記載されていますように、複製のコンテンツを有する製作物の生成を防止します。
　一方、
同一の名称および異なるコンテンツを有する製作物が記憶されますので、段落００１０に「ここでの各種の実施形態は、進行中の組織運営への阻害または悪影響なしにタスクが定義および修正されうるメカニズムを提供する。・・・そのような修正は、定義されたタスクのプロセス、または、タスク定義を伴う文書のような製作物に行われうる。」と記載されていますように、同一の名称の製作物を修正しても他の組織のタスクまたはプロジェクト管理に影響を与えません。
　
　
３．理由３（進歩性欠如）について
　理由３では、本願発明は特許法第２９条第２項の規定により特許を受けることができない、と認定されています。
　拒絶理由通知書の「（相違点３）及び（相違点４）について」の７行目以降の「同一ファイル名でも異なる内容のデータの記憶は行われるように処理することは，引用文献６の段落［００３５］，［００３９］に，それぞれ記載されている。」というご指摘について意見を申し述べます。
　
　引用文献６（特開平１１−７０７１４号公報）の段落００３５には、「本発明では、このように書式情報ファイル管理テーブル３を持つことにより、任意の場所に書式情報ファイルを作成しても、文書ファイル印刷手段４は、その作成場所を認識することが可能となる。その結果として、同一名称の書式を別々の書式情報ファイルに格納しておき、用途に応じて印刷形態を変更することが可能となり、印刷業務の汎用性を拡大することができる。」と記載されています。この段落中に「同一名称の書式を別々の書式情報ファイルに格納しておき、」、段落００３９に「同一名称であり、かつ定義内容の異なる書式を別々の書式情報ファイルに格納し、用途に応じて使い分けることができる」、段落００１０に「書式情報ファイルａ，ｂ，ｎから成る書式情報ファイル群２の作成を行う書式情報ファイル作成手段１と、書式情報ファイルａ，ｂ，ｎの管理情報を格納する書式情報ファイル管理テーブル３と、」と記載されていることと、ファイル名が同一でもよいなど特に言及がないことから、書式情報ファイルは互いに異なる名称で区別されていると考えられます。
　すなわち、引用文献６では、書式の名称は同一であり、書式の定義内容は異なり、書式が格納される書式情報ファイルは互いに異なる名称で区別されていると考えられます。これは、「同一ファイル名でも異なる内容のデータの記憶は行われる」こととは異なります。
　
　従って、本願発明の「同一の名称および異なるコンテンツを有する製作物が記憶され、同一の名称およびコンテンツを有する製作物が記憶されないように製作物リポジトリ内に記憶された前記製作物」という構成は引用文献に記載も示唆もされていませんので、本願発明は進歩性を有すると思料致します。
・・・（後略）』
　
４　当審による拒絶理由通知書の理由１（新規事項）について
　
ア　請求項１，１０，１７の「同一の名称および異なるコンテンツを有する製作物が記憶され，同一の名称およびコンテンツを有する製作物が記憶されないように製作物リポジトリ内に記憶された前記製作物」との記載における，「同一の名称および異なるコンテンツを有する製作物が記憶され」るように「製作物リポジトリ内に記憶された前記製作物」との態様は，出願当初の明細書等には記載されていない。
　
イ　すなわち，本願の出願当初の明細書等の段落【００１６】に，
「【００１６】
　ある実施形態において、製作物の表現は、タスク構造と並列にソフトウェアによって管理可能である。並列の製作物のシステムは、典型的に、タスクモデル内に含まれる最低限の製作物の表現に基づいて、中央の製作物リポジトリから１つまたは複数のタスクモデルに、異なる製作物および同一の製作物の異なるバージョンを供給および対応付けることができる。」
との記載があり，当該記載によれば，“中央の製作物リポジトリに，異なる製作物および同一の製作物の異なるバージョンが，供給可能に記憶される”ことは読み取れるが，“異なる製作物および同一の製作物の異なるバージョン”が，「同一の名称および異なるコンテンツを有する製作物」を意味することまでは読み取れない。
　
ウ　そして，本願の出願当初の明細書等の他の記載を参酌しても，請求項１，１０，１７に記載されている「同一の名称および異なるコンテンツを有する製作物が記憶され」るように「製作物リポジトリ内に記憶された前記製作物」は，読み取れない。
　
エ　なお，請求人は，上記平成２６年１２月３日付け意見書において，
「同一の名称を有する製作物が既に存在する製作物と重複して生成されないように、チェックサムにより検査されます。・・・この検査の結果、既に存在する製作物のコンテンツと、同一の名称を有する製作物のコンテンツとが重複する場合、この同一の名称を有する製作物は記憶されません。従って、重複しなければ記憶されると考えられます。」
と主張している。
　
オ　しかしながら，特開２００５−２１６２４０号公報（下記参考文献１）の段落【００５９】〜【００６８】（特に，段落【００６６】及び【００６７】のステップ１７４を参照）に記載されるように，同一ファイル名を有し，チェックサムを比較した結果，重複しない場合であっても，当該データが登録されない場合もあることから，請求人の上記主張（すなわち，「検査の結果、既に存在する製作物のコンテンツと、同一の名称を有する製作物のコンテンツとが・・・重複しなければ記憶されると考えられます」という主張）は採用することができない。
　
カ　したがって，請求項１，１０，１７の「同一の名称および異なるコンテンツを有する製作物が記憶され，同一の名称およびコンテンツを有する製作物が記憶されないように製作物リポジトリ内に記憶された前記製作物」は，本願の出願当初の明細書等のすべての記載を総合することにより導かれる技術的事項との関係において，新たな技術的事項を導入しないものでない。
　
キ　よって，上記平成２６年６月１６日付けの手続補正は，出願当初の明細書等に記載した範囲内でしたものではないから，特許法第１７条の２第３項に規定する要件を満たしていない。
　
５　当審による拒絶理由通知書の理由２（記載不備）について
　
（１）理由２（１）について
　
ア　上記「４　当審による拒絶理由通知書の理由１（新規事項）について」で述べたように，請求項１，１０，１７の「同一の名称および異なるコンテンツを有する製作物が記憶され，同一の名称およびコンテンツを有する製作物が記憶されないように製作物リポジトリ内に記憶された前記製作物」との記載における「同一の名称および異なるコンテンツを有する製作物が記憶され」るように「製作物リポジトリ内に記憶された前記製作物」との記載は，本願明細書の発明の詳細な説明のいずれの記載に対応するのか不明である。
　
イ　したがって，請求項１，１０，１７，及び，これらの請求項を引用する請求項２ないし９，請求項１１ないし１６，請求項１８ないし２１における「同一の名称および異なるコンテンツを有する製作物が記憶され」るように「製作物リポジトリ内に記憶された前記製作物」との記載は，本願明細書の発明の詳細な説明のいずれの記載に対応するのか不明であるから，本願の請求項１ないし２１の記載は，特許法第３６条第６項第１号に規定する要件を満たしていない。
　
（２）理由２（２）について
　
ア　請求項１，１０，１７の「同一の名称および異なるコンテンツを有する製作物が記憶され，同一の名称およびコンテンツを有する製作物が記憶されないように製作物リポジトリ内に記憶された前記製作物」との記載における，「同一の名称および異なるコンテンツを有する製作物が記憶され」るように「製作物リポジトリ内に記憶された前記製作物」との構成に関し，本願明細書の発明の詳細な説明は，「製作物リポジトリ内に記憶された前記製作物」について「同一の名称および異なるコンテンツを有する製作物が記憶され」るようにすることで，具体的に，どのような従来技術の課題を，どのように解消し得るかについて，説明が明確かつ十分になされていない。（記憶する「制作物」を，「同一の名称および異なるコンテンツを有する」ものまで含むようにすることに，技術上格別な意義は見出せない。）
　
イ　したがって，この出願の発明の詳細な説明は，当業者が請求項１，１０，１７に係る発明を実施することができる程度に明確かつ十分に記載されていないものであるとともに，請求項１，１０，１７に係る発明の技術上の意義を理解するために必要な事項が十分に記載されておらず，特許法第３６条第４項第１号に規定する要件を満たしていない。
　
（３）出願人の主張について
　
ア　なお，請求人は，上記平成２６年１２月３日付け意見書において，
「『請求項１，１０，１７の・・・「同一の名称および異なるコンテンツを有する製作物が記憶され」るように「製作物リポジトリ内に記憶された前記製作物」との記載は，本願明細書の発明の詳細な説明のいずれの記載に対応するのか不明である。』というご指摘については、理由１に関して説明致しました通りです。」，
「同一の名称および異なるコンテンツを有する製作物が記憶されますので、段落００１０に「ここでの各種の実施形態は、進行中の組織運営への阻害または悪影響なしにタスクが定義および修正されうるメカニズムを提供する。・・・そのような修正は、定義されたタスクのプロセス、または、タスク定義を伴う文書のような製作物に行われうる。」と記載されていますように、同一の名称の製作物を修正しても他の組織のタスクまたはプロジェクト管理に影響を与えません。」
と主張している。
　
イ　しかしながら，上記したように，本願の出願当初の明細書等から，「同一の名称および異なるコンテンツを有する製作物が記憶され」る態様を読み取ることはできないことから，請求人の当該主張についても，採用することはできない。
　
６　本願発明の進歩性について
　
　以上のように，本願の特許請求の範囲の請求項１に係る発明（以下，「本願発明」という。）は，上記「４　当審による拒絶理由通知書の理由１（新規事項）について」で述べたように，新規事項を含むものであり，また，上記「５　当審による拒絶理由通知書の理由２（記載不備）について」で述べたように，記載不備を含むものであるが，仮に，本願発明が，字句通りのものであるとして，その進歩性について検討する。
　
（１）本願発明
　
　本願発明は，上記平成２６年６月１６日付け手続補正書により補正された明細書及び特許請求の範囲の記載からみて，その特許請求の範囲の請求項１に記載された以下のとおりのものと認める。
　
「タスク管理フロントエンドインタフェースを介してタスクモデル更新要求を受信すると、前記タスクモデル更新要求をタスク管理サーバに転送するステップと、
　前記タスク管理サーバから前記タスクモデル更新要求の成功確認を受信すると、前記タスクモデル更新要求の成功確認において受信された少なくともいくつかのデータを使用して前記タスク管理フロントエンドインタフェースを更新するステップと、
　更新されたタスクモデルの付属物である製作物が前記タスクモデル内で参照を使用して記述されていないならば、前記タスク管理サーバに前記製作物を含む製作物更新要求を送信するステップと、
　前記製作物更新要求の成功確認を受信すると、同一の名称および異なるコンテンツを有する製作物が記憶され、同一の名称およびコンテンツを有する製作物が記憶されないように製作物リポジトリ内に記憶された前記製作物への参照を前記タスクモデル内に記述するステップと、
　を含み、
　前記製作物リポジトリ内に記憶された製作物は、１つまたは複数のタスクモデルと対応付けされる方法。」
　
（２）引用文献
　
（２−１）引用文献１
　
ア　本願の優先日前に頒布され，原審の拒絶の査定の理由である上記平成２４年９月７日付けの拒絶理由通知において引用された文献である，『E-Trainer.jp，“Microsoft Office Project 2003 オフィシャルマニュアル サーバー導入・管理編”，日本，日経ＢＰソフトプレス，２００４年６月２１日，初版，pp.55-64, 125-126, 275-282』（以下，「引用文献１」という。）には，図面とともに，以下の技術的事項が記載されている。
（当審注：下線は，参考のために当審で附加したものである。） 
　
Ａ　「Project Server 2003では、Outlookを使用中のユーザーからの要望により、次のような機能が追加されました。
　
　●Projectで割り当てられたタスクがOutlookの予定表にインポートされる。
　●割り当てられたタスクへの実績報告をOutlookからも実施できる。
　●ProjectのタスクのインポートやProject Serverへの更新の送信をスケジュールでの自動実行によって行える。
　
Outlookとの連携機能の設定 
　
　
Project ServerとOutlookとの連携を行うには、Outlook用のProject Web AccessアドインをProject Serverからあらかじめダウンロードして設定しておく必要があります
　
▲Outlookとの連携機能を設定する
○１：Outlookを起動し、クライアントコンピュータでOutlookが使用可能な状態に設定されていることを確認する。
○２：Outlookを閉じる。
○３：Project Web AccessからProject Serverに接続する。
○４：［タスク］メニューをクリックする。
○５：［自分のタスクの表示］ページの［アクション］から［Outlookの予定表からタスクを表示して進捗をレポート］をクリックする。
○６：［Outlook機能の使用］ページの［今すぐダウンロード］をクリックする。
○７：確認のメッセージが表示されるので、［はい］をクリックする。
○８：［ファイルのダウンロード］ダイアログボックスの［開く］をクリックする。
○９：［Outlook用のMicrosoft Office Projectアドインセットアップ］ダイアログボックスの［インストール］をクリックする。
○１０：確認のメッセージが表示されるので、［ＯＫ］をクリックする。
○１１：Outlookを起動する。」（５５頁下から６行〜５７頁末行）
（当審注：上記記載について，便宜上，横▲記号の表記を「▲」に，丸数字の表記を「○数字：」に替えて示している。以下同じ。）
　
Ｂ　「Project Serverとの接続設定
　
　
OutlookからProject Serverに接続する
Outlookは、Project Serverにログインして割り当て情報を取得したり、タスクの実績を報告したりします
　
▲Project Serverとの接続設定を行う
○１：Outlookを起動する。
○２：［ツール］−［オプション］をクリックする。
○３：［オプション］ダイアログボックスの［Project Web Access］タブをクリックし、［ログイン情報の入力］をクリックする。
○４：［ログイン情報の入力］ダイアログボックスの［Project ServerのＵＲＬ］ボックスに接続するProject ServerのＵＲＬを入力し、［Windowsユーザーアカウントを使用する］オプションボタンを選択して、［ＯＫ］をクリックする。
○５：［オプション］ダイアログボックスに戻るので、［ＯＫ］をクリックする。○６：Project Serverとの接続設定が行われたことを確認する。
　
　なお、接続時に使用するユーザーがProject Server認証の場合には、［ログイン情報の入力］ダイアログボックスの［Project Serverアカウントを使用する］オプションボタンを選択し、［ユーザー名］ボックスにユーザー名を入力します。」（５９頁１行〜６０頁３行）
　
Ｃ　「Outlookからの実績報告
　Outlookから割り当てられたタスクの実績報告を行うことができます。
・・・（中略）・・・
▲プロジェクト管理者への実績を報告する
○１：Outlookを起動する。
○２：［ツール］−［Project Web Access］−［Project Web Accessホームページ］をクリックする。
○３：Project Web Accessの［ホーム］ページが表示される。
○４：［タスク］メニューの［すべて更新］または［選択した行の更新］をクリックし、プロジェクト管理者に実績を報告する。」（６２頁下から４行〜６４頁７行）
　
Ｄ　「４．１　Project Web Accessの使用
　
　「Project Web Access」はプロジェクトメンバーが、Project Serverに発行されたプロジェクト情報を参照したり、進捗を報告したりする場合に使用するツールの１つです。」（１２５頁１３行〜１６行）
　
Ｅ　「５．６　役割別の作業：メンバー
　
　
ここでは、メンバーが行う作業について説明します
　メンバーは、自分が割り当てられたタスクを実施し、プロジェクト管理者に定期的にタスクの実績を報告する必要があります。そのため、Project Web Accessを使用して割り当てられたタスクの実績報告を行います。また、自分が割り当てられたタスクに関する進捗だけでなく、関連するリスク、懸案事項、ドキュメントなどを登録することも主な作業になります。
・・・（中略）・・・
タスクへのリスク、懸案事項、ドキュメントのリンク
　
　
Project Web Accessを使用して、リスク
を既にProject Serverに登録されているタスクにリンク
することができます
　
▲タスクへリスクをリンクする
○１：Project Web Accessにログインする
○２：［タスク］メニューをクリックする。
○３：［自分のタスクの表示］ページの一覧からリスクをリンクするタスクを選択し、［リスクのリンク］をクリックする
○４：［タスク審査委員会の招集（理念の追求／中止の決定）にプロジェクトリスクをリンク］ページの［プロジェクトリスクのリンク］をクリックする。
○５：プロジェクトのリスクとして登録されているリスクが一覧表示されるので、リスクをリンクするタスクのチェックボックスをオンにし、［変更の保存］をクリックする
○６：［“自分のタスク”に戻る］をクリックする
○７：タスクへリスクがリンクされたことを確認する
　
Ｆ　上記Ｅの記載に関連して，上記○３：時点でタスクへリスクがリンクされる前の［自分のタスクの表示］ページ画面例，及び，上記○７：時点でタスクへリスクがリンクされた後の［自分のタスクの表示］ページ画面例が，それぞれ，２７８頁及び２８０頁に示されている。
　
Ｇ　「
タスクへのメモの添付
　メンバーは、タイムシートビューを使用して割り当てられたタスクの実績報告をプロジェクト管理者に行います。しかし、タイムシートビューだけでは、タスクの詳細状況を伝えることができない場合があります。そのようなときには、タスクに「メモ」を添付することで対応します。
詳細状況を説明したメモをタスクに添付することで、実績情報だけでは伝わらない内容をプロジェクト管理者に報告することができます
　
▲タスクへメモを添付する
○１：Project Web Accessにログインする
○２：［タスク］メニューをクリックする。
○３：［自分のタスクの表示］ページの一覧からメモを添付するタスクを選択し、［メモの挿入］をクリックする
○４：［Project Web Access割り当てメモ−−Ｗｅｂページダイアログ］ダイアログボックスの一覧に添付するメモの内容を入力し、［ＯＫ］をクリックする
○５：タスクへメモが添付されたことを確認する
　
Ｈ　上記Ｇの記載に関連して，上記○３：時点でタスクへメモが添付される前の［自分のタスクの表示］ページ画面例，及び，上記○５：時点でタスクへメモが添付された後の［自分のタスクの表示］ページ画面例が，それぞれ，２８１頁及び２８２頁に示されている。
　
イ　ここで，上記引用文献１に記載されている事項を検討する。
　
（ア）引用文献１は“Project Serverの管理及び運用方法”について説明する文献であり，その内，上記Ｅは，ユーザがProject Web Accessを使用して，Project Serverに登録されているタスクに対しリスクをリンクする方法について，また，上記Ｇは，同じくユーザがProject Web Accessを使用して，Project Serverに登録されているタスクに対しメモを添付する方法について説明している。
　
（イ）上記Ｂの「OutlookからProject Serverに接続する・・・Outlookは、Project Serverにログインして割り当て情報を取得したり、タスクの実績を報告したりします」との記載，上記Ｃ及びＤの記載によれば，引用文献１の「Project Server」が，タスクを管理するサーバを構成するものであることは明らかであり，
　また，上記Ａの「Project ServerとOutlookとの連携を行うには、Outlook用のProject Web AccessアドインをProject Serverからあらかじめダウンロードして設定しておく必要があります」及びＢの「OutlookからProject Serverに接続する」との記載によれば，引用発明の「Project Server」と「Project Web Access」とは，連携可能に接続されていることがよみとれることから，引用文献１には，
“タスクを管理するサーバを構成するProject ServerとProject Web Accessとが連携可能に接続され”ること
が説明されていると言える。
　
（ウ）上記Ｅの「ここでは、メンバーが行う作業について説明します」，「Project Web Accessを使用して、リスク・・・を既にProject Serverに登録されているタスクにリンク・・・することができます」，「○１：Project Web Accessにログインする」，「○３：［自分のタスクの表示］ページの一覧からリスクをリンクするタスクを選択し、［リスクのリンク］をクリックする」，「○５：プロジェクトのリスクとして登録されているリスクが一覧表示されるので、リスクをリンクするタスクのチェックボックスをオンにし、［変更の保存］をクリックする」，「○６：［“自分のタスク”に戻る］をクリックする」，「○７：タスクへリスクがリンクされたことを確認する」との記載から，引用文献１には，
“Project Web Accessから，Project Serverに登録されているタスクに対しリスクをリンクする際に，
　ログインしたProject Web Accessにおいてユーザ自身のタスクの一覧を表示し， 
　ユーザがリスクをリンクするタスクを選択し，一覧表示されるリスクのうちリンクするリスクを選択して変更を保存すると，タスクへリスクがリンクされたことを確認できる”こと
が説明されていると言える。
　そして，上記“Project Web Accessにおいてユーザ自身のタスクの一覧を表示し”た状態，及び，上記“タスクへリスクがリンクされたことを確認できる”状態は，上記Ｆで説明したように，Project Web Accessの画面を表示している状態である。
　してみると，引用文献１には，
“Project Web Accessから，Project Serverに登録されているタスクに対しリスクをリンクする際に，
　ログインしたProject Web Accessの画面においてユーザ自身のタスクの一覧を表示し，
　ユーザがリスクをリンクするタスクを選択し，一覧表示されるリスクのうちリンクするリスクを選択して変更を保存すると，タスクへリスクがリンクされたことを確認できるProject Web Accessの画面を表示する”こと
が説明されていると言える。
　
（エ）上記Ｇの「タスクへのメモの添付」，「詳細状況を説明したメモをタスクに添付することで、実績情報だけでは伝わらない内容をプロジェクト管理者に報告することができます」，「○１：Project Web Accessにログインする」，「○３：［自分のタスクの表示］ページの一覧からメモを添付するタスクを選択し、［メモの挿入］をクリックする」，「○４：［Project Web Access割り当てメモ−−Ｗｅｂページダイアログ］ダイアログボックスの一覧に添付するメモの内容を入力し、［ＯＫ］をクリックする」，「○５：タスクへメモが添付されたことを確認する」との記載から，引用文献１には，
“Project Web Accessから，Project Serverに登録されているタスクに対しメモを添付する際に，
　ログインしたProject Web Accessにおいてユーザ自身のタスクの一覧を表示し， 
　ユーザがメモを添付するタスクを選択し，メモを作成してＯＫをクリックすると，タスクへメモが添付されたことを確認できる”こと
が説明されていると言える。
　そして，上記“Project Web Accessにおいてユーザ自身のタスクの一覧を表示し”た状態，及び，上記“タスクへメモが添付されたことを確認できる”状態は，上記Ｈに示されるようにProject Web Accessの画面を表示している状態である。
　してみると，引用文献１には，
“Project Web Accessから，Project Serverに登録されているタスクに対しメモを添付する際に，
　ログインしたProject Web Accessの画面においてユーザ自身のタスクの一覧を表示し，
　ユーザがメモを添付するタスクを選択し，メモを作成してＯＫをクリックすると，タスクへメモが添付されたことを確認できるProject Web Accessの画面を表示する”こと
が説明されていると言える。
　
ウ　以上，（ア）ないし（エ）で指摘した事項を踏まえると，引用文献１には，次の発明（以下，「引用発明」という。）が記載されているものと認められる。
　
「Project Serverの管理及び運用方法であって，
　タスクを管理するサーバを構成するProject ServerとProject Web Accessとが連携可能に接続され，
　Project Web Accessから，Project Serverに登録されているタスクに対しリスクをリンクする際に，
　ログインしたProject Web Accessの画面においてユーザ自身のタスクの一覧を表示し，
　ユーザがリスクをリンクするタスクを選択し，一覧表示されるリスクのうちリンクするリスクを選択して変更を保存すると，タスクへリスクがリンクされたことを確認できるProject Web Accessの画面を表示するものであり，
　Project Web Accessから，Project Serverに登録されているタスクに対しメモを添付する際に，
　ログインしたProject Web Accessの画面においてユーザ自身のタスクの一覧を表示し，
　ユーザがメモを添付するタスクを選択し，メモを作成してＯＫをクリックすると，タスクへメモが添付されたことを確認できるProject Web Accessの画面を表示する，
　方法。」
　
（２−２）引用文献２
　
　本願の優先日前に頒布され，原審の拒絶の査定の理由である上記平成２４年９月７日付けの拒絶理由通知において引用された刊行物である，特開２００７−１１４３９号公報（平成１９年１月１８日出願公開。以下，「引用文献２」という。）には，図面とともに，以下の技術的事項が記載されている。
（当審注：下線は，参考のために当審で附加したものである。）
　
Ｊ　「【００５１】
　図８は、データ更新処理の内容を示すフローチャートである。サブウィンドゥにデータが表示された後、例えばユーザが「品目名称」テキストボックスに表示されている「釘」という内容を「机」へ変更してからツールバーの「保存」ボタンを押すと、Ｓ５０においては、
表示エンジンがデータ更新要求を受け付ける
・・・（中略）・・・
【００５４】
　そして、
データベースの更新処理が成功した場合
XMLデータが端末へ返送されてくる
Ｓ５３においては、表示エンジンがこのXML更新済みデータ情報を取得する
Ｓ５４においては、対応するDHTML要がを生成され、Ｓ５５においては、完成したDHTML要素がブラウザに出力される
　
（２−３）引用文献３
　
　本願の優先日前に頒布され，上記平成２５年１０月４日付けの審尋で援用した上記平成２５年６月５日付けの前置報告において引用された刊行物である，特開２００１−２９０６９２号公報（平成１３年１０月１９日出願公開。以下，「引用文献３」という。）には，図面とともに，以下の技術的事項が記載されている。
（当審注：下線は，参考のために当審で附加したものである。）
　
Ｋ　「【００４０】図２は、図１に示すＦＴＰサーバのアップロード処理を説明するためのフローチャートである。
【００４１】ユーザ端末４ａからアップロードするファイルおよびそのファイル名がＦＴＰサーバ１へ送信されると、図２に示すように、ステップＳ１において、ＦＴＰサーバ１のファイル管理部１２は、通信制御部１４を介してアップロードされたファイルおよびそのファイル名を受信する。
【００４２】次に、ファイル管理部１２は、
アップロードされたファイルのファイル名がファイル格納メモリ１３にすでに記憶されているファイルのファイル名と同一であるか否かを判断し
【００４３】
アップロードされたファイルのファイル名が同一でない場合、ステップＳ３において、ファイル管理部１２は、受信したファイルおよびそのファイル名をファイル格納メモリ１３に格納する
・・・（中略）・・・
【００４５】
一方、ステップＳ２において、同一のファイル名があると判断された場合、ステップＳ５において、ファイル管理部１２は、通信制御部１４を介してファイル名が重複している旨を通知するためのデータを送信する
【００４６】送信されたデータはインターネット２およびプロバイダサーバ３ａを介してユーザ端末４ａに受信され、ユーザ端末４ａでは、ＦＴＰクライアントソフトによりファイル名が重複していることをユーザに通知する。ファイル名が重複していることがわかったユーザは、ファイル名を変更して再度ファイルおよび変更したファイル名を送信する。」
　
（２−４）引用文献４
　
　本願の優先日前に頒布され，上記平成２６年４月１１日付けの当審による拒絶理由通知において引用された文献である，『MORI, G.etc，“CTTE: Support for Developing and Analyzing Task Models for Interactive System Design”，米国，IEEE Transactions on Software Engineering, vol.28 No.8，２００２年８月，p.797-813，［平成２６年４月７日検索］，インターネット＜URL：http://hiis.isti.cnr.it/attachments/publications/2002-A0-45_0.pdf＞』（以下，「引用文献４」という。）には，図面とともに，以下の技術的事項が記載されている。
（当審注：下線は，参考のために当審で附加したものである。）
　
Ｌ　「3 
HOW THE TASK MODEL IS REPRESENTED
・・・（中略）・・・ 
　The main features of ConcurTaskTrees are: 
・・・（中略）・・・ 
・
Concurrent notation. A rich set of possible temporal relationships between the tasks can be defined.
（当審訳：3 
タスクモデルの表現方法
・・・ （中略）・・・
　ConcurTaskTreesの主な機能は次のとおりである：
・・・ （中略）・・・
・
同時記録。タスク間の可能な時間的関係の豊富なセットを定義することができる。
　
Ｍ　「4.6 Saving the Specification in Various Formats 
　At any time, it is possible to save all or parts of the specification and, vice versa, to insert parts of specifications previously saved into the current specification. It is also possible to save all or parts of the specification as jpeg images. This is particularly useful when inserting them in documents, manuals, or reports related to the application that is being considered. 
　It is also possible to 
save the task model in XML format
indicate the syntax for XML expressions that correctly represent task models
（当審訳：4.6　様々なフォーマットの仕様での保存
　いつでも，すべてまたは一部の仕様を保存することや，その逆に，現在の仕様に，以前に保存された仕様の一部を挿入することが可能である。これは，JPEG画像として仕様の全部または一部を保存することもまた可能である。これは，検討されているアプリケーションに関連するドキュメント，マニュアル，またはレポートにそれらを挿入する際に，特に有用である。
　
ＸＭＬ形式でタスクモデルを保存する
正確にタスクモデルを表すＸＭＬ表現のための構文を示す
　
（２−５）引用文献５
　
　本願の優先日前に頒布され，上記平成２６年４月１１日付けの当審による拒絶理由通知において引用された刊行物である，特開２００６−２６０１０１号公報（平成１８年９月２８日出願公開。以下，「引用文献５」という。）には，図面とともに，以下の技術的事項が記載されている。
（当審注：下線は，参考のために当審で附加したものである。）
　
Ｎ　「【要約】
【課題】メッセージのタスクへの影響度を自動的かつ即時的に分析する。
【解決手段】作業用端末１００のメッセージ集計部１４０がメッセージを集計してバックエンド３００の
メッセージデータ管理リポジトリ
　
（３）参考文献
　
（３−１）参考文献１
　
　本願の優先日前に頒布された刊行物である，特開２００５−２１６２４０号公報（平成１７年８月１１日出願公開。以下，「参考文献１」という。）には，図面（特に，図７）とともに，以下の技術的事項が記載されている。
（当審注：下線は，参考のために当審で附加したものである。）
　
Ｐ　「【００６０】
　
ステップ１６６では
ファイル名を認識し、認識したファイル名と同一のファイル名が画像記憶部４２に記憶されているか否かを判定する
・・・（中略）・・・
【００６４】
　一方、
印刷対象の原稿が印刷システム１０で過去に印刷が行われた原稿である場合は、ステップ１６６の判定が肯定されてステップ１６８へ移行し、印刷対象の印刷画像データと同一のファイル名と対応付けられたチェックサムデータ
を画像記憶部４２から取り出し、取り出したチェックサムデータを印刷対象の印刷画像データのチェックサムデータ
と
比較する
次のステップ１７０ではチェックサムが不一致か否か判定する
【００６５】
　また、
チェックサムが不一致のラインが存在している場合
ステップ１７０の判定が肯定された場合はステップ１７２へ移行する
【００６６】
　上記の通知が行われることで、印刷指示者は、印刷対象の原稿が前回の印刷時から変更されていることを認識し、明示されたラインに加えられている変更を確認することで、該変更が自身が把握している変更内容か（すなわち印刷対象の原稿に対して為された変更が正規の変更か）否か判断する。そして、ＢＥＰ２０又はクライアント端末２２のキーボードを介して判断結果を入力する。
次のステップ１７４では
チェックサムが不一致となったラインに加えられている変更が正規の変更か否か判定する
・・・（中略）・・・
【００６８】
　一方、
印刷対象の原稿に加えられている変更が、印刷指示者が把握している変更であった場合には、ステップ１７４の判定が肯定されてステップ１７８へ移行する
この場合、ステップ１７８で画像記憶部４２へのチェックサムデータ等の登録が行われ
　
（３−２）参考文献２
　
　本願の優先日前に頒布された刊行物である，特開２００７−１７２１１３号公報（平成１９年７月５日出願公開。以下，「参考文献２」という。）には，図面（特に，図４及び図８）とともに，以下の技術的事項が記載されている。
（当審注：下線は，参考のために当審で附加したものである。）
　
Ｑ　「【００５０】
　ここで、メモリカード４５内の「AAAA0003.JPG」が、デジタルカメラにより編集されていた場合について説明する。具体的には、
「AAAA0003.JPG」が、ファイル名の変更はないものの、ユーザによりデジタルカメラの編集モードを利用して編集されていたとする
【００５１】
　
かかる場合、ファイル名の変更はないものの、ヘッダは書き換わっている
したがって
ファイルの同一性の判断処理により、メモリカード４５の「AAAA0003.JPG」と、ＣＤ−Ｒに記録されている「AAAA0003.JPG」とが非同一であると判断される
そして
例えば、「AAAB0003.JPG」とリネームされて、ＣＤ−Ｒに記録される
・・・（中略）・・・
【００５７】
　＜
変形例
　本発明は、上記実施形態に制限されない。
上記実施形態は、本発明の技術的思想の範囲内で様々変形が可能である
【００５８】
　
例えば
ファイルの同一性の判断のためにヘッダをそのままチェックするのではなく、チェックサムやＣＲＣ
値を利用することもできる
　
（４）対比
　
　本願発明と引用発明とを対比する。
　
ア
（ア）本願発明の「タスクモデル」とは，本願の出願当初の明細書等の段落【００１７】の「タスクモデル（タスク記述）。」との記載，段落【００１８】の「タスクモデル記述としてのＸＭＬ文書」との記載，段落【００２３】の「タスクモデル１２６の抽出は、典型的に、抽出され、標準化されたタスク記述を与える。・・・タスクモデル１２６はフォーマットを提供し、そのフォーマットでタスクはローカルに記憶され、クライアント層１０２とサーバ層１０４との間で送信される。」との記載，及び，段落【００３２】の「タスクモデル１２６は、抽出され、標準化されたタスクの表現であり、・・・タスクモデルは、論理的にツリー状の構造であり、ＸＭＬ文書におけるようなマークアップ言語で記述することができる（図２のタスクモデル例を参照）。」との記載によれば，タスクについての表現に係る情報であり，タスク情報である。
（イ）一方，引用発明の「タスク」も，「Project Serverに登録され」記憶されており，当該記憶が所定の情報に基づいて行われていることは明らかであり，そして，「Project Serverに登録され」記憶されている当該「タスクに対しリスクをリンクする」ことは，「ユーザがリスクをリンクするタスクを選択し，一覧表示されるリスクのうちリンクするリスクを選択して変更を保存する」というユーザ操作に基づく要求により行われる。
（ウ）してみると，引用発明の「タスク」に係る所定の情報と，本願発明の「タスクモデル」とは，ともに，“タスク情報”である点で共通し，また，引用発明の「タスクに対しリスクをリンクする」ための要求と，本願発明の「タスクモデル更新要求」とは，ともに，“タスク情報更新要求”である点で共通する。
　
イ
（ア）引用発明の「Project Web Access」は，ユーザに表示する画面を有し，当該画面よりユーザによるタスクの操作を可能としていることから，「タスク管理フロントエンドインタフェース」に他ならない。
（イ）また，引用発明は「タスクを管理するサーバを構成するProject ServerとProject Web Accessとが連携可能に接続され」ているところ，「Project Serverに登録されているタスクに対し」，「Project Web Access」の画面から，「ユーザがリスクをリンクするタスクを選択し，一覧表示されるリスクのうちリンクするリスクを選択して変更を保存」していることから，「Project Web Access」は，その画面を介して「タスクに対しリスクをリンクする」ためのユーザ操作に基づく要求を受け取り，当該要求を，リスクのリンクについてProject Serverへ反映させるために送信していることは明らかである。
（ウ）してみると，引用発明の「Project Serverに登録されているタスクに対し」，「Project Web Access」の画面から，「ユーザがリスクをリンクするタスクを選択し，一覧表示されるリスクのうちリンクするリスクを選択して変更を保存する」ことと，本願発明の「タスク管理フロントエンドインタフェースを介してタスクモデル更新要求を受信すると、前記タスクモデル更新要求をタスク管理サーバに転送するステップ」とは，ともに，“タスク管理フロントエンドインタフェースを介してタスク情報更新要求を受信すると，前記タスク情報更新要求をタスク管理サーバに転送するステップ”である点で共通する。
　
ウ
（ア）本願発明の「タスクモデル更新要求の成功確認」とは，「タスクモデル更新要求」を受信したことを受けて，「タスク管理フロントエンドインタフェース」更新を行うことから，「タスクモデル更新要求」に対する応答であるといえる。
（イ）一方，引用発明は，「Project Serverに登録されているタスクに対し」，「Project Web Access」の画面から，「ユーザがリスクをリンクするタスクを選択し，一覧表示されるリスクのうちリンクするリスクを選択して変更を保存する」ことによって，「タスクへリスクがリンクされたことを確認できるProject Web Accessの画面を表示」していることから，Project Web Accessにおいて，ユーザ操作に基づく要求に対する何らかの応答を受信し，その応答に基づくデータにより，タスクへリスクがリンクされたことを確認できるProject Web Accessの画面を生成し表示していることは明らかである。
（ウ）してみると，引用発明の「タスクへリスクがリンクされたことを確認できるProject Web Accessの画面を表示」することと，本願発明の「タスク管理サーバから前記タスクモデル更新要求の成功確認を受信すると、前記タスクモデル更新要求の成功確認において受信された少なくともいくつかのデータを使用して前記タスク管理フロントエンドインタフェースを更新するステップ」とは，ともに，“タスク管理サーバから前記タスク情報更新要求に対する応答を受信すると，前記タスク情報更新要求に対する応答において受信された少なくともいくつかのデータを使用して前記タスク管理フロントエンドインタフェースを更新するステップ”である点で共通する。
　
エ
（ア）引用発明の「メモ」は，「タスク」に対応付けられており，また，「Project Serverに登録され」た「タスク」に添付することで，「Project Server」中の何らかの記憶手段に記憶されていることは明らかである。
（イ）してみると，引用発明の「メモ」が所定の記憶手段に記憶され「タスク」と対応付けられていることと，本願発明の「製作物リポジトリ内に記憶された製作物は、１つまたは複数のタスクモデルと対応付けされる」こととは，ともに，“記憶された製作物は，１つまたは複数のタスク情報と対応付けされる”ことである点で共通する。 
　
オ　以上から，本願発明と引用発明とは，以下の点で一致し，また，以下の点で相違する。
　
（一致点）
「タスク管理フロントエンドインタフェースを介してタスク情報更新要求を受信すると，前記タスク情報更新要求をタスク管理サーバに転送するステップと，
　前記タスク管理サーバから前記タスク情報更新要求に対する応答を受信すると，前記タスク情報更新要求に対する応答において受信された少なくともいくつかのデータを使用して前記タスク管理フロントエンドインタフェースを更新するステップと，
　を含み，
　記憶された製作物は，１つまたは複数のタスク情報と対応付けされる方法。」
　
（相違点１）
　
　本願発明が，「タスクモデル」を更新要求の対象とし，また，製作物を付属物として対応付けているのに対して，引用発明は，「タスク」を更新要求やメモの対応付けの対象としているものの，「タスクモデル」という構成については言及していない点。
　
（相違点２）
　
　タスク管理フロントエンドインタフェース更新のためのタスク管理サーバからの応答に関し，本願発明が，タスクモデル更新要求の「成功確認」であるとしているのに対して，引用発明は，タスクの更新要求に対し何らかの応答を受信しているものの「成功確認」であるとは特定していない点。
　
（相違点３）
　
　製作物の記憶に関し，本願発明が，「同一の名称および異なるコンテンツを有する制作物が記憶され、同一の名称およびコンテンツを有する製作物が記憶されないように」「製作物リポジトリ内」に行うのに対して，引用発明は，メモの記憶方法及び記憶手段について具体的に特定していない点。
　
（相違点４）
　
　本願発明が，「更新されたタスクモデルの付属物である製作物が前記タスクモデル内で参照を使用して記述されていないならば、前記タスク管理サーバに前記製作物を含む製作物更新要求を送信するステップ」及び「前記製作物更新要求の成功確認を受信すると」同一の名称および異なるコンテンツを有する製作物が記憶され、同一の名称およびコンテンツを有する制作物が記憶されないように製作物リポジトリ内に記憶された「前記製作物への参照を前記タスクモデル内に記述するステップ」を有しているのに対して，引用発明は，メモをタスクに対応付けて添付するよう要求を行っているものの，上記のような各ステップを有していない点。
　
（５）当審の判断
　
　上記相違点１ないし相違点４について検討する。
　
ア　相違点１について
　
（ア）タスクに文書等の付属物を対応付けること，及び，当該タスクをモデル化してタスクに関する情報をＸＭＬ等のフォーマットで記述することは，本願の優先日前に，周知技術（例えば，上記引用文献４の上記Ｌ及びＭ等参照）であった。
（イ）してみると，引用発明のタスク管理において，上記周知技術を採用し，更新要求及びタスクの付属物の対応付けの対象を「タスクモデル」とすること，すなわち，上記相違点１に係る構成とすることは，当業者が容易に想到し得たものである。
　
イ　相違点２について
　
（ア）上記引用文献２（上記Ｊ等の記載）には，データベース更新要求が成功した場合に，サーバからＸＭＬデータ（本願発明の「成功確認」に相当）を取得して，該ＸＭＬデータに基づいたＤＨＴＭＬ要素を生成してブラウザに出力させることが記載されている。
（イ）そして，引用発明及び引用文献２に記載された技術は，サーバに対して更新要求を送る点で共通の機能を有するものであるから，引用発明に上記引用文献２に記載された技術を適用し，Project Server からタスクへのリスクのリンクの変更保存の反映結果である「成功確認」を受信し，Project Web Access画面を更新するようすることは，当業者にとって格別な困難性を伴うものではない。
（ウ）してみると，引用発明のタスク管理において，タスクモデル更新要求の「成功確認」の受信によって，Project Web Access画面を更新するようにすること，すなわち，上記相違点２に係る構成とすることは，当業者が容易に想到し得たものである。
　
ウ　相違点３及び相違点４について
　
（ア）引用発明におけるメモは，タスクに対応付けられて何らかの記憶手段に記憶されるものであるところ，当該記憶手段として，リポジトリを採用することは周知技術（例えば，上記引用文献５の上記Ｎ等参照）といえ，また，記憶手段へのファイル等の記憶を，ファイル名や内容によりどのように排他処理するかは，必要により適宜決める設計的事項（例えば，同一のファイル名を有するデータの記憶がされないように処理することは，引用文献３の上記Ｋ等に記載され，また，同一ファイル名でもチェックサム値が異なる内容のデータは記憶するように処理することは，参考文献１の上記Ｐ及び参考文献２の上記Ｑ等に記載されている。）であり，引用発明におけるメモの記憶に関し，上記周知技術等を採用し，「同一の名称および異なるコンテンツを有する制作物が記憶され，同一の名称およびコンテンツを有する制作物が記憶されないように」「製作物リポジトリ内」に行うようにすることに，格別困難性は認められない。
（イ）また，上記「（１）相違点１について」で検討した如く，タスクに文書等を対応付けること，及び，「タスクモデル」として記述することはいずれも周知であるところ，付属物である上記メモについても当該周知の構成を採用することで，タスクモデルのＸＭＬにおける参照という形式により，対応付けられたメモに関する情報を記述することも，格別困難性を要せずに想到し得る程度のことであり，その場合，更新されたタスクに対し，対応するメモがタスクモデル内に記述されていないと判断されれば，メモをタスクモデル内に記述するよう更新要求を行って記述させることは必然的に行う事項であって，当業者であれば容易になし得ることである。
（ウ）してみると，引用発明のタスク管理において，「同一の名称および異なるコンテンツを有する制作物が記憶され，同一の名称およびコンテンツを有する製作物が記憶されないように」「製作物リポジトリ内」に行うとともに，「更新されたタスクモデルの付属物である製作物が前記タスクモデル内で参照を使用して記述されていないならば，前記タスク管理サーバに前記製作物を含む製作物更新要求を送信するステップ」及び「前記製作物更新要求の成功確認を受信すると，」同一の名称および異なるコンテンツを有する制作物が記憶され，同一の名称およびコンテンツを有する製作物が記憶されないように製作物リポジトリ内に記憶された「前記製作物への参照を前記タスクモデル内に記述するステップ」を有するようにすること，すなわち，上記相違点３及び相違点４に係る構成とすることは，当業者が容易に想到し得たものである。
 　 
エ　小括
　
　そして，本願発明の奏する作用効果は，上記引用発明及び上記周知技術の奏する作用効果から予測される範囲内のものにすぎず，格別顕著なものということはできない。
　
　したがって，本願発明は，上記引用発明及び上記周知技術に基づいて，当業者が容易に発明をすることができたものであり，特許法第２９条第２項の規定により，特許を受けることができない。
　
７　むすび
　
　上記４のとおり，平成２６年６月１６日付けの手続補正は，出願当初の明細書等に記載した範囲内でしたものではなく，特許法第１７条の２第３項に規定する要件を満たしていないから，本願は拒絶すべきものである。
　
　また，上記５のとおり，本願の請求項１ないし２１の記載は，特許法第３６条第６項第１号及び同法同条第４項第１号に規定する要件を満たしていないから，本願は拒絶すべきものである。
　
　さらに，上記６のとおり，本願の請求項１に係る発明は，特許法第２９条第２項の規定により特許を受けることができないものであるから，本願は拒絶すべきものである。
　
　よって，結論のとおり審決する。