【事件の表示】
　特願２００１−３４１１５１「食事管理システム」拒絶査定不服審判事件〔平成１５年　５月１６日出願公開、特開２００３−１４１２５９〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
　
１．　手続の経緯
　
　本願の手続の経緯は次に示すとおりである。
　
平成１３年１１月　６日　特許出願。
平成１８年１１月２４日　拒絶理由通知（起案日）。
平成１９年　１月１１日　手続補正。
平成１９年　２月２２日　拒絶査定（起案日）。
平成１９年　３月２９日　拒絶査定不服審判請求。
平成１９年　４月２５日　手続補正。
平成２１年　７月２７日　当審拒絶理由通知（起案日）。
平成２１年　９月２９日　手続補正。
　
　
２．　本願発明
　
　平成２１年９月２９日付けの手続補正では特許請求の範囲は補正されておらず、本願の請求項１乃至４に係る発明は、平成１９年４月２５日付けの手続補正によって補正された特許請求の範囲の請求項１乃至４に記載されたとおりのものと認められるところ、本願の請求項１に係る発明（以下、「本願発明」という。）は、次のとおりのものである。
　
＜本願発明＞
「　対象者に提供すべき食事の情報を管理する第１のコンピュータシステムと、前記対象者の食事を管理する第２のコンピュータシステムとがネットワークを通じて通信を行う食事管理システムであって、
　前記第１のコンピュータシステムは、
　食事に含まれる素材の栄養価に関する情報である素材情報を記憶した素材情報データベースと、
　該素材情報データベースに記憶した素材情報に基づいて作成された、前記素材を含む単品料理からなる食事のメニューを記憶するメニューデータベースと、
　該メニューデータベースからのメニューを前記第２のコンピュータシステムへ送信する手段とを備え、
　前記第２のコンピュータシステムは、
　前記メニューを送信する手段により送信されたメニューを受信する手段と、
　前記対象者の栄養摂取量の許容範囲を含む対象者情報を記憶した対象者情報データベースと、
　該対象者情報データベースに記憶した栄養摂取量の許容範囲に基づいて、前記メニューを受信する手段により受信したメニュー内の食事の各々に含まれる素材の量を調整するために使用される栄養指導情報データベースと、
　該栄養指導情報データベースを使用して調整されたメニューを前記対象者に提供する情報端末と、
　前記情報端末に提供されたメニューのうちから前記対象者により摂取される食事の選択を受け付ける手段と、
　前記選択を受け付けた食事に関する情報である選択食情報を前記第１のコンピュータシステムへ送信する手段と、
　選択食を前記対象者に提供する配膳容器に付けられた前記対象者の情報を記憶した非接触ＩＣタグと、
　前記ＩＣタグの前記対象者の情報を読取って回収された前記配膳容器から得られる残食状況から前記対象者の食事摂取情報を報告する際に使用されるＩＣタグリーダライタとを備える、
　ことを特徴とする食事管理システム。」
　
　
３．　引用例
　
３−１．　引用例１
　当審の拒絶の理由に引用された、本願出願前である平成１２年７月１４日に頒布された刊行物である、特開２０００−１９４７４９号公報（以下、「引用例１」という。）には、図面とともに以下の記載がある。
　
（１ａ）　「【０００１】
【発明の属する技術分野】本発明は１ヶ所以上の食事を提供（serve）する施設に、食事を構成する料理の食材を供給（provide）する料理供給システムに関する。」
　
（１ｂ）　「【０００５】
【課題を解決するための手段】上記課題を解決するための本発明の料理供給システムは、所定の食材を最終調理した料理からなる食事を飲食者に提供する食事提供施設Ｃと、該食事提供施設Ｃに前記料理の未加工又は予備加工された食材を供給する食材供給施設Ｈとの間に介設され、上記食事提供施設Ｃへの食材の供給を管理するシステムであって、食材提供施設Ｃ側にホストシステムＡが、食事提供施設Ｃ側にクライアントシステムＢが各配置され、上記ホストシステムＡがクライアントシステムＢとの間で、食材の発注を受信する受信部Ｒと、発注された食材の材料の種類を仕分けして、各材料毎に集計する食材集計部Ｆと、ホストシステムＡ側での上記集計後のデータに基づいて上記食事提供施設Ｃ側に納入する食材の納入表１３を作成する納入表作成部Ｅとを備えたシステムであり、クライアントシステムＢがホストシステムＡとの間で、所定の献立に基づいた発注表を送信する送信部ＳＣと、納入表１３を受信し、納入表１３と発注表との対比照合するチェック部ＣＣを備えたシステムであることを第１の特徴としている。」
　
（１ｃ）　「【０００８】第４にホストシステムＡ及びクライアントシステムＢが、食材供給施設Ｈと食事提供施設Ｃとに配置された文字又はグラフィックの送受信が可能な通信装置と、該通信装置相互の通信手段とからなることを特徴としている。
【０００９】第５に通信装置がコンピュータ４，９により構成され、通信手段がコンピュータネットワークであることを特徴としている。」
　
（１ｄ）　「【００１０】
【発明の実施の形態】次に本発明の１実施形態について詳細に説明する。本発明の食材供給システム（フードプロバイドシステム）は、図１に示されるように所定の食材を最終調理した料理からなる食事を飲食者に提供（serve）する施設である１つ又は複数の食事提供施設Ｃと、該食事提供施設Ｃに前記料理の食材を供給（provide）する施設である食材供給施設Ｈとの間に介設されている。
【００１１】そして病院や療養所等の食事提供施設Ｃにおけるキッチン（サテライトキッチン）側と食材供給施設Ｈにおけるキッチン（セントラルキッチン）側との間で行われる食材の供給システム（プロバイドシステム）と、該プロバイドシステムを成り立たせるための通信システム（コミニュケーションシステム）とから構成されている。
【００１２】つまりサテライトキッチン側は、入所者に提供する食事用の料理の食材をセントラルキッチン側に発注してセントラルキッチンから後述するように食材の供給を受け、該供給された食材から所定の料理を製造し、該料理等の組み合わせによる食事を食事提供施設Ｃにおいて飲食者に提供する。
【００１３】例えばサテライトキッチン側（食事提供施設Ｃ）は、セントラルキッチンから供給される食材により、味噌汁，エビ団子の煮付け，牛肉の佃煮，きのこオムレツという料理を製造し、この各料理（味噌汁，エビ団子の煮付け，牛肉の佃煮，きのこオムレツ）を組み合わせて食事として飲食者に提供する。」
　
（１ｅ）　「【００２１】次に上記コミニュケーションシステムの構造について全体のシステム概念図である図１及びシステムの作動フローの概略図である図２に従って説明する。このコミニュケーションシステムは、前述のように上記プロバイドシステムを成り立たせる（食材の供給を管理する）ためのツールであり、セントラルキッチン１側及びサテライトキッチン２側に設けられ、コンピュータネットワークによりネットワーク接続されたコンピュータ４，９を中心としたシステムにより実現されている。
【００２２】まずコミニュケーションシステムにおけるセントラルキッチン１側の構造について説明する。セントラルキッチン１側にはホストシステムが構築されており、該ホストシステムはディスプレイ３を有したホストコンピュータ４により構成せしめられている。
【００２３】そして上記ホストコンピュータ４はコンピュータネットワーク上で送受信されるディスプレイ表示可能な図３に示される表計算形式の献立表（ディスプレイ３での表示状態が図３となる献立表データ）６を作成するとともに、該献立表６をサテライトキッチン７側（コンピュータネットワークにおけるディスプレイ８を備えたクライアントコンピュータ９）に送信する送信部Ｓと、後述するようにクライアントコンピュータ９側から送信された献立表６（発注表）を受信することができる受信部Ｒとからなる送受信部Ｔを備えている。
【００２４】このとき献立表６には所定の日付に対してサテライトキッチン７側に提供可能な料理の食材が日付毎（図３の例では1998年10月1のみ例示）に入力されており、これらサテライトキッチン７側で選択可能な料理と該料理を形成せしめる食材及び食材の量（純量），料理及び食材の栄養価が予め入力されている（ホストコンピュータ４側で入力する）。
【００２５】またその他にサテライトキッチン名及び該サテライトキッチンの施設名の入力が可能であり（入力欄があり）、さらに各食材の食数の入力が可能（入力欄がある）に構成されている。そしてセントラルキッチン１側においては全ての項目に、サテライトキッチン７側においては、サテライトキッチン名及び該サテライトキッチンの施設（食事提供施設）名の記入項目と食数の記入項目にコンピュータ４，９上において書き込み（入力）が可能に設定されている。
【００２６】一方ホストコンピュータ４には、各サテライトキッチン７側（後述するようにサテライトキッチン７に配されたクライアントコンピュータ９）から送られた発注表を食材の種類毎に集計するディスプレイ表示可能な図４に示される食数表１１（ディスプレイ３での表示状態が図４となる食数表データ）を生成する食数演算部Ｆ１も備えられている。
【００２７】なお前述のように献立表６にはサテライトキッチン７側において、サテライトキッチン名，施設名，食数の記入が可能に構成されており、本実施形態において上記発注表はサテライトキッチン７側において上記各項目に入力が行われた献立表６が使用される。」
　
（１ｆ）　「【００３６】次にコミニュケーションシステムにおけるサテライトキッチン７側の構造について説明する。サテライトキッチン７にはクライアントシステムが構築されており、該クライアントシステムはディスプレイ８を備えたクライアントコンピュータ９により構成せしめられている。このとき該クライアントコンピュータ９は、コンピュータネットワーク上でホストコンピュータ４との情報（データ）の送受信が可能なように、例えばホストコンピュータ４側とサーバ・クライアント型又はピアトゥピア型にネットワーク接続されている。
【００３７】そしてクライアントコンピュータ９にはホストコンピュータ４から送信される献立表６，納入表１３，調理指示表１４（実際には各データ）を受信する受信部ＲＣと、ホストコンピュータ４に所定の記載を行った献立表６（発注表）を送信する送信部ＳＣとを備えた送受信部ＴＣが設けられており、さらに受信した献立表６，納入表１３，調理指示表１４の各データを表形式に表示する（再現させる）こと、及び受信した献立表６内（サテライトキッチン名，サテライトキッチンの施設名，食数の入力欄）への任意の入力が可能に設定されている。また送信した発注表と受信した納入表との対比照合を行うチェック部ＣＣも設けられている。
【００３８】なお献立表６，納入表１３，調理指示表１４の各データをホストコンピュータ４側に記憶させておき、クライアントコンピュータ９に共有データとして公開し、各表６，１３，１４のデータをクライアントコンピュータ９から直接読み書きするように構成してもよい。
【００３９】一方クライアントコンピュータ９は、作業者が所定の食材に対して必要な食数（数）を記入すると、この食数が入力された食材が構成用件となる（入力された食材を必要とする）料理をメニューとして選択したと判断して、サテライトキッチン７側のメニュー（メニュー表）を自動的に作成するメニュー表作成部Ｍも備えている。
【００４０】　（略）
【００４１】次に上記コミニュケーションシステムの作動についてプロバイドシステムの作動にあわせて説明する。まずサテライトキッチン７側（食事提供施設Ｃ）においては、予めセントラルキッチン１から送られる献立表６から所定日時の所定の食事（朝食，昼食，夕食等）のメニューを決定し、このメニュー基づいてセントラルキッチン側（食材供給施設Ｈ）に発注する食材を決定し、前記献立表６内の必要な（発注する）食材の側方の食数欄に、該食材の必要数の数量を入力し、セントラルキッチン１に送信する。この際にサテライトキッチン７側はサテライトキッチン名及び施設名を入力するが、セントラルキッチン側で送信元を自動判別するように設定しておいてもよい。
【００４２】これによりセントラルキッチン１側においては、セントラルキッチン１側のシステム（ホストコンピュータ４）に各サテライトキッチン７から送信された注文表（必要な食材の数量が記入された献立表６）が入力され、この献立表６を基に前述のように食数表１１，仕分け表１２，納入表１３が演算・作成される。
【００４３】そしてセントラルキッチン１側において生成された仕分け表１２や食数表１１に基づいて各材料を調達するとともに所定の調理を行い、食材を製造し、該食材を所定の日時（食事の日時から設定される）に各サテライトキッチン７毎に搬送する。そしてサテライトキッチン７側においては食材を受け取り、調理指示表等に基づいて食材を最終調理して料理を製造し、盛り付けを行い、飲食者に提供する。」
　
（１ｇ）　「【００４７】以上に示されるフードプロバイドシステムによれば、上記のように食材は食事を構成する料理がアッセンブル化されたもの（アッセンブル料理）であり、つまり料理は各アッセンブル（食材）の組み合わせで製造される。　・・・（中略）・・・
【００４８】　（略）
【００４９】つまりサテライトキッチン７側にて製造する料理の自由度が大きく、換言するとサテライトキッチン７側において製造される料理は、最終的な調理をサテライトキッチン７で行うため、サテライトキッチン７側（食事提供施設Ｃ）で提供される料理はいわゆるインスタント料理等とは異なり、容易にオリジナリティーを持たせることができ、入居者により適した食事を容易に作ることができる。」
　
　そして、引用例１の上記（１ａ）〜（１ｇ）の記載事項、及び、図面を総合すると、引用例１には、次の発明（以下、「引用発明」という。）が記載されていると認められる。
　
＜引用発明＞
「病院や療養所等の入所者に提供すべき食事の情報を管理するセントラルキッチン側のホストシステム（A）と、前記入所者の食事を管理するサテライトキッチン側のクライアントシステム（B）とがコンピュータネットワークを通じて通信を行う食材供給システムであって、
　
　前記セントラルキッチン側のホストシステム（A）は、
　食事に含まれる食材・材料の栄養価（エネルギー・タンパク質・脂質・炭水化物糖質）に関する情報である食材・材料情報を記憶し、
　記憶した食材・材料情報に基づいて作成された、前記食材・材料を含む料理からなる食事の献立表（図３）を記憶し、
　前記献立表（図３）を前記クライアントシステム（B）へ送信する献立表作成送信部（Ｓ）を備え、
　
　前記サテライトキッチン側のクライアントシステム（B）は、
　前記献立表作成送信部（Ｓ）により送信された献立表を受信する献立表受信部（ＲＣ）を備え、
　前記献立表のうちから前記入所者により摂取される食事のメニューを決定して各料理の食数を入力するとともに、
　前記入力された食事に関する情報である発注表を前記ホストシステム（A）へ送信する発注表送信部（ＳＣ）を備える
　
　食材供給システム。」
　
　
３−２．　引用例２
　当審の拒絶の理由に引用された、本願出願前である平成１１年２月２日に頒布された刊行物である、特開平１１−３１１７５号公報（以下、「引用例２」という。）には、以下の記載がある。
　
（２ａ）　「【０００１】
【発明の属する技術分野】本発明は、食材・加工調理品宅配業における、注文メニュー設定方式及び関連部署への作業指示方式に関する。」
　
（２ｂ）　「【００１２】図２は、メニューマスタ（３０）のテーブル図を示しており、メニューとその属性が記されたマスタである。「メニュー」毎、さらに同じメニューでも「調理レベル」毎、さらに同じメニュー／調理レベルでも「嗜好」毎と、「メニュー」「調理レベル」「価格」「カロリー」「食事制限」「嗜好」「栄養特性毎」という各項目において、一つでも項目の内容が異なる場合には、違うレコードとして登録されているマスタである。（例：メニューが３種類、調理レベルが３種類、嗜好が３種類ある場合には、３×３×３＝２７のレコードが登録される。) 　　・・・（中略）・・・　
【００１３】　　（略）
【００１４】図５は、顧客マスタ（３３）のテーブル図を示しており、顧客属性についてのマスタであり。「顧客NO.」「顧客苗字」「家族構成」「住所」及び、家族個人毎に「摂取栄養／カロリー基準値」が記されたマスタである。
【００１５】図６は、メニュー検索トランザクションファイル（３４）のテーブル図を示しており、メニュー検索処理（処理１−２）で利用されるファイルである。メニューマスタ（３０）と同様に、「メニューNO.」「メニュー名」「調理レベル」「価格」「カロリー」「食事制約」「嗜好」「栄養特性」より構成されている。」
　　
（２ｃ）　「【００２８】　　・・・（中略）・・・　
図１５  メニュー検索処理（処理１−２）は、消費者からのメニュー検索条件情報（４４）から、合致するメニューを検索する処理である。
【００２９】なお、メニュー検索条件情報（４４）とは、消費者がニーズに合ったメニューを検索するための検索条件である。図１２は、メニュー検索条件情報（４４）のテーブル図を示しており、「希望値段」「希望カロリー」「食事制約（健康上の理由等より摂取出来ない栄養素等の制限。例：塩分削減）」「嗜好（味の好み。例：辛い）」「調理レベル（食材の調理加工のレベル。例：半調理品）」より構成されている。
【００３０】　　・・・（中略）・・・　
メニュー検索条件情報（４４）を基に、消費者が検索項目として入力した項目をキーとして、メニュー検索トランザクションファイル（３４）より、該当するメニューを抽出する。〔ステップ４０４〕
　　・・・（中略）・・・　
メニュー検索トランザクションファイル（３４）を消費者端末（２０）へ表示する。〔ステップ４０７〕
　　・・・（中略）・・・　
【００３１】消費者端末（２０）より送信された注文情報（４０）から、「配達日」「顧客NO.」「顧客苗字」「注文メニューNO.」「注文メニュー名」を注文情報展開処理トランザクションファイル（３５）に登録する。〔ステップ５００〕」
　　
（２ｄ）　「【００３２】
【発明の効果】以上述べて事により、本発明によれば、消費者は、タイムリーにニーズに合った内容のメニューを食材・半調理品・調理品という自由な形態で調達できるようになる。」
　　
　そして、引用例２の上記（２ａ）〜（２ｄ）の記載及び関連する図面から、引用例２には次の（１）〜（３）の事項（以下、「引用例２に示された事項」という。）が記載されていると認められる。
　
＜引用例２に示された事項＞
（１）　「同じメニューであっても、カロリー・食事制限・栄養特性毎という各項目が一つでも異なるものは、違うメニューとして登録すること。」
（２）　「消費者個人毎に摂取栄養／カロリー基準値を記しておき、消費者個人毎のカロリー・食事制約（健康上の理由等により摂取出来ない栄養素等の制限。例：塩分削減）に対応するメニューを抽出すること。」
（３）　「消費者本人が消費者端末から食事のメニューを検索して注文すること。」
　
３−３．　引用例３
　当審の拒絶の理由に引用された、本願出願前である平成１２年２月２２日に頒布された刊行物である、特開２０００−５０８１５号公報（以下、「引用例３」という。）には、以下の記載がある。
　
（３ａ）　「【０００１】
【発明の属する技術分野】本発明は、例えば病院等において糖尿病や肝臓病等のように、栄養士が、厳格な食事療法が必要な患者に対する食事を作るための献立を作成するときに利用される献立作成支援システムに関する。
【０００２】
【従来の技術】例えば、糖尿病や肝臓病等を煩っている患者に対しては、厳格な食事療法を実施する必要がある。　・・・（中略）・・・　
【０００３】　・・・（中略）・・・　そして、各病気毎又は各患者毎に、各表毎にカロリーの必要量を一覧表に表したものを食品交換表と称する。
【０００４】さらに、糖尿病食品交換表によると、糖尿病の患者の体内で８０キロカロリーのエネルギを食品の量の単位と称する。なお、肝臓病食品交換表によると、たんぱく質３ｇを含む食品重量を１単位と称するために、おなじ１単位であっても、病気の種類によって、同一の食品であったとしても、必要な重量が異なる。
【０００５】そして、糖尿病の食事指導においては、主治医から１日の指示エネルギ量を単位数の形で指示される。例えば、指示エネルギ量が１６００キロカロリーならば、１６００÷８０＝２０となり、１日２０単位数と指示される。
【０００６】　　（略）
【０００７】
　　・・・（中略）・・・　
したがって、栄養士が該当患者に提供する食事の献立を作成する場合、該当患者の病気に対応した上述した食品交換表から１日の合計単位数に合うように、食事に使用する食品及びその量（重量）を選択設定する必要がある。
【０００８】
【発明が解決しようとする課題】しかしながら、栄養士が上述した各病気毎又は各患者毎に設定された食品交換表を参照しながら該当病気の患者に提供する食事の献立を作成するには、まだ解消すべき次のような課題があった。
【０００９】すなわち、栄養士の手元には、献立に使用可能な各食品毎に該当食品が１から６までのどの表に所属するかと、病気毎の前述した１単位に対応する重量を示す単位重量が記載された一覧表が予め準備されている。そして、栄養士は、前記食品交換表に記載された各表の単位数及び合計単位数、さらに、前述した一覧表を参照して、献立に使用する食品及びその量（重量）を選択設定する。」
　
（３ｂ）　「【００１２】また、一つの献立の作成が終了した時点で各表の合計の単位数や全部の表に亘る合計の単位数を算出して、前記食品交換表に基づく上限値を越えているか否かを検証していた。そして、その時点で各合計の単位数が上限値を超えていた場合、最初から献立をやり直す必要があり、栄養士にとって、多大の無駄時間を費やすことになる。」
　
（３ｃ）　「【００２１】別の発明においては、上述した発明の献立作成支援システムに対して、さらに、各表毎、食事毎または１日における合計の単位数に対する上限値を記憶する上限単位数テーブルと、献立作成テーブルに新規の食品が書込まれる毎に、書込まれている各表毎、食事毎または１日における合計の単位数を算出する単位数算出手段と、算出された合計の単位数が前記上限単位数テーブルに記憶された上限値を越えると警告出力する警告出力手段とを備えている。
【００２２】このように構成された献立支援システムにおいては、栄養士が新規の食品及び使用重量を入力する毎に、献立作成テーブルに書込まれている各表毎、食事毎または１日における合計の単位数が自動的に算出され、算出された合計の単位数が上限値を越えると、この時点で、自動的に警告が出力される。
【００２３】したがって、その時点で直ちにその誤った食品入力を取消又は重量値の訂正ができる。」
　
　そして、引用例３の上記（３ａ）〜（３ｃ）の記載及び関連する図面から、引用例３には次の事項（以下、「引用例３に示された事項」という。）が記載されていると認められる。
　
＜引用例３に示された事項＞
「栄養士が、糖尿病の患者には８０キロカロリーのエネルギーを有する量の食品を１単位とし、肝臓病の患者にはたんぱく質３ｇを含む量の食品を１単位として、その単位数が糖尿病患者あるいは肝臓病患者について設定された上限値を超えないように、各食品の量を調整して献立を作成すること。」
　
３−４．　引用例４
　当審の拒絶の理由に引用された、本願出願前である平成１２年１２月１５日に頒布された刊行物である、特開２０００−３４８０１３号公報（以下、「引用例４」という。）には、以下の記載がある。
　
（４ａ）　「【請求項１】  栄養指導に関するデータを管理する栄養指導システムにおいて、
医師が患者の疾病に応じて作成した栄養指導の指示データをコンピュータネットワークから取り込む指示データ取り込み手段と、
患者の検査結果データをコンピュータネットワークから取り込む検査結果データ取り込み手段と、
患者が実際に摂取した栄養摂取データを取り込む栄養摂取データ取り込み手段と、
前記指示データ，検査結果データ，栄養摂取データに基づいて行なった栄養指導の記録を作成し、その栄養指導の記録を格納する格納手段とを有することを特徴とする栄養指導システム。
【請求項２】  前記栄養摂取データ取り込み手段は、
献立から患者が摂取する予定の栄養摂取量を算出する予定栄養摂取量算出手段と、
前記患者が食べ残した残食から患者が摂取しなかった栄養量を算出する残食栄養量算出手段と、
前記患者が摂取する予定の栄養摂取量及び前記患者が摂取しなかった栄養量に基づいて実際に患者が摂取した栄養摂取量を算出する栄養摂取量算出手段とを有することを特徴とする請求項１記載の栄養指導システム。」
　
（４ｂ）　「【０００７】更に、作成された栄養指導の記録を格納手段に格納しておくことにより、医師は必要に応じて栄養指導の記録を参照できる。また、その栄養指導の記録を簡単に検索でき、次回の栄養指導に利用することが容易になる。また、請求項２記載の本発明は、前記栄養摂取データ取り込み手段は、献立から患者が摂取する予定の栄養摂取量を算出する予定栄養摂取量算出手段と、前記患者が食べ残した残食から患者が摂取しなかった栄養量を算出する残食栄養量算出手段と、前記患者が摂取する予定の栄養摂取量及び前記患者が摂取しなかった栄養量に基づいて実際に患者が摂取した栄養摂取量を算出する栄養摂取量算出手段とを有することを特徴とする。
【０００８】このように、残食から患者が摂取しなかった栄養量を算出することにより、実際に患者が摂取した栄養摂取量を把握することができ、効果的な栄養指導を行なうことが可能となる。」
　　
（４ｃ）　「【００２６】図６は、本発明の栄養指導システムが実行する処理の第２実施例のフローチャートを示す。図６のフローチャートは、主に入院患者の栄養摂取量の算出に関するものである。入院患者は、医師の栄養指導指示に基づいた給食システムにより計画的に栄養摂取が行われる。しかしながら、入院患者が出された給食を全て食べるとは限らず、医師の指示食種による栄養摂取量と実際に摂取した栄養摂取量とが異なる場合がある。そこで入院患者の給食の残食管理を行なうことにより、患者が実際に摂取した栄養摂取量を把握することができる。以下、図６のフローチャートの処理について説明する。
【００２７】同図中、ステップＳ２００では、医師の栄養指導指示に基づいた給食の献立メニューから入院患者が摂取する予定の予定栄養摂取量がＬＡＮ接続装置１００から取り込まれる。なお、給食の献立メニューがデータベース化されていない場合、入力装置２０より給食の献立メニューを入力してもよい。この給食の献立メニューは、例えば図７に示すように構成される。
【００２８】図７は、給食の献立メニューの一例の説明図を示す。図７の給食の献立メニューは、メニュー毎の栄養摂取量及びそのメニューを構成する食材毎の栄養摂取量，食事（例えば、朝食，昼食，夕食）毎の栄養摂取量，一日の栄養摂取量より構成される。ステップＳ２００に続いてステップＳ２１０に進み、実際の給食の残食を調べることにより入院患者毎の残食量を取得する。そして、入力装置２０より残食量のデータが栄養指導システムに入力される。ステップＳ２１０に続いてステップＳ２２０に進み、演算処理装置８０はステップＳ２１０にて取り込まれた残食量から残食の栄養量を算出する。そして、予定栄養摂取量から残食の栄養量を減算することで実際に患者が摂取した栄養摂取量を算出する。
【００２９】このように、給食の残食管理を行なうことにより実際に入院患者が摂取した栄養摂取量を把握することができ、医師の栄養指導指示に基づく予定栄養摂取量と実際に入院患者が摂取した栄養摂取量とを比較検討し、効果的な栄養指導を行なうことが可能となる。」
　　
（４ｄ）　「【００４３】　・・・（中略）・・・　また、請求項２記載の本発明によれば、残食から患者が摂取しなかった栄養量を算出することにより、実際に患者が摂取した栄養摂取量を把握することができ、効果的な栄養指導を行なうことが可能となる。」
　　
　そして、引用例４の上記（４ａ）〜（４ｄ）の記載及び関連する図面から、引用例４には次の事項（以下、「引用例４に示された事項」という。）が記載されていると認められる。
　
＜引用例４に示された事項＞
「入院患者に出す給食の献立メニューから入院患者毎の予定栄養摂取量を求め、
給食の実際の残食を調べることにより入院患者毎の残食量を取得し、残食量から残食の栄養量を算出し、
前記予定栄養摂取量から前記残食の栄養量を減算することで、入院患者が実際に摂取した栄養摂取量を算出すること。」
　
３−５．　引用例５
　当審の拒絶の理由に引用された、本願出願前である平成１３年４月３日に頒布された刊行物である、特開２００１−８７０４５号公報（以下、「引用例５」という。）には、以下の記載がある。
　
（５ａ）　「【０００１】
【発明の属する技術分野】本発明は、病院や学校等の施設における食事の配膳に使用される配膳車に関する。」
　
（５ｂ）　「【０００３】特に、病院等の医療施設にあっては、各患者に異なる献立の食事を配膳する必要のある場合が多い。」
　　
（５ｃ）　「【０００６】本発明は、上記のような従来の問題に鑑みてなされたものであり、異なる献立の食事を対応する人に正しく配膳すること、及び、その記録管理が容易な配膳車を提供することを目的とする。
【０００７】
【課題を解決するための手段】本発明による配膳車は、トレーに載置された食品セットを複数収容する収容庫を備えたものであって、各トレーに設けられた認識タグに付されたバーコードを読み取るバーコードリーダと、前記バーコードに対応する食品セットの種類や配膳先等の給食情報を記憶する記憶装置と、前記バーコードリーダで読み取ったバーコードに対応する給食情報を前記記憶装置から読み出す制御部と、この制御部によって読み出された給食情報を表示する表示装置とを備え、前記制御部は、各トレーの入出庫に際し、前記バーコードリーダで前記バーコードが読み取られた時刻を入出庫時刻として記憶する機能を有することを特徴とする。
【０００８】上記のような構成によれば、各トレーに設けられた認識タグに付されたバーコードを読み取るだけで、トレーに配置された食品セットを配膳車に入庫した時間及び配膳車から出庫した時間を記録として残すことができ、管理が容易になる。また、各食品セットを配膳車に入庫する際に、食品セットと配膳先の人（例えば患者）との対応を確認することが容易になる。更に、食品セットを配膳車から出庫する際に、出庫しようとする食品セットの種類や配膳先等の給食情報が表示されるので、間違った食品セットを配膳する可能性が小さくなる。」
　　
（５ｄ）　「【００１６】図３は、バーコード２３と給食情報との対応を示すテーブルの一例である。」
　　
　そして、引用例５の上記（５ａ）〜（５ｄ）の記載及び関連する図面から、引用例５には次の（１），（２）の技術的事項（以下、「引用例５に示された技術的事項」という。）が記載されていると認められる。
　
＜引用例５に示された技術的事項＞
（１）　「病院の患者に配膳する食事のトレーに、献立、配膳先である患者名、部屋番号を表すバーコードを付すること。」
（２）　「食事のトレーに付されたバーコードをバーコードリーダで読み取って、配膳先である患者名を表示すること。」
　
３−６．　引用例６
　当審の拒絶の理由に引用された、本願出願前である平成１１年１０月１２日に頒布された刊行物である、特開平１１−２７６３５９号公報（以下、「引用例６」という。）には、以下の記載がある。
　
（６ａ）　「【０００１】
【発明の属する技術分野】本発明はご飯、汁、主菜、副菜などの食事を適温に保冷した状態で家庭や老人ホーム、病院等に配食することができる配食用容器、その容器を加熱する加熱調理器及びそれらを用いた配食システムに関する。」
　
（６ｂ）　「【０００７】　・・・（中略）・・・　また食材を盛りつけた給食容器を１回電子レンジ等で加熱した後、放置し再度加熱すると同様に食品の早期腐敗や雑菌の付着等を招きやすく食品衛生上の問題が生じる。」
　　
（６ｃ）　「【００４１】このシステムで使用する加熱調理器７は、第１実施例と同様のいわゆる電子レンジタイプのものであるが、この第２実施例の加熱調理器７は、図１０に示すように、配食用容器毎の識別情報とこの識別情報に関連して配食用容器３を加熱したことを記憶する記憶部３６を有している。そして、加熱調理器７の制御部３９は操作部２２から入力された加熱処理条件に従って記憶部３６から読み出した加熱処理プロセスを実行し加熱部２１を加熱制御することができるが、こうした加熱処理を開始する前に情報受取部３８で受け取った識別情報に基づき、加熱調理器７内にセットされた配食用容器３の識別コードをキーコードとして記憶部３６に保存されている加熱情報を検索し、既に加熱したことを示す情報が検出されたときは加熱処理の開始を中止する。　・・・（中略）・・・　一方、配食用容器３が未加熱のものであるときは、加熱制御を開始するとともに、情報受取部３８から取得した識別情報に関連付けて配食用容器を加熱したことを示す情報を記憶部３６に保存する。
【００４２】配食用容器毎の識別情報は、配食用容器３を加熱しようとする際に操作部２２から手入力したり、配食用容器３と一緒に配送される識別カードから識別情報を情報受取部としてのカードリーダー（図示省略）で読み取るように構成することができるが、好ましくは、図８に示すように、配食用容器３の外容器１２の外面に識別情報を保有する情報記憶部３７が設けられ、加熱調理器７の本体１８の内側面に配食用容器３の情報記憶部３７からその記憶情報を取得する情報受取部３８が設けられる。配食用容器３に設けられる情報記憶部３７は、配食用容器に配食用容器を特定するためのバーコードや、IDチップ等で構成することができる。このような構成とすれば配食用容器３を加熱調理器７内にセットしたときに該加熱調理器３を加熱したかどうかを自動的にチェックすることができる。」
　　
　そして、引用例６の上記（６ａ）〜（６ｃ）の記載及び関連する図面から、引用例６には次の技術的事項（以下、「引用例６に示された技術的事項」という。）が記載されていると認められる。
　
＜引用例６に示された技術的事項＞
「病院に配食する配食用容器に、個々の配食用容器を特定するためのＩＤチップを設けること。」
　
　
４．　対比
　
　本願発明と引用発明とを比較すると、次のことがいえる。
　
（１）　引用発明における「病院や療養所等の入所者」は、本願発明の「対象者」に相当する。
（２）　引用発明における「セントラルキッチン側のホストシステム（A）」は、本願発明の「第１のコンピュータシステム」に相当する。
（３）　引用発明における「サテライトキッチン側のクライアントシステム（B）」は、本願発明の「第２のコンピュータシステム」に相当する。
（４）　引用発明における「コンピュータネットワーク」は、本願発明の「ネットワーク」に相当する。
（５）　引用発明における「食材供給システム」は、本願発明の「食事管理システム」に相当する。
（６）　引用発明における「食材・材料」は、本願発明の「素材」に相当し、引用発明における「食材・材料情報」は、本願発明の「素材情報」に相当する。
（７）　引用発明における「料理」は、本願発明の「単品料理」に相当する。
（８）　引用発明における「食事」は、本願発明の「食事」に相当する。
（９）　引用発明における「献立表（図３）」は、本願発明の「メニュー」に相当する。
（１０）　引用発明における「栄養価（エネルギー・タンパク質・脂質・炭水化物糖質）」は、本願発明の「栄養価」に相当する。
（１１）　引用発明における「献立表作成送信部（Ｓ）」は、本願発明における「メニューを第２のコンピュータシステムへ送信する手段」に相当する。
（１２）　引用発明における「献立表受信部（ＲＣ）」は、本願発明における「メニューを受信する手段」に相当する。
（１３）　引用発明が、食事のメニューを決定して各料理の食数を入力していることは、本願発明が、食事の選択を受け付けていることに相当している。
（１４）　引用発明における「発注表」は、本願発明の「選択食情報」に相当する。
（１５）　引用発明における「発注表送信部（ＳＣ）」は、本願発明の「選択食情報を第１のコンピュータシステムへ送信する手段」に相当する。
　
　すると、本願発明と引用発明とは次の点で一致する。
　
＜一致点＞
「対象者に提供すべき食事の情報を管理する第１のコンピュータシステムと、前記対象者の食事を管理する第２のコンピュータシステムとがネットワークを通じて通信を行う食事管理システムであって、
　
　前記第１のコンピュータシステムは、
　食事に含まれる素材の栄養価に関する情報である素材情報を記憶し、
　記憶した素材情報に基づいて作成された、前記素材を含む単品料理からなる食事のメニューを記憶し、
　メニューを前記第２のコンピュータシステムへ送信する手段とを備え、
　
　前記第２のコンピュータシステムは、
　前記メニューを送信する手段により送信されたメニューを受信する手段と、
　前記メニューのうちから前記対象者により摂取される食事の選択を受け付ける手段と、
　前記選択を受け付けた食事に関する情報である選択食情報を前記第１のコンピュータシステムへ送信する手段とを備える
　　
　食事管理システム。」
　　
　一方で、本願発明と引用発明とは次の点で相違する。
　　
＜相違点１＞　素材情報データベース，メニューデータベース
　本願発明は、その第１のコンピュータシステムが、素材情報データベース及びメニューデータベースを備えたものであるのに対し、引用例１のものは、この本願発明の第１のコンピュータシステムに対応しているセントラルキッチン側のホストシステム（A）が、食材・材料情報及び献立表を記憶しているものの、これらの食材・材料情報及び献立表をデータベースとして記憶することが、引用例１には示されていない点。
　　
＜相違点２＞　素材の量を調整すること，対象者情報データベース，栄養指導情報データベース
　　
　本願発明は、対象者の栄養摂取量の許容範囲に関する情報に基づいて、メニュー内の食事の各々に含まれる素材の量を調整するものであるのに対し、引用例１には、メニュー内の食事の各々に含まれる素材の量を調整することが示されておらず、したがってその調整を、対象者の栄養摂取量の許容範囲に関する情報に基づいて行うことも示されていない点。またそのために、本願発明は、その第２のコンピュータシステムが、対象者の栄養摂取量の許容範囲を含む対象者情報を記憶した対象者情報データベース、及び、栄養摂取量の許容範囲に基づいて、メニュー内の食事の各々に含まれる素材の量を調整するために使用される栄養指導情報データベースを備えたものであるのに対し、引用例１には、この本願発明の第２のコンピュータシステムに対応しているサテライトキッチン側のクライアントシステムに、病院の入所者の栄養摂取量の許容範囲に関する情報を記憶したデータベース、及び、メニュー内の食事の各々に含まれる素材の量を調整するためのデータベースを備えることが示されていない点。
　　
＜相違点３＞　情報端末
　本願発明は、その第２のコンピュータシステムが、メニューを対象者に提供する情報端末を備えたものであり、この情報端末に提供されたメニューのうちから食事の選択を受け付けるものであるのに対し、引用例１のものにおいて食事の選択を受け付けているのは、サテライトキッチン側のクライアントシステムそのものであって、メニューを対象者に提供するための情報端末をクライアントシステムそのものとは別に設けること、及び、この別の情報端末から食事の選択を受け付けることが引用例１には示されていない点。
　
＜相違点４＞　誰が食事を選択するか
　食事の選択に関して、本願の特許請求の範囲の請求項１には、「対象者により摂取される食事の選択を受け付ける」と記載されているのみであって、メニューから食事を選択するのが誰であるのかは必ずしも明確ではないが、本願発明は、メニューを対象者に提供し、提供されたメニューのうちから対象者により摂取される食事の選択を受け付けるものであるから、実質的には、食事を摂取する対象者本人がメニューから食事を選択するものであるのに対し、引用例１のものでメニューから食事を選択しているのは、サテライトキッチン側にあるクライアントシステムを操作している作業者であって、食事を摂取する本人が食事を選択することが引用例１には示されていない点。
　
＜相違点５＞　残食状況から対象者の食事摂取情報を報告すること
　本願発明は、回収された配膳容器から得られる残食状況から対象者の食事摂取情報を報告するものであるのに対し、引用例１には、これに対応する事項が示されていない点。
　
＜相違点６＞　ＩＣタグ
　本願発明は、選択食を対象者に提供する配膳容器に対象者の情報を記憶した非接触ＩＣタグを付けたものであるのに対し、引用例１には、これに対応する事項が示されていない点。
　
＜相違点７＞　ＩＣタグリーダライタ
　本願発明は、ＩＣタグの対象者の情報を読取って、回収された配膳容器から得られる残食状況から対象者の食事摂取情報を報告する際に使用されるＩＣタグリーダライタを備えたものであるのに対し、引用例１には、これに対応する事項が示されていない点。
　
　
５．　判断
　
　上記相違点について検討する。
　　
＜相違点１について＞
　同じ種類の情報を一括して管理するために情報をデータベースとして記憶することは，本願出願前の周知技術であり、引用発明において食材・材料情報を一括して管理し、また献立表を一括して管理することは普通に考えられることであるから、引用発明のセントラルキッチン側のホストシステム（A）に食材・材料情報及び献立表を記憶させる際に、これらの情報をデータベースとして記憶させること、すなわち本願発明にいう素材情報データベース及びメニューデータベースを備えることとすることは、当業者が容易になし得たことである。
　
＜相違点２について＞
　栄養士が食事のメニューを作成する方法には様々なものがあるが、例えば引用例３に示された事項として挙げたとおり、
「栄養士が、糖尿病の患者には８０キロカロリーのエネルギーを有する量の食品を１単位とし、肝臓病の患者にはたんぱく質３ｇを含む量の食品を１単位として、その単位数が糖尿病患者あるいは肝臓病患者について設定された上限値を超えないように、各食品の量を調整して献立を作成すること。」
や、また例えば引用例２に示された事項の（２）に挙げたとおり、
（２）　「消費者個人毎に摂取栄養／カロリー基準値を記しておき、消費者個人毎のカロリー・食事制約（健康上の理由等により摂取出来ない栄養素等の制限。例：塩分削減）に対応するメニューを抽出すること。」
が従来から知られている。
　これらのメニュー作成方法で栄養士が実質的に意図することは、糖尿病患者にはカロリー摂取量が上限値以下となるメニューを、肝臓病患者にはたんぱく質摂取量が上限値以下となるメニューを、また、塩分削減をしなければならない患者には塩分を削減したメニューを提供することである。
　その際、どのようにしてカロリーあるいはたんぱく質を上限値以下としたり、塩分を削減したりしようとするかを考えると、カロリーを減らすためには、カロリーの高い食材の量を減らし、たんぱく質を減らすためには、たんぱく質を多く含む食材の量を減らし、塩分削減のためには、塩そのものや、塩を多く含む調味料たとえば醤油や、塩分を多く含む食材の量を減らすことが一般的であるといえる。また、栄養士であれば、カロリーを減らすために、カロリーの高い食材の代わりにカロリーの低い似た食材を用いることや、砂糖の代わりに人工甘味料を用いることや、塩分削減のために通常の醤油の代わりに減塩醤油を用いることも普通に思いつくものといえる。
　このように、患者毎にカロリーあるいはたんぱく質の上限値を設定し、あるいは塩分削減という条件を設定して、メニューに使うある食材やある調味料の量を減らしたり、代わりの食材や調味料を用いること、すなわち、対象者の栄養摂取量の許容範囲に関する情報に基づいて、メニュー内の食事の各々に含まれる素材の量を計算して調整することは、従来から病人食を扱う栄養士が行っていた手法であるといえる。
　このような手法それ自体は、従来から人である栄養士が行っていたことであるし、人が計算して行っていた手法を単にコンピュータを利用して実施することはコンピュータが世に生まれたときから綿々と行われ続けてきたことであるから、この栄養士が計算して行っていた手法をコンピュータシステムを利用して実施することに技術的な困難性は認められない。
　では、その実施を具体的にどのようにして当業者が行うことができたかを考えると、例えば引用例２に示された事項（１）として挙げたとおり、
（１）　「同じメニューであっても、カロリー・食事制限・栄養特性毎という各項目が一つでも異なるものは、違うメニューとして登録すること。」
も従来から知られていたから、この実施に当たって当業者は、ある１つの料理について、そのままの通常メニューと、従来から栄養士が行っていた手法によって、同じ料理であってカロリーを減らした糖尿病患者向けメニューと、たんぱく質を減らした肝臓病患者向けメニューと、塩分削減メニューとの４つのメニューを作成して登録しておき、この４つのメニューの中から患者に応じたメニューを選択することをまず想到する。カロリーあるいはたんぱく質の上限値や、塩分削減の必要性の程度は、患者の病状の軽重によって異なりうるから、４つのメニューのみならず、糖尿病患者向け、肝臓病患者向け、塩分削減のそれぞれについてさらに程度を段階的に設定したメニューを作成して登録しておき、個々の患者により適合したメニューを選択することも当業者であれば想到し得たものと言える。
　してみると、引用発明のものにおいて、病院の入所者が、通常メニューを提供すればよい者であるか、糖尿病患者であるか、肝臓病患者であるか、塩分削減が必要な者であるか、またカロリーあるいはたんぱく質の上限値や塩分削減の必要性の程度に関する情報に基づいて、ある１つの料理について、その料理の通常メニューに含まれているある食材やある調味料の量を減らしたり、代わりの食材や調味料を用いたりして段階的に設定したメニューを作成して登録しておき、個々の患者の病状の別およびその軽重に応じてより適合したメニューを選択するように構成すること、すなわち、対象者の栄養摂取量の許容範囲に関する情報に基づいて、メニュー内の食事の各々に含まれる素材の量を調整するように構成することは、当業者が容易になし得たことである。
　また、素材の量を調整することに関しては上述したとおりであって、必要な情報をデータベースとして記憶することは、本願出願前の周知技術であったから、素材の量を調整するために必要な情報である、対象者の栄養摂取量の許容範囲、及び、メニュー内の食事の各々に含まれる素材の量を調整するための情報を病院側のコンピュータにデータベースとして記憶させておくことも、当業者が容易になし得たことである。
　
＜相違点３，４について＞
　食事のメニューを食べる本人が選択することは、消費者にとって利便性が高いものといえ、許容できれば病院等でも採用すべきものといえ、引用例２に示された事項の（３）に挙げたとおり、消費者本人が消費者端末から食事のメニューを注文することも、従来から通常行われていたことであるから、引用発明のサテライトキッチンのクライアントシステム（B）側に、病院の入所者のための端末を設けて、病院の入所者本人がこの端末から食事のメニューを注文するように構成すること、すなわち本願発明にいう、メニューを対象者に提供する情報端末を設けて、対象者本人がこの情報端末から食事を選択するように構成することは、当業者が容易になし得たことである。
　　　
＜相違点５について＞
　対象者の食事摂取情報を報告することは、従来から病院のスタッフが医師等に対して行っていた事項であって、入院患者への給食を配膳容器で配膳し、食事後に配膳容器を回収することも周知の事項である。また、引用例４に示された事項として挙げたとおり、
「入院患者に出す給食の献立メニューから入院患者毎の予定栄養摂取量を求め、
給食の実際の残食を調べることにより入院患者毎の残食量を取得し、残食量から残食の栄養量を算出し、
前記予定栄養摂取量から前記残食の栄養量を減算することで、入院患者が実際に摂取した栄養摂取量を算出すること。」
も、本願出願前に慣用の手法であったから、引用発明において病院の入所者に提供した食事の実際の残食を病院のスタッフが調べることにより、入所者が実際に摂取した栄養摂取量を求めて医師等に報告すること、すなわち本願発明にいう、回収された配膳容器から得られる残食状況から対象者の食事摂取情報を報告することは、病院のスタッフ等の当業者が容易になし得たことである。
　　　
（なお、回収された配膳容器から得られる残食状況から対象者の食事摂取情報を報告することは、病院のスタッフが医師等に対して行うことであって、そもそも技術的な事項ではないから、これをコンピュータを用いた食事管理システムに付加しても、技術的思想の創作たる発明としての進歩性を生じさせるような事項では元々ないともいえる。）
　　　
（なお、請求人は、平成２１年９月２９日付けの意見書の（３）の（ｂ）の項目及び（３）の（ｃ）の（ｉｉ）の項目において、実際に摂取された食事量を求めることが各引用例には開示されていない旨を主張しているが、該事項は、上記３−４．の（４ｂ）に、
「患者が食べ残した残食から患者が摂取しなかった栄養量を算出する」、
「実際に患者が摂取した栄養摂取量を算出する」、
「残食から患者が摂取しなかった栄養量を算出することにより、実際に患者が摂取した栄養摂取量を把握する」
と記載され、
また、上記３−４．の（４ｃ）の【００２８】にも、
「実際の給食の残食を調べることにより入院患者毎の残食量を取得する。」、
「予定栄養摂取量から残食の栄養量を減算することで実際に患者が摂取した栄養摂取量を算出する。」
と記載されていることから明らかなとおり、引用例４に明瞭に開示されているといえる。）
　　　
＜相違点６，７について＞
　配膳容器の１個１個を特定するために非接触ＩＣタグ等とそのリーダライタとを用いることは、引用例５に示された技術的事項（１）、（２）として挙げたとおり、
（１）　「病院の患者に配膳する食事のトレーに、献立、配膳先である患者名、部屋番号を表すバーコードを付すること。」、及び、
（２）　「食事のトレーに付されたバーコードをバーコードリーダで読み取って、配膳先である患者名を表示すること。」
として、
また例えば引用例６に示された技術的事項として挙げたとおり、
「病院に配食する配食用容器に、個々の配食用容器を特定するためのＩＤチップを設けること。」
として知られていたように、病院で食事を患者に配膳する際に用いられていた慣用の手法である。
　そして、引用例５における上記トレー、及び、引用例６における上記配食用容器は、本願発明における配膳容器に相当するものであると言える。
　してみると、引用発明において病院の入所者に提供する食事を、入所者毎に管理するために、食事の配膳容器に対象者の情報を記憶した非接触ＩＣタグを付けること、及び、配膳容器から対象者の情報を読み取るためのＩＣタグリーダライタを設けることは、当業者が容易になし得たことである。
　　　
（なお、請求人は、平成２１年９月２９日付けの意見書の（３）の（ｃ）の（ｉ）の項目において、引用例５のものはトレー毎に管理をしているものであり、引用例６のものも配食用容器を管理しているものであって、これら引用例５，６のものは個々の容器の食材を個別に管理するものではないから、本願発明とは異なる旨の主張をしている。請求人の該主張は、本願発明が、個々の容器の食材を個別に管理するものであることを前提としたものであるが、本願の当初明細書を参照しても、本願における配膳容器がどのようなものであるかについては、その段落【００８５】に、
「【００８５】なお、患者が摂取した食事の情報は、例えば配膳容器に患者の情報を記載した非接触ＩＣタグをつけることにより管理することができる。この場合、患者から配膳容器を回収する回収者が非接触ＩＣタグリーダライタを用いて、回収された配膳容器に付された非接触ＩＣタグ内の患者情報を読取る。そして、読取られた患者情報に対応する配膳容器の残食状況を、厨房用サーバの管理者に報告する。厨房用サーバの管理者は、配膳容器の回収者から受けた報告の内容を、厨房用データベースに反映する。」
との記載があるのみであって、個々の容器の食材を個別に管理することは、そもそも本願の当初明細書にすら記載されていなかった事項であり、本願の特許請求の範囲の請求項１にも記載されていない事項であるといえる。）
　
　
　また、本願発明の構成によってもたらされる効果も、引用発明、周知の事項、及び、周知の技術的事項から当業者が予測することができた程度のものであって、格別のものとは認められない。
　
　
６．　むすび
　
　以上のとおり、本願発明は、引用発明、周知の事項、及び、周知の技術的事項に基づいて当業者が容易に発明をすることができたものであるから、本願の請求項１に係る発明は、特許法第２９条第２項の規定により特許を受けることができないものである。
　したがって、その余の請求項について検討するまでもなく、本願は拒絶すべきものである。
　よって、結論のとおり審決する。