• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 特許、登録しない(前置又は当審拒絶理由) G06F
審判 査定不服 特174条1項 特許、登録しない(前置又は当審拒絶理由) G06F
審判 査定不服 特36条6項1、2号及び3号 請求の範囲の記載不備 特許、登録しない(前置又は当審拒絶理由) G06F
審判 査定不服 特36条4項詳細な説明の記載不備 特許、登録しない(前置又は当審拒絶理由) G06F
管理番号 1302002
審判番号 不服2013-5816  
総通号数 188 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2015-08-28 
種別 拒絶査定不服の審決 
審判請求日 2013-04-01 
確定日 2015-06-09 
事件の表示 特願2008-182891「分散タスク処理」拒絶査定不服審判事件〔平成21年 3月12日出願公開、特開2009- 54142〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 1 手続の経緯

本件審判請求に係る出願(以下,「本願」という。)は,平成20年7月14日(パリ条約による優先権主張外国庁受理2007年7月31日(以下,「優先日」という。),米国)を出願日とする出願であって,平成21年4月17日付けで審査請求がなされ,平成24年2月6日付けで拒絶理由通知(同年2月14日発送)がなされ,同年4月5日付けで意見書が提出されるとともに,同日付けで手続補正がなされ,同年9月7日付けで最後の拒絶理由通知(同年9月18日発送)がなされ,これに対して,同年11月19日付けで意見書が提出されるとともに,同日付けで手続補正がなされたが,同年12月5日付けで前記平成24年11月19日付け手続補正を却下する旨の補正の却下の決定(同年12月11日発送)がなされるとともに,同日付けで拒絶査定(同年12月11日謄本送達)がなされたものである。
これに対して,「原査定を取り消す。本願は特許をすべきものである、との審決を求める。」ことを請求の趣旨として,平成25年4月1日付けで審判請求がなされるとともに,同日付けで手続補正がなされた。
そして,平成25年6月5日付けで審査官により特許法第164条第3項に定める報告(前置報告)がなされ,同年10月4日付けで当審により特許法第134条第4項の規定に基づく審尋(同年10月8日発送)がなされ,同年12月11日付けで回答書の提出がなされ,平成26年4月11日付けで当審により拒絶理由通知(同年4月14日発送)がなされ,同年6月16日付けで意見書が提出されるとともに,同日付けで手続補正がなされ,同年9月2日付けで当審により最後の拒絶理由通知(同年9月8日発送)がなされ,これに対して,同年12月3日付けで意見書が提出された。

2 平成26年9月2日付け拒絶理由通知書

上記平成26年9月2日付けで当審により通知した最後の拒絶理由は、以下のとおりである。

『 理 由

1.この出願の平成26年6月16日付けの手続補正は,出願当初の明細書等に記載した範囲内でしたものではないから,特許法第17条の2第3項に規定する要件を満たしていない。

2.この出願は,発明の詳細な説明及び特許請求の範囲の記載が下記の点で,特許法第36条第4項第1号,第6項第1号に規定する要件を満たしていない。

3.この出願の下記の請求項に係る発明は,その出願前日本国内又は外国において頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて,その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから,特許法第29条第2項の規定により特許を受けることができない。



(理由1)
請求項1,10,17の「同一の名称および異なるコンテンツを有する製作物が記憶され,同一の名称およびコンテンツを有する製作物が記憶されないように製作物リポジトリ内に記憶された前記製作物」との記載における,「同一の名称および異なるコンテンツを有する製作物が記憶され」るように「製作物リポジトリ内に記憶された前記製作物」との態様は,出願当初の明細書等には記載されていない。
すなわち,本願の出願当初の明細書等の段落【0016】に,
「【0016】
ある実施形態において,製作物の表現は,タスク構造と並列にソフトウェアによって管理可能である。並列の製作物のシステムは,典型的に,タスクモデル内に含まれる最低限の製作物の表現に基づいて,中央の製作物リポジトリから1つまたは複数のタスクモデルに,異なる製作物および同一の製作物の異なるバージョンを供給および対応付けることができる。」
との記載があり,当該記載によれば,“中央の製作物リポジトリに,同一及び異なるバージョンの製作物が,供給可能に記憶される”ことは読み取れるが,“同一”の“製作物”であることが,必ずしも「同一の名称」の「製作物」を意味せず,また,“異なるバージョンの製作物”であることが,必ずしも「異なるコンテンツを有する製作物」を意味しないことから,上記引用の本願の出願当初の明細書等の記載から,「同一の名称および異なるコンテンツを有する製作物が記憶され」るように「製作物リポジトリ内に記憶された前記製作物」との態様までは読み取れない。

よって,請求項1,10,17の「同一の名称および異なるコンテンツを有する製作物が記憶され,同一の名称およびコンテンツを有する製作物が記憶されないように製作物リポジトリ内に記憶された前記製作物」は,本願の出願当初の明細書等のすべての記載を総合することにより導かれる技術的事項との関係において,新たな技術的事項を導入しないものでない。

よって,平成26年6月16日付けの手続補正は,出願当初の明細書等に記載した範囲内でしたものではないから,特許法第17条の2第3項に規定する要件を満たしていない。


(理由2)
(1)請求項1,10,17の「同一の名称および異なるコンテンツを有する製作物が記憶され,同一の名称およびコンテンツを有する製作物が記憶されないように製作物リポジトリ内に記憶された前記製作物」との記載における,「同一の名称および異なるコンテンツを有する製作物が記憶され」るように「製作物リポジトリ内に記憶された前記製作物」との記載は,本願明細書の発明の詳細な説明のいずれの記載に対応するのか不明である。
(上記(理由1)で述べたように,本願の出願当初の明細書等の段落【0016】からは,同様の構成についての記載は,読み取れない。)
請求項1,10,17を引用する請求項2-9,11-16,18-21についても同様である。
(第36条第6項第1号)

(2)請求項1,10,17の「同一の名称および異なるコンテンツを有する製作物が記憶され,同一の名称およびコンテンツを有する製作物が記憶されないように製作物リポジトリ内に記憶された前記製作物」との記載における,「同一の名称および異なるコンテンツを有する製作物が記憶され」るように「製作物リポジトリ内に記憶された前記製作物」との構成に関し,本願明細書の発明の詳細な説明は,「製作物リポジトリ内に記憶された前記製作物」について「同一の名称および異なるコンテンツを有する製作物が記憶され」るようにすることで,具体的に,どのような従来技術の課題を,どのように解消し得るかについて,説明が明確かつ十分になされていない。(記憶する「制作物」を,「同一の名称および異なるコンテンツを有する」ものまで含むようにすることに,技術上格別な意義は見出せない。)
したがって,この出願の発明の詳細な説明は,当業者が請求項1,10,17に係る発明を実施することができる程度に明確かつ十分に記載されていないものであるとともに,請求項1,10,17に係る発明の技術上の意義を理解するために必要な事項が十分に記載されておらず,特許法第36条第4項第1号の経済産業省令で定めるところによる記載がされていないものである。(第36条第4項第1号(実施可能要件違反,委任省令要件違反))


(理由3)
請求項:1?21

[引用文献等一覧]
1.E-Trainer.jp,Microsoft Office Project 2003 オフィシャルマニュアル サーバー導入・管理編,日本,日経BPソフトプレス,2004年 6月21日,初版,pp.1-421
2.特開2007-11439号公報
3.特開2001-290692号公報
4.MORI, G.etc,“CTTE: Support for Developing and Analyzing Task Models for Interactive System Design”,米国,IEEE Transactions on Software Engineering, vol.28 No.8,2002年8月,p.797-813,[平成26年4月7日検索],インターネット<URL:http://hiis.isti.cnr.it/attachments/publications/2002-A0-45_0.pdf>
5.特開2006-260101号公報
6.特開平11-70714号公報

備考

(1)請求項1,10,17について
引用文献1の,特に,55頁下から6行?57頁末行,59頁1行?60頁3行及びコラム1つ目内の説明,125頁13行?16行,275頁5行?280頁1行,及び,281頁1行?282頁1行の記載,並びに,60頁,278頁,及び,280頁の図を踏まえると,引用文献1には,次の発明(以下,「引用発明」という。)が記載されているものと認められる。

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の画面においてユーザ自身のタスクの一覧を表示し,
ユーザがメモを添付するタスクを選択し,メモを作成してOKをクリックすると,タスクへメモが添付されたことを確認できるProject Web Accessの画面を表示する,
方法。

本願の請求項に記載された字句どおりのものとして,本願の請求項1に係る発明(以下,「本願発明」という)と引用発明とを対比すると,本願発明と引用発明とは,以下の点で一致し,また,以下の点で相違する。

(一致点)
タスク管理フロントエンドインタフェースを介してタスク情報更新要求を受信すると,前記タスク情報更新要求をタスク管理サーバに転送するステップと,
前記タスク管理サーバから前記タスク情報更新要求に対する応答を受信すると,前記タスク情報更新要求に対する応答において受信された少なくともいくつかのデータを使用して前記タスク管理フロントエンドインタフェースを更新するステップと,
を含み,
記憶された製作物は,1つまたは複数のタスク情報と対応付けされる方法。

(相違点1)
本願発明が,「タスクモデル」を更新要求の対象とし,また,製作物を付属物として対応付けているのに対して,引用発明は,「タスク」を更新要求やメモの対応付けの対象としているものの,「タスクモデル」という構成については言及していない点。

(相違点2)
タスク管理フロントエンドインタフェース更新のためのタスク管理サーバからの応答に関し,本願発明が,タスクモデル更新要求の「成功確認」であるとしているのに対して,引用発明は,タスクの更新要求に対し何らかの応答を受信しているものの「成功確認」であるとは特定していない点。

(相違点3)
製作物の記憶に関し,本願発明が,「同一の名称および異なるコンテンツを有する製作物が記憶され,同一の名称およびコンテンツを有する製作物が記憶されないように」「製作物リポジトリ内」に行うのに対して,引用発明は,メモの記憶方法及び記憶手段について具体的に特定していない点。

(相違点4)
本願発明が,「更新されたタスクモデルの付属物である製作物が前記タスクモデル内で参照を使用して記述されていないならば,前記タスク管理サーバに前記製作物を含む製作物更新要求を送信するステップ」及び,「前記製作物更新要求の成功確認を受信すると,」同一の名称および異なるコンテンツを有する製作物が記憶され,同一の名称およびコンテンツを有する製作物が記憶されないように製作物リポジトリ内に記憶された「前記製作物への参照を前記タスクモデル内に記述するステップ」を有しているのに対して,引用発明は,メモをタスクに対応付けて添付するよう要求を行っているものの,上記のような各ステップを有していない点。

以下で,上記相違点1ないし相違点4について検討する。

(相違点1)について
タスクに文書等の付属物を対応付けること,及び,当該タスクをモデル化してタスクに関する情報をXML等のフォーマットで記述することは,周知技術(例えば,引用文献4の特に800頁右欄1行?801頁左欄5行,805頁左欄下から19行?下から3行の記載の参照)であり,
引用発明のタスク管理において,上記周知技術を採用し,更新要求及びタスクの付属物の対応付けの対象を「タスクモデル」とすること,すなわち,相違点1に係る構成とすることは,当業者が容易に想到し得たものである。
よって,上記相違点1は格別なものではない。

(相違点2)について
引用文献2(特に段落【0051】?【0054】の記載)には,データベース更新要求が成功した場合に,サーバからXMLデータ(本願発明の「成功確認」に相当)を取得して,該XMLデータに基づいたDHTML要素を生成してブラウザに出力させることが記載されている。
引用発明,及び,引用文献2に記載された技術とは,サーバに対して更新要求を送る点で共通の機能を有するものであるから,引用発明に上記引用文献2に記載された技術を適用し,Project Server からタスクへのリスクのリンクの変更保存の反映結果である「成功確認」を受信し,Project Web Access画面を更新するよう構成することは,当業者にとって格別な困難性を要するものではない。
してみると,引用発明のタスク管理において,タスクモデル更新要求の「成功確認」の受信によって,Project Web Access画面を更新するようにすること,すなわち,相違点2に係る構成とすることは,当業者が容易に想到し得たものである。
よって,上記相違点2は格別なものではない。

(相違点3)及び(相違点4)について
引用発明におけるメモは,タスクに対応付けられて何らかの記憶手段に記憶されるものであるところ,当該記憶手段として,リポジトリを採用することは周知技術(例えば,引用文献5の特に【要約】の記載を参照)といえ,また,記憶手段へのファイル等の記憶を,ファイル名や内容によりどのように排他処理するかは,必要により適宜決める設計的事項(例えば,同一のファイル名を有するデータの記憶がされないように処理することは,引用文献3の段落【0040】?【0046】に,また,同一ファイル名でも異なる内容のデータの記憶は行われるように処理することは,引用文献6の段落【0035】,【0039】に,それぞれ記載されている。)であり,引用発明におけるメモの記憶に関し,上記周知技術等を採用し,「同一の名称および異なるコンテンツを有する製作物が記憶され,同一の名称およびコンテンツを有する製作物が記憶されないように」「製作物リポジトリ内」に行うようにすることに,格別困難性は認められない。
また,上記「(相違点1)について」で検討した如く,タスクに文書等を対応付けること,及び,「タスクモデル」として記述することはいずれも周知であるところ,付属物である上記メモについても当該周知の構成を採用することで,タスクモデルのXMLにおける参照という形式により,対応付けられたメモに関する情報を記述することも,格別困難性を要せずに想到し得る程度のことであり,その場合,更新されたタスクに対し,対応するメモがタスクモデル内に記述されていないと判断されれば,メモをタスクモデル内に記述するよう更新要求を行って記述させることは必然的に行う事項であって,当業者であれば容易になし得ることである。
してみると,引用発明のタスク管理において,「同一の名称および異なるコンテンツを有する製作物が記憶され,同一の名称およびコンテンツを有する製作物が記憶されないように」「製作物リポジトリ内」に行うとともに,「更新されたタスクモデルの付属物である製作物が前記タスクモデル内で参照を使用して記述されていないならば,前記タスク管理サーバに前記製作物を含む製作物更新要求を送信するステップ」及び,「前記製作物更新要求の成功確認を受信すると,」同一の名称および異なるコンテンツを有する製作物が記憶され,同一の名称およびコンテンツを有する製作物が記憶されないように製作物リポジトリ内に記憶された「前記製作物への参照を前記タスクモデル内に記述するステップ」を有するようにすること,すなわち,相違点3及び4に係る構成とすることは,当業者が容易に想到し得たものである。
よって,上記相違点3及び4は格別なものではない。

そして,本願発明の奏する作用効果は,引用発明,引用文献2に記載の事項,及び,周知技術等の奏する作用効果から予測される範囲内のものにすぎず,格別顕著なものということはできない。
したがって,本願発明は,引用発明,引用文献2に記載の事項,及び,上記周知技術等から,当業者が容易に発明をすることができたものである。

(2)請求項2?21について
請求項2?21に係る発明についても,ウェブサービス,ローカルキャッシュ,サブタスク,インターフェース等の周知の構成について限定したものであり,格別な構成はなく,引用発明,引用文献2に記載の事項,及び,上記周知技術等から,当業者が容易に想到し得たことである。』

3 平成26年12月3日付け意見書の概要

上記平成26年12月3日付けで提出された意見書の概要は、以下のとおりである。
(当審注:下線は,参考のために当審で附加したものである。)

『1.理由1(新規事項)について
理由1では、本願の平成26年6月16日付けの手続補正は特許法第17条の2第3項に規定する要件を満たしていない、と認定されています。『「同一の名称および異なるコンテンツを有する製作物が記憶され」るように「製作物リポジトリ内に記憶された前記製作物」との態様は,出願当初の明細書等には記載されていない。』というご指摘に対し、以下に意見を申し述べます。

製作物を製作物リポジトリ内に保存する処理に関して、段落0060には、「アプリケーションは含まれる製作物オブジェクトの参照を利用して、物理的な付属物がタスクオブジェクト内で製作物の参照を使用して既に記述されているかどうか検査する(510)。
・・・付属物が適切な製作物オブジェクトの参照を通してタスクオブジェクト内で表現されていないならば、製作物ウェブサービスクライアントは、適切な付属物の全てのコンテンツ(バイト)を含みうる製作物更新要求を生成(512)および送信(514)する。」と記載され、
段落0061には、「サーバ上で要求が解析され(516)、受信したコンテンツについてチェックサムを作成する(518)。そして、製作物がサーバ上に既に存在するかどうか確認するために、サーバ上の既存の製作物が検査される(520)。製作物が存在しないならば、製作物は製作物リポジトリ内に保存される(524)。製作物が存在するならば、記憶されているデータソースから製作物が取得される(526)。」と記載されています。
そして、製作物リポジトリにおける製作物の管理に関して、段落0046には、「製作物ウェブサービス132は、典型的に、タスク管理バックエンドアプリケーション128内で製作物の管理の責任を負う。製作物の管理は、典型的に、クライアントから供給される製作物のコンテンツを製作物リポジトリ138内に記憶し、必要に応じて、製作物のコンテンツおよび情報を製作物クライアント120に供給することを含む。それによって、製作物ウェブサービス132は、製作物の名称および製作物のコンテンツのチェックサム、例えば、製作物のコンテンツをユニークに識別するCRC32チェックサムに応じて、異なる製作物のバージョンを識別し、クライアントに供給する。」と記載されています。
この記載から、一例として、製作物リポジトリにおける製作物を特定するために、「製作物の名称」と、製作物のコンテンツをユニークに識別する「製作物のコンテンツのチェックサム」が使用されることが読み取れます。
そして、段落0020の「製作物は、典型的に、サーバ上の製作物リポジトリ内に記憶され、それによって、同一の名称を有する各々の利用可能な製作物は、既に存在する製作物について重複して生成されないように、チェックサムにより明示的に検査される。」という記載によれば、製作物が製作物リポジトリ内に記憶された結果として、同一の名称を有する製作物が既に存在する製作物と重複して生成されないように、チェックサムにより検査されます。チェックサムが検査されること、一例としてチェックサムは製作物のコンテンツをユニークに識別することを考慮すると、チェックサムの検査は、既に存在する製作物のコンテンツと、同一の名称を有する製作物のコンテンツとが重複するかどうかを検査するものです。従って、この検査の結果、既に存在する製作物のコンテンツと、同一の名称を有する製作物のコンテンツとが重複する場合、この同一の名称を有する製作物は記憶されません。従って、重複しなければ記憶されると考えられます。

従って、「同一の名称および異なるコンテンツを有する製作物が記憶され」るように「製作物リポジトリ内に記憶された前記製作物」との態様は、出願当初の明細書に記載されていると思料致します。


2.理由2(記載不備)について
理由2では、本願は発明の詳細な説明及び特許請求の範囲の記載が特許法第36条第4項第1号,第6項第1号に規定する要件を満たしていない、と認定されています。ご指摘の(1)、(2)に対し、以下に意見を申し述べます。

(1)『請求項1,10,17の・・・「同一の名称および異なるコンテンツを有する製作物が記憶され」るように「製作物リポジトリ内に記憶された前記製作物」との記載は,本願明細書の発明の詳細な説明のいずれの記載に対応するのか不明である。』というご指摘については、理由1に関して説明致しました通りです。

(2)『本願明細書の発明の詳細な説明は,「製作物リポジトリ内に記憶された前記製作物」について「同一の名称および異なるコンテンツを有する製作物が記憶され」るようにすることで,具体的に,どのような従来技術の課題を,どのように解消し得るかについて,説明が明確かつ十分になされていない。』というご指摘については次の通りです。
従来技術の課題について、段落0002には、「組織の内部プロセスは、一般的に、タスクまたはプロジェクト管理ソフトウェアを使用して追跡される。そのようなソフトウェアはプロジェクトおよびタスクのモデル化を可能とする。これらのモデルは典型的に静的である。しかし、多くの組織内の運用は、予測できない形態で変化しうる、緩く定義された、または、動的なプロセスを利用する。」と記載され、段落0004には、「プロジェクトファイルの複数の実例が存在するので、プロジェクトファイルは、複数回、複製されなければならない。結果として、プロジェクトのためのファイルは、非常に大きくなりうる。」と記載されています。すなわち、組織内でのタスクまたはプロジェクト管理ソフトウェアの運用において、複製によりプロジェクトのためのファイルが非常に大きくなり得
ます。
本願発明は、「同一の名称および異なるコンテンツを有する製作物が記憶され、同一の名称およびコンテンツを有する製作物が記憶されないように製作物リポジトリ内に記憶された前記製作物」という構成を有し、この構成により、段落0030に「製作物のコンテンツは、複製のコンテンツを有する製作物の生成を防止するために役立つようにチェックサムに基づいて検査される。」と記載されていますように、複製のコンテンツを有する製作物の生成を防止します。
一方、同一の名称および異なるコンテンツを有する製作物が記憶されますので、段落0010に「ここでの各種の実施形態は、進行中の組織運営への阻害または悪影響なしにタスクが定義および修正されうるメカニズムを提供する。・・・そのような修正は、定義されたタスクのプロセス、または、タスク定義を伴う文書のような製作物に行われうる。」と記載されていますように、同一の名称の製作物を修正しても他の組織のタスクまたはプロジェクト管理に影響を与えません。


3.理由3(進歩性欠如)について
理由3では、本願発明は特許法第29条第2項の規定により特許を受けることができない、と認定されています。
拒絶理由通知書の「(相違点3)及び(相違点4)について」の7行目以降の「同一ファイル名でも異なる内容のデータの記憶は行われるように処理することは,引用文献6の段落[0035],[0039]に,それぞれ記載されている。」というご指摘について意見を申し述べます。

引用文献6(特開平11-70714号公報)の段落0035には、「本発明では、このように書式情報ファイル管理テーブル3を持つことにより、任意の場所に書式情報ファイルを作成しても、文書ファイル印刷手段4は、その作成場所を認識することが可能となる。その結果として、同一名称の書式を別々の書式情報ファイルに格納しておき、用途に応じて印刷形態を変更することが可能となり、印刷業務の汎用性を拡大することができる。」と記載されています。この段落中に「同一名称の書式を別々の書式情報ファイルに格納しておき、」、段落0039に「同一名称であり、かつ定義内容の異なる書式を別々の書式情報ファイルに格納し、用途に応じて使い分けることができる」、段落0010に「書式情報ファイルa,b,nから成る書式情報ファイル群2の作成を行う書式情報ファイル作成手段1と、書式情報ファイルa,b,nの管理情報を格納する書式情報ファイル管理テーブル3と、」と記載されていることと、ファイル名が同一でもよいなど特に言及がないことから、書式情報ファイルは互いに異なる名称で区別されていると考えられます。
すなわち、引用文献6では、書式の名称は同一であり、書式の定義内容は異なり、書式が格納される書式情報ファイルは互いに異なる名称で区別されていると考えられます。これは、「同一ファイル名でも異なる内容のデータの記憶は行われる」こととは異なります。

従って、本願発明の「同一の名称および異なるコンテンツを有する製作物が記憶され、同一の名称およびコンテンツを有する製作物が記憶されないように製作物リポジトリ内に記憶された前記製作物」という構成は引用文献に記載も示唆もされていませんので、本願発明は進歩性を有すると思料致します。
・・・(後略)』

4 当審による拒絶理由通知書の理由1(新規事項)について

ア 請求項1,10,17の「同一の名称および異なるコンテンツを有する製作物が記憶され,同一の名称およびコンテンツを有する製作物が記憶されないように製作物リポジトリ内に記憶された前記製作物」との記載における,「同一の名称および異なるコンテンツを有する製作物が記憶され」るように「製作物リポジトリ内に記憶された前記製作物」との態様は,出願当初の明細書等には記載されていない。

イ すなわち,本願の出願当初の明細書等の段落【0016】に,
「【0016】
ある実施形態において、製作物の表現は、タスク構造と並列にソフトウェアによって管理可能である。並列の製作物のシステムは、典型的に、タスクモデル内に含まれる最低限の製作物の表現に基づいて、中央の製作物リポジトリから1つまたは複数のタスクモデルに、異なる製作物および同一の製作物の異なるバージョンを供給および対応付けることができる。」
との記載があり,当該記載によれば,“中央の製作物リポジトリに,異なる製作物および同一の製作物の異なるバージョンが,供給可能に記憶される”ことは読み取れるが,“異なる製作物および同一の製作物の異なるバージョン”が,「同一の名称および異なるコンテンツを有する製作物」を意味することまでは読み取れない。

ウ そして,本願の出願当初の明細書等の他の記載を参酌しても,請求項1,10,17に記載されている「同一の名称および異なるコンテンツを有する製作物が記憶され」るように「製作物リポジトリ内に記憶された前記製作物」は,読み取れない。

エ なお,請求人は,上記平成26年12月3日付け意見書において,
「同一の名称を有する製作物が既に存在する製作物と重複して生成されないように、チェックサムにより検査されます。・・・この検査の結果、既に存在する製作物のコンテンツと、同一の名称を有する製作物のコンテンツとが重複する場合、この同一の名称を有する製作物は記憶されません。従って、重複しなければ記憶されると考えられます。」
と主張している。

オ しかしながら,特開2005-216240号公報(下記参考文献1)の段落【0059】?【0068】(特に,段落【0066】及び【0067】のステップ174を参照)に記載されるように,同一ファイル名を有し,チェックサムを比較した結果,重複しない場合であっても,当該データが登録されない場合もあることから,請求人の上記主張(すなわち,「検査の結果、既に存在する製作物のコンテンツと、同一の名称を有する製作物のコンテンツとが・・・重複しなければ記憶されると考えられます」という主張)は採用することができない。

カ したがって,請求項1,10,17の「同一の名称および異なるコンテンツを有する製作物が記憶され,同一の名称およびコンテンツを有する製作物が記憶されないように製作物リポジトリ内に記憶された前記製作物」は,本願の出願当初の明細書等のすべての記載を総合することにより導かれる技術的事項との関係において,新たな技術的事項を導入しないものでない。

キ よって,上記平成26年6月16日付けの手続補正は,出願当初の明細書等に記載した範囲内でしたものではないから,特許法第17条の2第3項に規定する要件を満たしていない。

5 当審による拒絶理由通知書の理由2(記載不備)について

(1)理由2(1)について

ア 上記「4 当審による拒絶理由通知書の理由1(新規事項)について」で述べたように,請求項1,10,17の「同一の名称および異なるコンテンツを有する製作物が記憶され,同一の名称およびコンテンツを有する製作物が記憶されないように製作物リポジトリ内に記憶された前記製作物」との記載における「同一の名称および異なるコンテンツを有する製作物が記憶され」るように「製作物リポジトリ内に記憶された前記製作物」との記載は,本願明細書の発明の詳細な説明のいずれの記載に対応するのか不明である。

イ したがって,請求項1,10,17,及び,これらの請求項を引用する請求項2ないし9,請求項11ないし16,請求項18ないし21における「同一の名称および異なるコンテンツを有する製作物が記憶され」るように「製作物リポジトリ内に記憶された前記製作物」との記載は,本願明細書の発明の詳細な説明のいずれの記載に対応するのか不明であるから,本願の請求項1ないし21の記載は,特許法第36条第6項第1号に規定する要件を満たしていない。

(2)理由2(2)について

ア 請求項1,10,17の「同一の名称および異なるコンテンツを有する製作物が記憶され,同一の名称およびコンテンツを有する製作物が記憶されないように製作物リポジトリ内に記憶された前記製作物」との記載における,「同一の名称および異なるコンテンツを有する製作物が記憶され」るように「製作物リポジトリ内に記憶された前記製作物」との構成に関し,本願明細書の発明の詳細な説明は,「製作物リポジトリ内に記憶された前記製作物」について「同一の名称および異なるコンテンツを有する製作物が記憶され」るようにすることで,具体的に,どのような従来技術の課題を,どのように解消し得るかについて,説明が明確かつ十分になされていない。(記憶する「制作物」を,「同一の名称および異なるコンテンツを有する」ものまで含むようにすることに,技術上格別な意義は見出せない。)

イ したがって,この出願の発明の詳細な説明は,当業者が請求項1,10,17に係る発明を実施することができる程度に明確かつ十分に記載されていないものであるとともに,請求項1,10,17に係る発明の技術上の意義を理解するために必要な事項が十分に記載されておらず,特許法第36条第4項第1号に規定する要件を満たしていない。

(3)出願人の主張について

ア なお,請求人は,上記平成26年12月3日付け意見書において,
「『請求項1,10,17の・・・「同一の名称および異なるコンテンツを有する製作物が記憶され」るように「製作物リポジトリ内に記憶された前記製作物」との記載は,本願明細書の発明の詳細な説明のいずれの記載に対応するのか不明である。』というご指摘については、理由1に関して説明致しました通りです。」,
「同一の名称および異なるコンテンツを有する製作物が記憶されますので、段落0010に「ここでの各種の実施形態は、進行中の組織運営への阻害または悪影響なしにタスクが定義および修正されうるメカニズムを提供する。・・・そのような修正は、定義されたタスクのプロセス、または、タスク定義を伴う文書のような製作物に行われうる。」と記載されていますように、同一の名称の製作物を修正しても他の組織のタスクまたはプロジェクト管理に影響を与えません。」
と主張している。

イ しかしながら,上記したように,本願の出願当初の明細書等から,「同一の名称および異なるコンテンツを有する製作物が記憶され」る態様を読み取ることはできないことから,請求人の当該主張についても,採用することはできない。

6 本願発明の進歩性について

以上のように,本願の特許請求の範囲の請求項1に係る発明(以下,「本願発明」という。)は,上記「4 当審による拒絶理由通知書の理由1(新規事項)について」で述べたように,新規事項を含むものであり,また,上記「5 当審による拒絶理由通知書の理由2(記載不備)について」で述べたように,記載不備を含むものであるが,仮に,本願発明が,字句通りのものであるとして,その進歩性について検討する。

(1)本願発明

本願発明は,上記平成26年6月16日付け手続補正書により補正された明細書及び特許請求の範囲の記載からみて,その特許請求の範囲の請求項1に記載された以下のとおりのものと認める。

「タスク管理フロントエンドインタフェースを介してタスクモデル更新要求を受信すると、前記タスクモデル更新要求をタスク管理サーバに転送するステップと、
前記タスク管理サーバから前記タスクモデル更新要求の成功確認を受信すると、前記タスクモデル更新要求の成功確認において受信された少なくともいくつかのデータを使用して前記タスク管理フロントエンドインタフェースを更新するステップと、
更新されたタスクモデルの付属物である製作物が前記タスクモデル内で参照を使用して記述されていないならば、前記タスク管理サーバに前記製作物を含む製作物更新要求を送信するステップと、
前記製作物更新要求の成功確認を受信すると、同一の名称および異なるコンテンツを有する製作物が記憶され、同一の名称およびコンテンツを有する製作物が記憶されないように製作物リポジトリ内に記憶された前記製作物への参照を前記タスクモデル内に記述するステップと、
を含み、
前記製作物リポジトリ内に記憶された製作物は、1つまたは複数のタスクモデルと対応付けされる方法。」

(2)引用文献

(2-1)引用文献1

ア 本願の優先日前に頒布され,原審の拒絶の査定の理由である上記平成24年9月7日付けの拒絶理由通知において引用された文献である,『E-Trainer.jp,“Microsoft Office Project 2003 オフィシャルマニュアル サーバー導入・管理編”,日本,日経BPソフトプレス,2004年6月21日,初版,pp.55-64, 125-126, 275-282』(以下,「引用文献1」という。)には,図面とともに,以下の技術的事項が記載されている。
(当審注:下線は,参考のために当審で附加したものである。)

A 「Project Server 2003では、Outlookを使用中のユーザーからの要望により、次のような機能が追加されました。

●Projectで割り当てられたタスクがOutlookの予定表にインポートされる。
●割り当てられたタスクへの実績報告をOutlookからも実施できる。
●ProjectのタスクのインポートやProject Serverへの更新の送信をスケジュールでの自動実行によって行える。

Outlookとの連携機能の設定

Project ServerとOutlookとの連携を行うには、Outlook用のProject Web AccessアドインをProject Serverからあらかじめダウンロードして設定しておく必要があります。

▲Outlookとの連携機能を設定する
○1:Outlookを起動し、クライアントコンピュータでOutlookが使用可能な状態に設定されていることを確認する。
○2:Outlookを閉じる。
○3:Project Web AccessからProject Serverに接続する。
○4:[タスク]メニューをクリックする。
○5:[自分のタスクの表示]ページの[アクション]から[Outlookの予定表からタスクを表示して進捗をレポート]をクリックする。
○6:[Outlook機能の使用]ページの[今すぐダウンロード]をクリックする。
○7:確認のメッセージが表示されるので、[はい]をクリックする。
○8:[ファイルのダウンロード]ダイアログボックスの[開く]をクリックする。
○9:[Outlook用のMicrosoft Office Projectアドインセットアップ]ダイアログボックスの[インストール]をクリックする。
○10:確認のメッセージが表示されるので、[OK]をクリックする。
○11:Outlookを起動する。」(55頁下から6行?57頁末行)
(当審注:上記記載について,便宜上,横▲記号の表記を「▲」に,丸数字の表記を「○数字:」に替えて示している。以下同じ。)

B 「Project Serverとの接続設定

OutlookからProject Serverに接続するための設定を行います。この接続設定に従ってOutlookは、Project Serverにログインして割り当て情報を取得したり、タスクの実績を報告したりします。

▲Project Serverとの接続設定を行う
○1:Outlookを起動する。
○2:[ツール]-[オプション]をクリックする。
○3:[オプション]ダイアログボックスの[Project Web Access]タブをクリックし、[ログイン情報の入力]をクリックする。
○4:[ログイン情報の入力]ダイアログボックスの[Project ServerのURL]ボックスに接続するProject ServerのURLを入力し、[Windowsユーザーアカウントを使用する]オプションボタンを選択して、[OK]をクリックする。
○5:[オプション]ダイアログボックスに戻るので、[OK]をクリックする。○6:Project Serverとの接続設定が行われたことを確認する。

なお、接続時に使用するユーザーがProject Server認証の場合には、[ログイン情報の入力]ダイアログボックスの[Project Serverアカウントを使用する]オプションボタンを選択し、[ユーザー名]ボックスにユーザー名を入力します。」(59頁1行?60頁3行)

C 「Outlookからの実績報告
Outlookから割り当てられたタスクの実績報告を行うことができます。
・・・(中略)・・・
▲プロジェクト管理者への実績を報告する
○1:Outlookを起動する。
○2:[ツール]-[Project Web Access]-[Project Web Accessホームページ]をクリックする。
○3:Project Web Accessの[ホーム]ページが表示される。
○4:[タスク]メニューの[すべて更新]または[選択した行の更新]をクリックし、プロジェクト管理者に実績を報告する。」(62頁下から4行?64頁7行)

D 「4.1 Project Web Accessの使用

「Project Web Access」はプロジェクトメンバーが、Project Serverに発行されたプロジェクト情報を参照したり、進捗を報告したりする場合に使用するツールの1つです。」(125頁13行?16行)

E 「5.6 役割別の作業:メンバー

ここでは、メンバーが行う作業について説明します。
メンバーは、自分が割り当てられたタスクを実施し、プロジェクト管理者に定期的にタスクの実績を報告する必要があります。そのため、Project Web Accessを使用して割り当てられたタスクの実績報告を行います。また、自分が割り当てられたタスクに関する進捗だけでなく、関連するリスク、懸案事項、ドキュメントなどを登録することも主な作業になります。
・・・(中略)・・・
タスクへのリスク、懸案事項、ドキュメントのリンク

Project Web Accessを使用して、リスク、懸案事項、ドキュメントを既にProject Serverに登録されているタスクにリンクしたり、新たにProject Serverに登録しながらタスクにリンクしたりすることができます。ここでは、タスクを既に登録されているリスクにリンクさせる方法について説明します。

▲タスクへリスクをリンクする
○1:Project Web Accessにログインする。
○2:[タスク]メニューをクリックする。
○3:[自分のタスクの表示]ページの一覧からリスクをリンクするタスクを選択し、[リスクのリンク]をクリックする。
○4:[タスク審査委員会の招集(理念の追求/中止の決定)にプロジェクトリスクをリンク]ページの[プロジェクトリスクのリンク]をクリックする。
○5:プロジェクトのリスクとして登録されているリスクが一覧表示されるので、リスクをリンクするタスクのチェックボックスをオンにし、[変更の保存]をクリックする。
○6:[“自分のタスク”に戻る]をクリックする。
○7:タスクへリスクがリンクされたことを確認する。」(275頁5行?280頁1行)

F 上記Eの記載に関連して,上記○3:時点でタスクへリスクがリンクされる前の[自分のタスクの表示]ページ画面例,及び,上記○7:時点でタスクへリスクがリンクされた後の[自分のタスクの表示]ページ画面例が,それぞれ,278頁及び280頁に示されている。

G 「タスクへのメモの添付
メンバーは、タイムシートビューを使用して割り当てられたタスクの実績報告をプロジェクト管理者に行います。しかし、タイムシートビューだけでは、タスクの詳細状況を伝えることができない場合があります。そのようなときには、タスクに「メモ」を添付することで対応します。詳細状況を説明したメモをタスクに添付することで、実績情報だけでは伝わらない内容をプロジェクト管理者に報告することができます。ここでは、タイムシートビューでタスクにメモを添付する方法について説明します。

▲タスクへメモを添付する
○1:Project Web Accessにログインする。
○2:[タスク]メニューをクリックする。
○3:[自分のタスクの表示]ページの一覧からメモを添付するタスクを選択し、[メモの挿入]をクリックする。
○4:[Project Web Access割り当てメモ--Webページダイアログ]ダイアログボックスの一覧に添付するメモの内容を入力し、[OK]をクリックする。
○5:タスクへメモが添付されたことを確認する。」(281頁1行?282頁1行)

H 上記Gの記載に関連して,上記○3:時点でタスクへメモが添付される前の[自分のタスクの表示]ページ画面例,及び,上記○5:時点でタスクへメモが添付された後の[自分のタスクの表示]ページ画面例が,それぞれ,281頁及び282頁に示されている。

イ ここで,上記引用文献1に記載されている事項を検討する。

(ア)引用文献1は“Project Serverの管理及び運用方法”について説明する文献であり,その内,上記Eは,ユーザがProject Web Accessを使用して,Project Serverに登録されているタスクに対しリスクをリンクする方法について,また,上記Gは,同じくユーザがProject Web Accessを使用して,Project Serverに登録されているタスクに対しメモを添付する方法について説明している。

(イ)上記Bの「OutlookからProject Serverに接続する・・・Outlookは、Project Serverにログインして割り当て情報を取得したり、タスクの実績を報告したりします」との記載,上記C及びDの記載によれば,引用文献1の「Project Server」が,タスクを管理するサーバを構成するものであることは明らかであり,
また,上記Aの「Project ServerとOutlookとの連携を行うには、Outlook用のProject Web AccessアドインをProject Serverからあらかじめダウンロードして設定しておく必要があります」及びBの「OutlookからProject Serverに接続する」との記載によれば,引用発明の「Project Server」と「Project Web Access」とは,連携可能に接続されていることがよみとれることから,引用文献1には,
“タスクを管理するサーバを構成するProject ServerとProject Web Accessとが連携可能に接続され”ること
が説明されていると言える。

(ウ)上記Eの「ここでは、メンバーが行う作業について説明します」,「Project Web Accessを使用して、リスク・・・を既にProject Serverに登録されているタスクにリンク・・・することができます」,「○1:Project Web Accessにログインする」,「○3:[自分のタスクの表示]ページの一覧からリスクをリンクするタスクを選択し、[リスクのリンク]をクリックする」,「○5:プロジェクトのリスクとして登録されているリスクが一覧表示されるので、リスクをリンクするタスクのチェックボックスをオンにし、[変更の保存]をクリックする」,「○6:[“自分のタスク”に戻る]をクリックする」,「○7:タスクへリスクがリンクされたことを確認する」との記載から,引用文献1には,
“Project Web Accessから,Project Serverに登録されているタスクに対しリスクをリンクする際に,
ログインしたProject Web Accessにおいてユーザ自身のタスクの一覧を表示し,
ユーザがリスクをリンクするタスクを選択し,一覧表示されるリスクのうちリンクするリスクを選択して変更を保存すると,タスクへリスクがリンクされたことを確認できる”こと
が説明されていると言える。
そして,上記“Project Web Accessにおいてユーザ自身のタスクの一覧を表示し”た状態,及び,上記“タスクへリスクがリンクされたことを確認できる”状態は,上記Fで説明したように,Project Web Accessの画面を表示している状態である。
してみると,引用文献1には,
“Project Web Accessから,Project Serverに登録されているタスクに対しリスクをリンクする際に,
ログインしたProject Web Accessの画面においてユーザ自身のタスクの一覧を表示し,
ユーザがリスクをリンクするタスクを選択し,一覧表示されるリスクのうちリンクするリスクを選択して変更を保存すると,タスクへリスクがリンクされたことを確認できるProject Web Accessの画面を表示する”こと
が説明されていると言える。

(エ)上記Gの「タスクへのメモの添付」,「詳細状況を説明したメモをタスクに添付することで、実績情報だけでは伝わらない内容をプロジェクト管理者に報告することができます」,「○1:Project Web Accessにログインする」,「○3:[自分のタスクの表示]ページの一覧からメモを添付するタスクを選択し、[メモの挿入]をクリックする」,「○4:[Project Web Access割り当てメモ--Webページダイアログ]ダイアログボックスの一覧に添付するメモの内容を入力し、[OK]をクリックする」,「○5:タスクへメモが添付されたことを確認する」との記載から,引用文献1には,
“Project Web Accessから,Project Serverに登録されているタスクに対しメモを添付する際に,
ログインしたProject Web Accessにおいてユーザ自身のタスクの一覧を表示し,
ユーザがメモを添付するタスクを選択し,メモを作成してOKをクリックすると,タスクへメモが添付されたことを確認できる”こと
が説明されていると言える。
そして,上記“Project Web Accessにおいてユーザ自身のタスクの一覧を表示し”た状態,及び,上記“タスクへメモが添付されたことを確認できる”状態は,上記Hに示されるようにProject Web Accessの画面を表示している状態である。
してみると,引用文献1には,
“Project Web Accessから,Project Serverに登録されているタスクに対しメモを添付する際に,
ログインしたProject Web Accessの画面においてユーザ自身のタスクの一覧を表示し,
ユーザがメモを添付するタスクを選択し,メモを作成してOKをクリックすると,タスクへメモが添付されたことを確認できるProject Web Accessの画面を表示する”こと
が説明されていると言える。

ウ 以上,(ア)ないし(エ)で指摘した事項を踏まえると,引用文献1には,次の発明(以下,「引用発明」という。)が記載されているものと認められる。

「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の画面においてユーザ自身のタスクの一覧を表示し,
ユーザがメモを添付するタスクを選択し,メモを作成してOKをクリックすると,タスクへメモが添付されたことを確認できるProject Web Accessの画面を表示する,
方法。」

(2-2)引用文献2

本願の優先日前に頒布され,原審の拒絶の査定の理由である上記平成24年9月7日付けの拒絶理由通知において引用された刊行物である,特開2007-11439号公報(平成19年1月18日出願公開。以下,「引用文献2」という。)には,図面とともに,以下の技術的事項が記載されている。
(当審注:下線は,参考のために当審で附加したものである。)

J 「【0051】
図8は、データ更新処理の内容を示すフローチャートである。サブウィンドゥにデータが表示された後、例えばユーザが「品目名称」テキストボックスに表示されている「釘」という内容を「机」へ変更してからツールバーの「保存」ボタンを押すと、S50においては、表示エンジンがデータ更新要求を受け付ける。S51においては、サブウィンドゥ定義情報に含まれるデータセット定義情報に基づき、更新データをXMLに変換する。
・・・(中略)・・・
【0054】
そして、データベースの更新処理が成功した場合、サーバ11から「在庫品目サブウィンドゥ」と「品番:001、名称:机」という情報を含むXMLデータが端末へ返送されてくる。S53においては、表示エンジンがこのXML更新済みデータ情報を取得する。S54においては、対応するDHTML要がを生成され、S55においては、完成したDHTML要素がブラウザに出力される。」

(2-3)引用文献3

本願の優先日前に頒布され,上記平成25年10月4日付けの審尋で援用した上記平成25年6月5日付けの前置報告において引用された刊行物である,特開2001-290692号公報(平成13年10月19日出願公開。以下,「引用文献3」という。)には,図面とともに,以下の技術的事項が記載されている。
(当審注:下線は,参考のために当審で附加したものである。)

K 「【0040】図2は、図1に示すFTPサーバのアップロード処理を説明するためのフローチャートである。
【0041】ユーザ端末4aからアップロードするファイルおよびそのファイル名がFTPサーバ1へ送信されると、図2に示すように、ステップS1において、FTPサーバ1のファイル管理部12は、通信制御部14を介してアップロードされたファイルおよびそのファイル名を受信する。
【0042】次に、ファイル管理部12は、アップロードされたファイルのファイル名がファイル格納メモリ13にすでに記憶されているファイルのファイル名と同一であるか否かを判断し、同一でない場合はステップS3へ移行し、同一である場合はステップS5へ移行する。
【0043】アップロードされたファイルのファイル名が同一でない場合、ステップS3において、ファイル管理部12は、受信したファイルおよびそのファイル名をファイル格納メモリ13に格納する。次に、ステップS4において、ファイル管理部12は、通信制御部14を介してアップロードが完了した旨を通知するためのデータを送信する。
・・・(中略)・・・
【0045】一方、ステップS2において、同一のファイル名があると判断された場合、ステップS5において、ファイル管理部12は、通信制御部14を介してファイル名が重複している旨を通知するためのデータを送信する。
【0046】送信されたデータはインターネット2およびプロバイダサーバ3aを介してユーザ端末4aに受信され、ユーザ端末4aでは、FTPクライアントソフトによりファイル名が重複していることをユーザに通知する。ファイル名が重複していることがわかったユーザは、ファイル名を変更して再度ファイルおよび変更したファイル名を送信する。」

(2-4)引用文献4

本願の優先日前に頒布され,上記平成26年4月11日付けの当審による拒絶理由通知において引用された文献である,『MORI, G.etc,“CTTE: Support for Developing and Analyzing Task Models for Interactive System Design”,米国,IEEE Transactions on Software Engineering, vol.28 No.8,2002年8月,p.797-813,[平成26年4月7日検索],インターネット<URL:http://hiis.isti.cnr.it/attachments/publications/2002-A0-45_0.pdf>』(以下,「引用文献4」という。)には,図面とともに,以下の技術的事項が記載されている。
(当審注:下線は,参考のために当審で附加したものである。)

L 「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. This sort of aspect is usually implicit, expressed informally in the output of task analysis. Making the analyst use these operators is a substantial change to normal practice. The reason for this innovation is that, after an informal task analysis, we want designers to clearly express the logical temporal relationships. This is because such ordering should be taken into account in the user interface implementation to allow the user to perform, at any time,the tasks that should be enabled from a semantic point of view.」(800頁右欄1行?801頁左欄5行)
(当審訳:3 タスクモデルの表現方法
・・・ (中略)・・・
ConcurTaskTreesの主な機能は次のとおりである:
・・・ (中略)・・・
・同時記録。タスク間の可能な時間的関係の豊富なセットを定義することができる。この種の見地は通常,暗黙的であり,タスク分析の出力において略式に表現される。アナリストにこれらのオペレータを使用させることは通常の実行への実質的な変化である。この技術革新の理由は,略式でのタスク分析の後,我々はデザイナーが明確に論理的で時間的な関係を表現して欲しい,ということである。これは,このような順序付けが,ユーザがいつでも意味的な視点から有効にする必要があるタスクを実行できるように,ユーザインタフェースの実装において考慮されるべきであるからである。)

M 「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. To this end, the DTD format for task models specified by ConcurTaskTrees has been developed. Its purpose is to indicate the syntax for XML expressions that correctly represent task models. This can be useful to facilitate the possibility of analyzing its information from other environments or to build rendering systems able to generate user interfaces for specific platforms using the task model as abstract specification.」(805頁左欄下から19行?下から3行)
(当審訳:4.6 様々なフォーマットの仕様での保存
いつでも,すべてまたは一部の仕様を保存することや,その逆に,現在の仕様に,以前に保存された仕様の一部を挿入することが可能である。これは,JPEG画像として仕様の全部または一部を保存することもまた可能である。これは,検討されているアプリケーションに関連するドキュメント,マニュアル,またはレポートにそれらを挿入する際に,特に有用である。
XML形式でタスクモデルを保存することも可能である。この目的のために,ConcurTaskTreesで指定されたタスクモデル用のDTDフォーマットが開発されている。その目的は,正確にタスクモデルを表すXML表現のための構文を示すことである。これは,他の環境からの情報分析の可能性を促進したり,抽象的仕様としてタスク・モデルを使用する特定のプラットフォーム用のユーザインタフェースを生成することができるレンダリング・システムを構築するのに,有用であり得る。)

(2-5)引用文献5

本願の優先日前に頒布され,上記平成26年4月11日付けの当審による拒絶理由通知において引用された刊行物である,特開2006-260101号公報(平成18年9月28日出願公開。以下,「引用文献5」という。)には,図面とともに,以下の技術的事項が記載されている。
(当審注:下線は,参考のために当審で附加したものである。)

N 「【要約】
【課題】メッセージのタスクへの影響度を自動的かつ即時的に分析する。
【解決手段】作業用端末100のメッセージ集計部140がメッセージを集計してバックエンド300のメッセージデータ管理リポジトリ303に登録する。タスク判定部110がタスク状況を判定してバックエンド300のタスク進捗管理リポジトリ305等に登録する。関連度算出サービス301は、タスク状況のイベントに基づいてタスクとメッセージとを関連付けその関連度を算出する。バックエンド300の関連度情報提供サービス302は、作業用端末100の関連メッセージ表示GUIとインタラクトしてメッセージの関連度をユーザに表示・提供する。」

(3)参考文献

(3-1)参考文献1

本願の優先日前に頒布された刊行物である,特開2005-216240号公報(平成17年8月11日出願公開。以下,「参考文献1」という。)には,図面(特に,図7)とともに,以下の技術的事項が記載されている。
(当審注:下線は,参考のために当審で附加したものである。)

P 「【0060】
ステップ166では、印刷対象の印刷画像データに付与されているファイル名を認識し、認識したファイル名と同一のファイル名が画像記憶部42に記憶されているか否かを判定する。この態様では、印刷システム10で過去に印刷を行った原稿のチェックサムデータを、印刷画像データのファイル名と対応づけて画像記憶部42に保管している。従って、ステップ166では、印刷対象の印刷画像データが過去に印刷を行った原稿のデータか否かを判定している。このように、この態様において、画像記憶部42は請求項1に記載の記憶手段(詳しくは請求項4に記載の「特徴情報を記憶する記憶手段」)に対応している。
・・・(中略)・・・
【0064】
一方、印刷対象の原稿が印刷システム10で過去に印刷が行われた原稿である場合は、ステップ166の判定が肯定されてステップ168へ移行し、印刷対象の印刷画像データと同一のファイル名と対応付けられたチェックサムデータ(過去に行われた印刷で用いられた印刷画像データに対して演算・付加されていたチェックサムデータ)を画像記憶部42から取り出し、取り出したチェックサムデータを印刷対象の印刷画像データのチェックサムデータ(ステップ164で取り出したチェックサムデータ)と各ラインを単位として比較する。次のステップ170ではチェックサムが不一致か否か判定する。なお、ステップ168,170は請求項1(詳しくは請求項4,5)に記載の判断手段に対応している。ステップ170の判定が否定された場合、印刷対象の原稿は印刷システム10で前回印刷されてから変更されていないと判断できるので、ステップ178で画像記憶部42へチェックサムデータ等を登録し、ステップ180で印刷対象の印刷画像データを指定された印刷装置へ転送することで印刷装置により印刷処理を行わせ、変更監視処理を終了する。
【0065】
また、チェックサムが不一致のラインが存在している場合、印刷対象の原稿における前記ラインは印刷システム10で前回印刷されてから変更されていると判断できる。このため、ステップ170の判定が肯定された場合はステップ172へ移行する。次のステップ172以降の処理は請求項1(詳しくは請求項6)に記載の変更通知手段に対応しており、ステップ172では印刷対象の原稿の印刷を指示した印刷指示者に対し、チェックサム不一致のラインが有ったことを通知し、当該ラインについての変更が正規の変更か否かのチェックを印刷指示者へ要請する。これは、例えばBEP20のディスプレイ又は印刷指示者が操作しているクライアント端末22のディスプレイに、チェックサム不一致のラインを明示して印刷対象の原稿を表示させると共に、明示したラインが変更されていることを通知するメッセージ(例えば「明示しているラインには何らかの変更が加えられています」等)を表示させ、更に明示したラインに加えられている変更が正規の変更か否かのチェックを要請するメッセージ(例えば「明示したラインに加えられている変更が正規の変更かご確認下さい」等)を表示させることで実現できる。
【0066】
上記の通知が行われることで、印刷指示者は、印刷対象の原稿が前回の印刷時から変更されていることを認識し、明示されたラインに加えられている変更を確認することで、該変更が自身が把握している変更内容か(すなわち印刷対象の原稿に対して為された変更が正規の変更か)否か判断する。そして、BEP20又はクライアント端末22のキーボードを介して判断結果を入力する。次のステップ174では、印刷指示者によって入力された情報に基づき、チェックサムが不一致となったラインに加えられている変更が正規の変更か否か判定する。
・・・(中略)・・・
【0068】
一方、印刷対象の原稿に加えられている変更が、印刷指示者が把握している変更であった場合には、ステップ174の判定が肯定されてステップ178へ移行する。この場合、ステップ178で画像記憶部42へのチェックサムデータ等の登録が行われ、ステップ180で印刷対象の印刷画像データが指定された印刷装置へ転送されることで、印刷装置による印刷処理が行われることになる。」

(3-2)参考文献2

本願の優先日前に頒布された刊行物である,特開2007-172113号公報(平成19年7月5日出願公開。以下,「参考文献2」という。)には,図面(特に,図4及び図8)とともに,以下の技術的事項が記載されている。
(当審注:下線は,参考のために当審で附加したものである。)

Q 「【0050】
ここで、メモリカード45内の「AAAA0003.JPG」が、デジタルカメラにより編集されていた場合について説明する。具体的には、「AAAA0003.JPG」が、ファイル名の変更はないものの、ユーザによりデジタルカメラの編集モードを利用して編集されていたとする。例えば、サイズ変更、レタッチ処理、向きの変更などの編集がなされていたとする。
【0051】
かかる場合、ファイル名の変更はないものの、ヘッダは書き換わっている。したがって、図5で示したファイルの同一性の判断処理により、メモリカード45の「AAAA0003.JPG」と、CD-Rに記録されている「AAAA0003.JPG」とが非同一であると判断される。そして、図4のS20の処理により、例えば、「AAAB0003.JPG」とリネームされて、CD-Rに記録される。このとき、撮影日は元のままであるので、元の撮影日に対応するフォルダに格納される。」
・・・(中略)・・・
【0057】
<変形例>
本発明は、上記実施形態に制限されない。上記実施形態は、本発明の技術的思想の範囲内で様々変形が可能である。
【0058】
例えば、上記実施形態のように、ファイルの同一性の判断のためにヘッダをそのままチェックするのではなく、チェックサムやCRC(Cyclic Redundancy Check)値を利用することもできる。」

(4)対比

本願発明と引用発明とを対比する。


(ア)本願発明の「タスクモデル」とは,本願の出願当初の明細書等の段落【0017】の「タスクモデル(タスク記述)。」との記載,段落【0018】の「タスクモデル記述としてのXML文書」との記載,段落【0023】の「タスクモデル126の抽出は、典型的に、抽出され、標準化されたタスク記述を与える。・・・タスクモデル126はフォーマットを提供し、そのフォーマットでタスクはローカルに記憶され、クライアント層102とサーバ層104との間で送信される。」との記載,及び,段落【0032】の「タスクモデル126は、抽出され、標準化されたタスクの表現であり、・・・タスクモデルは、論理的にツリー状の構造であり、XML文書におけるようなマークアップ言語で記述することができる(図2のタスクモデル例を参照)。」との記載によれば,タスクについての表現に係る情報であり,タスク情報である。
(イ)一方,引用発明の「タスク」も,「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」中の何らかの記憶手段に記憶されていることは明らかである。
(イ)してみると,引用発明の「メモ」が所定の記憶手段に記憶され「タスク」と対応付けられていることと,本願発明の「製作物リポジトリ内に記憶された製作物は、1つまたは複数のタスクモデルと対応付けされる」こととは,ともに,“記憶された製作物は,1つまたは複数のタスク情報と対応付けされる”ことである点で共通する。

オ 以上から,本願発明と引用発明とは,以下の点で一致し,また,以下の点で相違する。

(一致点)
「タスク管理フロントエンドインタフェースを介してタスク情報更新要求を受信すると,前記タスク情報更新要求をタスク管理サーバに転送するステップと,
前記タスク管理サーバから前記タスク情報更新要求に対する応答を受信すると,前記タスク情報更新要求に対する応答において受信された少なくともいくつかのデータを使用して前記タスク管理フロントエンドインタフェースを更新するステップと,
を含み,
記憶された製作物は,1つまたは複数のタスク情報と対応付けされる方法。」

(相違点1)

本願発明が,「タスクモデル」を更新要求の対象とし,また,製作物を付属物として対応付けているのに対して,引用発明は,「タスク」を更新要求やメモの対応付けの対象としているものの,「タスクモデル」という構成については言及していない点。

(相違点2)

タスク管理フロントエンドインタフェース更新のためのタスク管理サーバからの応答に関し,本願発明が,タスクモデル更新要求の「成功確認」であるとしているのに対して,引用発明は,タスクの更新要求に対し何らかの応答を受信しているものの「成功確認」であるとは特定していない点。

(相違点3)

製作物の記憶に関し,本願発明が,「同一の名称および異なるコンテンツを有する制作物が記憶され、同一の名称およびコンテンツを有する製作物が記憶されないように」「製作物リポジトリ内」に行うのに対して,引用発明は,メモの記憶方法及び記憶手段について具体的に特定していない点。

(相違点4)

本願発明が,「更新されたタスクモデルの付属物である製作物が前記タスクモデル内で参照を使用して記述されていないならば、前記タスク管理サーバに前記製作物を含む製作物更新要求を送信するステップ」及び「前記製作物更新要求の成功確認を受信すると」同一の名称および異なるコンテンツを有する製作物が記憶され、同一の名称およびコンテンツを有する制作物が記憶されないように製作物リポジトリ内に記憶された「前記製作物への参照を前記タスクモデル内に記述するステップ」を有しているのに対して,引用発明は,メモをタスクに対応付けて添付するよう要求を行っているものの,上記のような各ステップを有していない点。

(5)当審の判断

上記相違点1ないし相違点4について検討する。

ア 相違点1について

(ア)タスクに文書等の付属物を対応付けること,及び,当該タスクをモデル化してタスクに関する情報をXML等のフォーマットで記述することは,本願の優先日前に,周知技術(例えば,上記引用文献4の上記L及びM等参照)であった。
(イ)してみると,引用発明のタスク管理において,上記周知技術を採用し,更新要求及びタスクの付属物の対応付けの対象を「タスクモデル」とすること,すなわち,上記相違点1に係る構成とすることは,当業者が容易に想到し得たものである。

イ 相違点2について

(ア)上記引用文献2(上記J等の記載)には,データベース更新要求が成功した場合に,サーバからXMLデータ(本願発明の「成功確認」に相当)を取得して,該XMLデータに基づいたDHTML要素を生成してブラウザに出力させることが記載されている。
(イ)そして,引用発明及び引用文献2に記載された技術は,サーバに対して更新要求を送る点で共通の機能を有するものであるから,引用発明に上記引用文献2に記載された技術を適用し,Project Server からタスクへのリスクのリンクの変更保存の反映結果である「成功確認」を受信し,Project Web Access画面を更新するようすることは,当業者にとって格別な困難性を伴うものではない。
(ウ)してみると,引用発明のタスク管理において,タスクモデル更新要求の「成功確認」の受信によって,Project Web Access画面を更新するようにすること,すなわち,上記相違点2に係る構成とすることは,当業者が容易に想到し得たものである。

ウ 相違点3及び相違点4について

(ア)引用発明におけるメモは,タスクに対応付けられて何らかの記憶手段に記憶されるものであるところ,当該記憶手段として,リポジトリを採用することは周知技術(例えば,上記引用文献5の上記N等参照)といえ,また,記憶手段へのファイル等の記憶を,ファイル名や内容によりどのように排他処理するかは,必要により適宜決める設計的事項(例えば,同一のファイル名を有するデータの記憶がされないように処理することは,引用文献3の上記K等に記載され,また,同一ファイル名でもチェックサム値が異なる内容のデータは記憶するように処理することは,参考文献1の上記P及び参考文献2の上記Q等に記載されている。)であり,引用発明におけるメモの記憶に関し,上記周知技術等を採用し,「同一の名称および異なるコンテンツを有する制作物が記憶され,同一の名称およびコンテンツを有する制作物が記憶されないように」「製作物リポジトリ内」に行うようにすることに,格別困難性は認められない。
(イ)また,上記「(1)相違点1について」で検討した如く,タスクに文書等を対応付けること,及び,「タスクモデル」として記述することはいずれも周知であるところ,付属物である上記メモについても当該周知の構成を採用することで,タスクモデルのXMLにおける参照という形式により,対応付けられたメモに関する情報を記述することも,格別困難性を要せずに想到し得る程度のことであり,その場合,更新されたタスクに対し,対応するメモがタスクモデル内に記述されていないと判断されれば,メモをタスクモデル内に記述するよう更新要求を行って記述させることは必然的に行う事項であって,当業者であれば容易になし得ることである。
(ウ)してみると,引用発明のタスク管理において,「同一の名称および異なるコンテンツを有する制作物が記憶され,同一の名称およびコンテンツを有する製作物が記憶されないように」「製作物リポジトリ内」に行うとともに,「更新されたタスクモデルの付属物である製作物が前記タスクモデル内で参照を使用して記述されていないならば,前記タスク管理サーバに前記製作物を含む製作物更新要求を送信するステップ」及び「前記製作物更新要求の成功確認を受信すると,」同一の名称および異なるコンテンツを有する制作物が記憶され,同一の名称およびコンテンツを有する製作物が記憶されないように製作物リポジトリ内に記憶された「前記製作物への参照を前記タスクモデル内に記述するステップ」を有するようにすること,すなわち,上記相違点3及び相違点4に係る構成とすることは,当業者が容易に想到し得たものである。

エ 小括

そして,本願発明の奏する作用効果は,上記引用発明及び上記周知技術の奏する作用効果から予測される範囲内のものにすぎず,格別顕著なものということはできない。

したがって,本願発明は,上記引用発明及び上記周知技術に基づいて,当業者が容易に発明をすることができたものであり,特許法第29条第2項の規定により,特許を受けることができない。

7 むすび

上記4のとおり,平成26年6月16日付けの手続補正は,出願当初の明細書等に記載した範囲内でしたものではなく,特許法第17条の2第3項に規定する要件を満たしていないから,本願は拒絶すべきものである。

また,上記5のとおり,本願の請求項1ないし21の記載は,特許法第36条第6項第1号及び同法同条第4項第1号に規定する要件を満たしていないから,本願は拒絶すべきものである。

さらに,上記6のとおり,本願の請求項1に係る発明は,特許法第29条第2項の規定により特許を受けることができないものであるから,本願は拒絶すべきものである。

よって,結論のとおり審決する。
 
審理終結日 2015-01-06 
結審通知日 2015-01-13 
審決日 2015-01-26 
出願番号 特願2008-182891(P2008-182891)
審決分類 P 1 8・ 55- WZ (G06F)
P 1 8・ 121- WZ (G06F)
P 1 8・ 537- WZ (G06F)
P 1 8・ 536- WZ (G06F)
最終処分 不成立  
前審関与審査官 稲垣 良一金子 秀彦  
特許庁審判長 山崎 達也
特許庁審判官 小林 大介
田中 秀人
発明の名称 分散タスク処理  
代理人 渡邊 隆  
代理人 実広 信哉  
代理人 村山 靖彦  
代理人 志賀 正武  

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