【事件の表示】
　平成　９年特許願第１４９７４６号「情報アクセス方法および装置」拒絶査定不服審判事件〔平成１０年１２月２２日出願公開、特開平１０−３４０２３４〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は、平成９年６月６日の出願であって、平成１８年８月２９日付けで拒絶査定がなされ、これに対し、平成１８年１０月５日に拒絶査定不服審判が請求されるとともに、同日付けで手続補正がなされたものである。その後、当審において、平成２１年１０月２３日付けで拒絶の理由が通知され、これに対して、平成２１年１２月１１日付けで意見書及び手続補正書が提出されたものである。
　
２．本願発明
　本願の請求項１に係る発明（以下、「本願発明」という。）は、平成２１年１２月１１日付け手続補正書の特許請求の範囲の請求項１に記載された事項により特定される、以下のとおりのものである。
　「【請求項１】　放送局の多重化手段が、アンカー情報を埋め込まれたコンテンツ情報と、放送されてきた情報を用いたサーバサイトへのアクセスであることを当該サーバサイトのコンピュータ・システムに対して示すオリジン情報とを放送信号に多重化するステップと、
　上記放送局の送信手段が、上記多重化した放送信号を送信するステップと、
　受信端末の受信手段が、上記多重化した放送信号を受信するステップと、
　受信端末の取り出し手段が、上記受信した放送信号から、上記コンテンツ情報と上記オリジン情報とを取り出すステップと、
　受信端末の閲覧要求発行手段が、取り出した上記コンテンツ情報中のアンカー情報の指定に応じて当該アンカー情報により特定される他のコンテンツ情報の閲覧要求をネットワーク上の上記コンピュータ・システムに発行するステップと、
　受信端末の供給手段が、上記閲覧要求を発行するときに上記オリジン情報を上記コンピュータ・システムに供給するステップと、
　上記コンピュータ・システムが、当該コンピュータ・システムに保管された上記オリジン情報を取り出すステップとを有することを特徴とする情報アクセス方法。」　
　
３．刊行物
　当審における、平成２１年１０月２３日付けで通知した拒絶の理由で引用した刊行物は次のとおりである。
　
刊行物１．笠野 英松 監修，マルチメディア通信研究会 編，「ポイント図解式 通信プロトコル事典」，株式会社アスキー，１９９６年１１月１１日，ｐｐ．５４０，５４１，５４４，５４５，５４７，５５２−５５４，５５９，５６１
　
刊行物２．菊池 隆裕，“Ｑ　地上波を使うデータ放送とは？”，日経コミュニケーション，第２１６号，１９９６年２月１９日，ｐｐ．９６−９７
　
刊行物３．インターノーツ，“テレビ放送とインターネットの融合”，ＷＥＢスタジオ第３巻，株式会社文化放送ブレーン，１９９７年６月１日，ｐｐ．１１４−１１７
　
刊行物４．特開平９−８１４４７号公報
　
３−１．刊行物１の記載
　刊行物１には、図面と共に、以下の事項が記載されている。
　
（ア）第５４０頁第２２行から第２５行
　HTTPは、アンカーと呼ばれるタグによって他のリソースへのハイパーリンクを実現できる言語であるHTML（HyperText Markup Language）との組み合わせで広く世の中に普及しましたが、HTMLはHTTP上で送られるデータ形式の一つにすぎません。
　
（イ）第５４１頁第２３行から第２４行
　大部分のHTTP通信は、ユーザー・エージェントによって開始され、オリジン・サーバ上のリソースがリクエストされます。
　
（ウ）第５４４頁第１０行から第１１行
　HTTPにおける表記法の拡張BNF（Backus Naur Form、RFC822参照）を表10-12に、またHTTPの基本ルールを表10-13に示します。
　
（エ）第５４５頁表10-12によれば、構文とその説明は、以下の（Ａ）から（Ｇ）のとおりである。以下の（Ａ）から（Ｇ）では、山括弧（〈〉）で囲まれた部分が構文に当たる。
（Ａ）〈name=definition〉あるルールの名前は、単純にその名前自身であり、=によってその定義と分離される。
（Ｂ）〈literal〉ダブルクォーテーションで囲まれたテキストそのもの。断りがなければケース・インセンシティブ（大文字と小文字を区別しない）
（Ｃ）〈rule1|rule2〉rule1かrule2のどちらか
（Ｄ）〈(rule1 rule2)〉かっこで囲まれた要素は、一つの要素として扱われる
（Ｅ）〈*rule〉要素の前の*は繰り返しを意味する。n*melementが完全形で、最小n回、最大m回、要素が現れる。デフォルトではゼロと無限大。*(element)はいくつでもよい。
（Ｆ）〈[rule]〉オプショナル要素
（Ｇ）〈N rule〉反復回数を指定する
（Ｈ）〈#rule〉完全フォーマットはn#melement。要素のリストを定義する。
　
（オ）第５４７頁第４行から第２４行
　URI（Uniform Resource Identifier、ユニフォーム・リソース・アイデンティファイヤ）は、インターネットのオブジェクトのアドレスや名前をエンコードした、WWWで用いられる書式です。
　WWWには、WWWのために開発された既存のプロトコルや、将来開発されるであろうプロトコルなど、拡張の可能性のある多くのプロトコルを用いてアクセスされるオブジェクトが存在します。あるプロトコルにおける個々のオブジェクトへのアクセス方法は、アドレスの文字列の形式にエンコードされています。しかし他のプロトコルでは、いろいろな形式のオブジェクトの名前の利用が可能です。そこでWWWでは、汎用的なオブジェクトの概念を抽象化するため、オブジェクトの名前やアドレスの統一的なセットのコンセプトが必要になります。
　URIは、登録されたネーム・スペースやアドレスにおける名前のこの統一的なセットで、次のようないろいろな名前で知られています。
　(a) WWWアドレス (WWW address)
　(b) ユニバーサル・ドキュメント・アイデンティファイヤ (Universal Document Identifier)
　(c) ユニバーサル・リソース・アイデンティファイヤ (Universal Resource Identifier)
　(d) URL（Uniform Resource Locator、ユニフォーム・リソース・ロケータ）とURN（Uniform Resource Name、ユニフォーム・リソース・ネーム）の組み合わせ
　
（カ）第５５２頁第２１行から第３２行
　クライアントからサーバに対するリクエストでは、メッセージの最初の行で、そのリソースに適用されるメソッド、リソースの識別子、使用されるプロトコルのバージョンが記述されます。機能が限定されたHTTP/0.9のプロトコルに対する下位互換としては、次の二つの書式が有効です。
　Request　　　　= Simple-Request|Full-Request
　Simple-Request = GET SP Request-URI CRLF
　Full-Request　 = Request-Line　　　　　　　 ; （P.552参照）
　　　　　　　　　 *(General-Header　　　　　 ; （P.551参照）
　　　　　　　　　　|Request-Header　　　　　 ; （P.554参照）
　　　　　　　　　　|Entity-Header)　　　　　 ; （P.559参照）
　　　　　　　　　 CRLF
　　　　　　　　　 [Entity-Body]　　　　　　　; （P.560参照）
　
　上記（カ）のRequest及びFull-Requestの定義は、上記（エ）に鑑みれば、以下のとおりと認められる。
　「Requestは、Simple-Request又はFull-Requestのいずれかであり、
　Full-Requestは、
　　Request-Lineと、
　　General-Header、Request-Header又はEntity-Headerの０回以上の繰り返しと、
　　CRLFと、
　　オプショナル要素としてのEntity-Bodyとからなる。」
　
（キ）第５５３頁第５行から第８行
　Request-Lineはメソッドのトークンではじまり、その後にRequest-URIとプロトコルのバージョンが続き、CRLFで終わります。個々の要素はスペース（SP）で区切られます。最後のCRLF以外では、CRやLFは使用できません。
 Request-Line = Method SP Request-URI SP HTTP-Version CRLF
　
（ク）第５５３頁第１２行から第１７行
　メソッドは、Request-URIで指定されるリソースに対して実行される方法を示しています。メソッドのトークンはケース・センシティブです。
　Method　 = GET　　　　　　　; （P.561参照）
　　　　　 | HEAD　　　　　　 ; （P.562参照）
　　　　　 | POST　　　　　　 ; （P.563参照）
　　　　　 | extension-method
　
　上記（ク）のMethodの定義は、上記（エ）に鑑みれば、以下のとおりと認められる。
　「Methodは、GET、HEAD若しくはPOSTというテキストそのもの又はextension-methodである。」
　
（ケ）第５５３頁第２４行から第２５行
　Request-URIはUniform Resource Identifierであり、リクエストが適用されるリソースを特定するものです。
　
（コ）第５５４頁第１９行から第２５行
　クライアントは、Request-Headerフィールドを用いて、リクエストやクライアント自身に関する追加情報をサーバに伝えます。
　Request-Header = Authorization　　　　　　 ; （表10-18参照）
　　　　　　　　 | From　　　　　　　　　　　; （表10-18参照）
　　　　　　　　 | If-Modified-Since　　　　 ; （表10-18参照）
　　　　　　　　 | Referer　　　　　　　　　 ; （表10-18参照）
　　　　　　　　 | User-Agent　　　　　　　　; （表10-18参照）
　
　上記（コ）のRequest-Headerの定義は、上記（エ）に鑑みれば、以下のとおりと認められる。
　「Request-Headerは、Authorization、From、If-Modified-Since、Referer又はUser-Agentである。」
　
（サ）第５５９頁表10-18のRefererの部分
　Request-HeaderのRefererフィールドによって、クライアントはサーバのために、Request-URIを取得したところのリソースのアドレス（URI）を示します。これによって、サーバは、参考、ログ、キャッシュの最適化などのための、リソースへのバックリンクのリストを作成することができます。
　
（シ）第５６１頁第３１行から第３２行
　GETメソッドは、Request-URIで示されるいかなる情報もエンティティのかたちで取得するということを意味します。
　
　以上の刊行物１の記載によれば、刊行物１には、次の発明（以下、「刊行物１記載発明」という。）が記載されていると認められる。
　
　「HTTP通信のうちのクライアントからサーバに対するリクエスト（Request）であって、
　Requestは、Full-Requestであり、
　Full-Requestは、Request-Lineと、Request-HeaderとCRLFとからなり、
　Request-Lineはメソッド（Method）のトークンではじまり、その後にRequest-URIとプロトコルのバージョンが続き、CRLFで終わり、個々の要素はスペース（SP）で区切られ、
　Methodは、GETというテキストそのものであり、
　GETメソッドは、Request-URIで示されるいかなる情報もエンティティのかたちで取得するということを意味し、
　Request-URIはUniform Resource Identifierであり、リクエストが適用されるリソースを特定するものであり、
　Request-Headerは、Refererであり、
　Request-HeaderのRefererフィールドによって、クライアントはサーバのために、Request-URIを取得したところのリソースのアドレス（URI）を示し、これによって、サーバは、参考、ログ、キャッシュの最適化などのための、リソースへのバックリンクのリストを作成することができ、
　URI（Uniform Resource Identifier、ユニフォーム・リソース・アイデンティファイヤ）は、インターネットのオブジェクトのアドレスや名前をエンコードした、WWWで用いられる書式であり、汎用的なオブジェクトの概念を抽象化するため、オブジェクトの名前やアドレスの統一的なセットであり、
　オブジェクトは、既存のプロトコルや、将来開発されるであろうプロトコルなど、拡張の可能性のある多くのプロトコルを用いてアクセスされるものであり、
　アンカーと呼ばれるタグによって他のリソースへのハイパーリンクを実現できる言語であるHTML（HyperText Markup Language）は、HTTP上で送られるデータ形式である、
　HTTP通信のうちのクライアントからサーバに対するリクエスト。」
　
４．対比
　本願発明と刊行物１記載発明とを以下で対比する。
　
　刊行物１記載発明の「サーバ」及び「アンカー」は、それぞれ本願発明の「サーバサイトのコンピュータ・システム」及び「アンカー情報」に相当する。
　
　刊行物１記載発明の「他のリソース」は、「アンカーと呼ばれるタグによって」「ハイパーリンクを実現」した際に該アンカーによって特定されるリソースであるから、本願発明の「アンカー情報により特定される他のコンテンツ情報」に相当する。
　
　HTMLの技術常識として、あるコンテンツの中にアンカーと呼ばれるタグによって実現されたハイパーリンクが存在するとき、当該コンテンツのうち当該アンカーで囲まれた部分を指定すると、当該アンカーによって特定されるリソースを閲覧するために、当該リソースの取得がサーバに対して要求される。
　してみると、刊行物１記載発明と本願発明とは、「コンテンツ情報中のアンカー情報の指定に応じて当該アンカー情報により特定される他のコンテンツ情報の閲覧要求をネットワーク上のコンピュータ・システムに発行するステップ」を含む点で一致しており、該ステップを実行するための「閲覧要求発行手段」を含む点でも一致している。
　
　一方、刊行物１記載発明の「リクエスト（Request）」は「GETメソッド」であり、「GETメソッドは、Request-URIで示されるいかなる情報もエンティティのかたちで取得するということを意味」するのであるから、刊行物１記載発明の「リクエスト（Request）」は、「Request-URIで示される情報」を入手するための要求である。
　よって、刊行物１記載発明の「リクエスト（Request）」は、本願発明の「閲覧要求」に相当し、刊行物１記載発明の「Request-URIで示される情報」は、本願発明の「他のコンテンツ情報」に相当する。
　
　刊行物１記載発明の「Request-Header」すなわち「Referer」は、「サーバのために、Request-URIを取得したところのリソースのアドレス（URI）を示（す）」ものである。
　「Request-URIを取得したところのリソース」は、アンカータグを含んだコンテンツ（Request-URIの参照元のコンテンツ）のことに他ならない。
　そして、刊行物１記載発明の「Request-Header」すなわち「Referer」は、「Request」の一部分を成すものである。
　してみると、刊行物１記載発明と本願発明とは、「アンカー情報を埋め込まれたコンテンツ情報と」、「該コンテンツ情報を用いたサーバサイトへのアクセスであることを当該サーバサイトのコンピュータ・システムに対して示す参照元情報」とを有し、「閲覧要求を発行するときに上記参照元情報を上記コンピュータ・システムに供給するステップ」を含み、該ステップを実行するための「供給手段」を含む点で一致する。
　
　刊行物１記載発明では、「Referer」によって「サーバは、参考、ログ、キャッシュの最適化などのための、リソースへのバックリンクのリストを作成する」から、該Refererがサーバによって保管され取り出されて利用されることは明らかである。
　してみると、刊行物１記載発明と本願発明とは、「コンピュータ・システムが、当該コンピュータ・システムに保管された上記参照元情報を取り出すステップとを有する」点で一致する。
　
　刊行物１記載発明の「クライアント」は、アンカー情報を埋め込まれたコンテンツ情報及び該コンテンツ情報中のアンカー情報の指定に応じて当該アンカー情報により特定される他のコンテンツ情報を取得し、それらを閲覧に供することは明らかである。
　してみると、刊行物１記載発明の「クライアント」と本願発明の「受信端末」とは、「閲覧のための端末」である点で一致する。
　
　刊行物１記載発明の「HTTP通信のうちのクライアントからサーバに対するリクエスト」は、明らかに「情報アクセス方法」を構成するものである。
　
　すると、本願発明と刊行物１記載発明との一致点及び相違点は、以下のとおりである。
　
〈一致点〉
　アンカー情報を埋め込まれたコンテンツ情報と、
　該コンテンツ情報を用いたサーバサイトへのアクセスであることを当該サーバサイトのコンピュータ・システムに対して示す参照元情報とを有し、
　閲覧のための端末の閲覧要求発行手段が、上記コンテンツ情報中のアンカー情報の指定に応じて当該アンカー情報により特定される他のコンテンツ情報の閲覧要求をネットワーク上の上記コンピュータ・システムに発行するステップと、
　閲覧のための端末の供給手段が、上記閲覧要求を発行するときに上記参照元情報を上記コンピュータ・システムに供給するステップと、
　上記コンピュータ・システムが、当該コンピュータ・システムに保管された上記参照元情報を取り出すステップとを有することを特徴とする情報アクセス方法。
　
〈相違点１〉
　本願発明では、「閲覧のための端末」が「多重化した放送信号を受信」する「受信端末」であり、「放送局の多重化手段が、アンカー情報を埋め込まれたコンテンツ情報を放送信号に多重化するステップと」、「受信端末の取り出し手段が、上記受信した放送信号から、上記コンテンツ情報を取り出すステップと」を有しているのに対し、刊行物１記載発明では、「閲覧のための端末」が放送信号を受信するものではない「クライアント」であり、上記多重化するステップ及びコンテンツ情報を取り出すステップを有していない点。
　
〈相違点２〉
　本願発明では、「参照元情報」が「放送されてきた情報を用いたサーバサイトへのアクセスであることを当該サーバサイトのコンピュータ・システムに対して示すオリジン情報」であり、「放送局の多重化手段が、オリジン情報を放送信号に多重化するステップと」、「受信端末の取り出し手段が、上記受信した放送信号から、上記オリジン情報を取り出すステップと」を有しているのに対し、刊行物１記載発明では、「参照元情報」が放送されてきた情報を用いたサーバサイトへのアクセスであることを示すものではない「Referer」であり、上記多重化するステップ及びオリジン情報を取り出すステップを有していない点。
　
５．判断
　上記相違点について判断する。
　
５−１．相違点１について
　放送信号にHTMLで記述されたコンテンツを多重化して放送局から送信し、受信側で多重化された信号からHTMLで記述されたコンテンツを取り出して閲覧する技術は、周知である（例えば、刊行物２第９７頁左欄第１４行から第３５行及び図２、刊行物３第１１４頁左欄第２行から第３０行及び刊行物４第００１４段落参照）。
　
　したがって、刊行物１記載発明における「アンカー情報を埋め込まれたコンテンツ情報」を、放送信号に多重化された形で入手するよう構成することは、当業者が格別の困難性なく発想することである。
　
５−２．相違点２について
　上記５−１に述べた、刊行物１記載発明における「アンカー情報を埋め込まれたコンテンツ情報」を、放送信号に多重化された形で入手するよう構成した場合について検討する。
　
　刊行物１記載発明における「Referer」は、「Request-URIを取得したところのリソースのアドレス（URI）を示す」ものであるが、その「リソースのアドレス（URI）」とは、具体的な記述形式よりも、サーバ側でリソースのバックリンクを特定し、「該サーバへのアンカー情報を埋め込まれたコンテンツ情報」がいかなる起源よりクライアントに入手されたかを明らかにすることに本質的な意義を有する情報であるから、引用例１記載発明において、「アンカー情報を埋め込まれたコンテンツ情報」を、クライアントが「放送信号に多重化された形」で入手するよう構成する場合、前記Refererとして該「アンカー情報を埋め込まれたコンテンツの情報」の出所が該「放送信号」（つまり「放送されてきた情報」）に由来することを示す情報（本願発明でいう「オリジン情報」）を用いるようにすることは、当業者がその知識、経験に基づき格別困難性無くなし得ることである。
　
５−３．相違点１及び２についてのまとめ
　以上の５−１及び５−２を総合すると、刊行物１記載発明に対して、周知技術のようなHTMLで記述されたコンテンツを放送信号に多重化して送信する技術を適用することで、
アンカー情報を埋め込まれたコンテンツ情報を放送信号に多重化し、
さらに、当該コンテンツ情報を示すURIをも該放送信号に多重化し、
放送局の送信手段が上記多重化した放送信号を送信するステップと、
受信端末が上記多重化した放送信号を受信するステップと、
受信端末の取り出し手段が、上記受信した放送信号から、上記コンテンツ情報と上記URIとを取り出すステップと、
受信端末の閲覧要求発行手段が、取り出した上記コンテンツ情報中のアンカー情報の指定に応じて当該アンカー情報により特定される他のコンテンツ情報の閲覧要求をネットワーク上のコンピュータ・システムに発行するステップと、
受信端末の供給手段が、上記要求を発行するときに上記URIを上記コンピュータ・システムに供給するステップとを有するようにし、
上記URIが、放送信号に由来するコンテンツであることを示す情報、すなわち、放送されてきた情報を用いたサーバサイトへのアクセスであることを当該サーバサイトのコンピュータ・システムに対して示す情報として、本願発明のように構成することは、当業者が容易になし得ることである。
　
６．むすび
　以上のとおり、本願発明は、刊行物１記載発明及び周知技術に基いて、当業者が容易に発明をすることができたものであるから、特許法第２９条２項の規定により特許を受けることができない。
　
　よって、結論のとおり審決する。