拒絶査定不服の審決｜不服2011-8216 - 特許審決データベース

会員機能

ランキング

請求人別審判件数

判例データベース

審決データベース

ポートフォリオ機能

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

この審決の個人情報、企業機密に関する修正依頼をする

PDF	PDFをダウンロード

審決分類	審判査定不服 2項進歩性特許、登録しない。 H04N 審判査定不服 2項進歩性特許、登録しない。 H04N 審判査定不服 5項独立特許用件特許、登録しない。 H04N
管理番号	1260891
審判番号	不服2011-8216
総通号数	153
発行国	日本国特許庁(JP)
公報種別	特許審決公報
発行日	2012-09-28
種別	拒絶査定不服の審決
審判請求日	2011-04-18
確定日	2012-08-02
事件の表示	特願2006-333699「データ伝送方法及びデータ伝送装置」拒絶査定不服審判事件〔平成19年 6月21日出願公開、特開2007-159148〕について、次のとおり審決する。
結論	本件審判の請求は、成り立たない。
理由	第1 経緯 1 経緯本願は、平成10年7月15日に出願された特願平10-200271号の一部を分割して、平成18年12月11日に出願(特願2006-333699号)されたものであって、平成21年12月11日付けで拒絶理由が通知され、これに対し、平成22年2月22日付けで意見書が提出されると同時に手続補正がなされたが、平成23年1月7日付け(発送日同年1月18日)で拒絶査定がなされたものである本件は、本願についてなされた上記拒絶査定を不服として平成23年4月18日付けで請求された拒絶査定不服審判であって、同時に手続補正がなされたものである。 2 査定の概要原査定の理由は、概略、次のとおりである。 [査定の理由] 請求項1及び2に係る発明は、下記の刊行物に記載された発明に基いて、当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。記引用文献1:L.Atzori, F.G.B.De Natale, M.Di Gregorio, D.D.Giusto,“Multimedia information broadcasting using digital TV channels”,IEEE TRANSACTIONS ON BROADCASTING,1997年 9月,VOL. 43, NO. 3,pp242-251 第2 補正却下の決定平成23年4月18日付けの手続補正について次のとおり決定する。 [補正却下の決定の結論] 平成23年4月18日付けの手続補正を却下する。 [理由] 1 補正の内容平成23年4月18日付けの手続補正(以下「本件補正」という。)は、請求項1及び請求項2についてする補正を含むものである。補正前の請求項1及び請求項2 「【請求項1】データ受信装置にモノメディアデータを伝送する伝送方法において、上記モノメディアデータをDSM-CC方式に基づいてモジュールを生成し、上記モジュールを固定長を有するブロックに分割し、上記ブロックに分割されたデータから、DDBメッセージを生成し、上記モジュールを識別するための情報、当該モジュールの大きさ及びモジュールのバージョンを示す情報を含んでいるDIIメッセージを生成し、上記DDBメッセージ及びDIIメッセージをトランスポートストリームに変換して、パケット化し、さらに、少なくともチャンネルリストを含むNITとチャンネルごとの情報であるPMTとを含むパケット化されたPSIとともに多重化し、周期的且つ繰り返し送出するカルーセル方式を使って伝送するデータ伝送方法。【請求項2】データ受信装置にモノメディアデータを伝送する伝送装置において、上記モノメディアデータをDSM-CC方式に基づいてモジュールを生成するモジュール生成手段と、上記モジュールを固定長を有するブロックに分割する分割手段と、上記ブロックに分割されたデータから、DDBメッセージを生成するDDBメッセージ生成手段と、上記モジュールを識別するための情報、当該モジュールの大きさ及びモジュールのバージョンを示す情報を含んでいるDIIメッセージを生成するDIIメッセージ生成手段と、上記DDBメッセージ及びDIIメッセージをトランスポートストリームに変換して、パケット化し、さらに、少なくともチャンネルリストを含むNITとチャンネルごとの情報であるPMTとを含むパケット化されたPSIとともに多重化し、周期的且つ繰り返し送出するカルーセル方式を使って伝送する伝送手段とを備えるデータ伝送装置。」を、次のとおり補正後の請求項1及び請求項2に補正するものである。「【請求項1】データ受信装置にモノメディアデータを伝送する伝送方法において、ダウンロードのためのGUI情報を含んでいる上記モノメディアデータをDSM-CC方式に基づいてモジュールを生成し、上記モジュールを固定長を有するブロックに分割し、上記ブロックに分割されたデータから、DDBメッセージを生成し、上記モジュールを識別するための情報、当該モジュールの大きさ及びモジュールのバージョンを示す情報を含んでいるDIIメッセージを生成し、上記DDBメッセージ及びDIIメッセージをトランスポートストリームに変換して、パケット化し、さらに、少なくともチャンネルリストを含むNITとチャンネルごとの情報であるPMTとを含むパケット化されたPSIとともに多重化し、周期的且つ繰り返し送出するカルーセル方式を使って伝送するデータ伝送方法。【請求項2】データ受信装置にモノメディアデータを伝送する伝送装置において、ダウンロードのためのGUI情報を含んでいる上記モノメディアデータをDSM-CC方式に基づいてモジュールを生成するモジュール生成手段と、上記モジュールを固定長を有するブロックに分割する分割手段と、上記ブロックに分割されたデータから、DDBメッセージを生成するDDBメッセージ生成手段と、上記モジュールを識別するための情報、当該モジュールの大きさ及びモジュールのバージョンを示す情報を含んでいるDIIメッセージを生成するDIIメッセージ生成手段と、上記DDBメッセージ及びDIIメッセージをトランスポートストリームに変換して、パケット化し、さらに、少なくともチャンネルリストを含むNITとチャンネルごとの情報であるPMTとを含むパケット化されたPSIとともに多重化し、周期的且つ繰り返し送出するカルーセル方式を使って伝送する伝送手段とを備えるデータ伝送装置。」 2 補正の適合性 (1)補正の目的本件補正は、特許請求の範囲の減縮を目的とするものである。理由は以下のとおりである。補正前の請求項1及び請求項2の「上記モノメディアデータ」を、補正後の請求項1及び請求項2の「ダウンロードのためのGUI情報を含んでいる上記モノメディアデータ」とする補正は、「上記モノメディアデータ」を限定していると認められるから、特許請求の範囲の減縮に相当する。 (2)独立特許要件上記のとおり本件補正は特許請求の範囲の減縮を目的としているので、本件補正後における発明が特許出願の際独立して特許を受けることができるものであるか否かを、以下に検討する。 (3)補正後発明補正後の請求項1及び請求項2に係る発明のうち請求項1に係る発明(以下「補正後発明」という。)は、補正後の特許請求の範囲の請求項1に記載された以下のとおりのものである。「データ受信装置にモノメディアデータを伝送する伝送方法において、ダウンロードのためのGUI情報を含んでいる上記モノメディアデータをDSM-CC方式に基づいてモジュールを生成し、上記モジュールを固定長を有するブロックに分割し、上記ブロックに分割されたデータから、DDBメッセージを生成し、上記モジュールを識別するための情報、当該モジュールの大きさ及びモジュールのバージョンを示す情報を含んでいるDIIメッセージを生成し、上記DDBメッセージ及びDIIメッセージをトランスポートストリームに変換して、パケット化し、さらに、少なくともチャンネルリストを含むNITとチャンネルごとの情報であるPMTとを含むパケット化されたPSIとともに多重化し、周期的且つ繰り返し送出するカルーセル方式を使って伝送するデータ伝送方法。」 (4)刊行物1の記載原査定の拒絶の理由に引用された「L.Atzori, F.G.B.De Natale, M.Di Gregorio, D.D.Giusto,“Multimedia information broadcasting using digital TV channels”,IEEE TRANSACTIONS ON BROADCASTING,1997年 9月,VOL. 43, NO. 3,pp242-251」(上記引用文献1、以下「刊行物1」という。)には、「Multimedia Information Broadcasting Using Digital TV Channels」〔訳:TVチャンネルを使用したマルチメディア情報放送〕(タイトル)に関し、図面と共に次に掲げる事項が記載されている。〈Abstract〉〔訳:要約〕 (あ)「In this paper, the structure of a new system to broadcast multimedia information within a digital TV channel is outlined. The proposed scheme is based on the DSM-CC functions, and uses a newly developed protocol that allows to efficiently convey multimedia information. Such information has the same characteristics of HTML files used in WWW environments, as it may contain text, images, sounds and animation organized as an hypertext. 」(242頁左欄1?9行) 〔訳:この論文では、デジタルTVチャンネルの内でマルチメディア情報を放送する、新システムの構造が概説されます。提案されたスキームは、DSM-CC機能に基づき、効率的にマルチメディア情報を伝えることを可能にする新しく開発されたプロトコルを使用します。そのような情報には、それがハイパーテキストとして構成されたテキスト、イメージ、音およびアニメーションを含んでいるかもしれないから、WWW環境の中で使用されるHTMLファイルの同じ特性があります。〕 (い)「The transport structure used is the MPEG-2 Transport Stream, which is the most popular standardized platform for the development of new digital TV services. A prototype software was developed to encode the file system by means of DSM-CC operations and include it in a MPEG-2 compatible Transport Stream.」(242頁左欄10?16行) 〔訳:使用されるトランスポート構造はMPEG-2トランスポートストリームです。それは、新しいデジタルTVサービスの開発用の最もポピュラーな標準化されたプラットフォームです。プロトタイプソフトウェアは、DSM-CCオペレーションによるファイルシステムをエンコードし、かつMPEG-2の互換性をもつトランスポートストリームにそれを含めるために開発されました。〕〈2. MPEG-2 AND PRIVATE DATA TRANSMISSION 〉〔訳:2. MPEG-2とプライベートデータの伝送〕 (う)「MPEG has defined the syntax for audio/video coding as a transport structure, in order to combine different bitstreams and to convey the synchronization of audio/video signals. Two transport structures have been provided for the system coding layer, where only the Transport Stream (TS) is suitable for television broadcasting. Such a structure allows to multiplex in a single bitstream different MPEG audio and video signals, as well as every other type of digital stream anyway defined; these data are referred to as private data. This allows new elementary streams to be handled at the transport layer without modifying the hardware, and gives the opportunity to implement additional services inside the digital TV channel. 」(243頁右欄8?21行) 〔訳:MPEGは、異なるビットストリームを組み合わせて、かつオーディオ/ビデオ信号の同期を伝えるためにオーディオ/ビデオ・コーディング用のシンタクスをトランスポート構造として定義しました。2つのトランスポート構造がシステムコーディング層に提供されました。そこでは、トランスポートストリーム(TS)だけがテレビジョン放送に適しています。そのような構造は、単一のビットストリーム中で異なるMPEGオーディオおよびビデオ信号を多重化することを可能にし、同様に、デジタルストリームの他のどのタイプも定義されています;これらのデータはプライベートデータと呼ばれます。これは、新しいエレメンタリストリームがハードウェアを修正せずに、トランスポート層で扱われることを可能にし、デジタルTVチャンネルの内部の追加サービスをインプリメントする機会を与えます。〕 (え)「A digital version of teletext has been already standardized by ETSI, through the definition of the syntax to insert data within the Transport Stream. Furthermore, the sixth part of the ISO/IEC 13818 describes a global server-network-client system, and defines the relevant bitstream syntax for the implementation of additional broadcast and interactive multimedia services. This is the Digital Storage Media Command and Control (DSM-CC) specification, concerning a set of protocols that provide the specific control functions and operations to manage an ISO/IEC 13818 bitstream (although the concepts and protocols do apply to more general situations). The system developed and presented in this paper is aimed at conveying multimedia information within the MPEG-2 Transport Stream, by making use of the DSM-CC features and by introducing a service that is similar in some way to the World- Wide-Web (WWW) information system available on Internet. Focus of the paper is on the definition of a protocol that rules the insertion, within the MPEG transport structure, of files linked each other to form a hypertext (analogous to an hypertext mark-up language, HTML, documents). A software simulation of coding-transmission-decoding process has been already developed and is described in the following; the simulation has been carried out through the creation of a client-server architecture managed by two processes running on remote UNIX workstations. Such processes are connected through a socket interface, which is used by the first process (server) to transmit on request the packetized information included into the transport stream, and by the second one (client)to receive the encoded data.」(244頁左欄1?36行) 〔訳:文字放送のデジタルバージョンは、トランスポートストリームの内のデータを挿入するシンタクスの定義によって、ETSIによって既に標準化されています。更に、ISO/IEC 13818の6番目の部分はグローバルなサーバ-ネットワーク-クライアント・システムについて記述し、付加放送およびインタラクティブ・マルチメディア・サービスのインプリメンテーションのための適切なビットストリームシンタクスを定義します。これは、デジタル蓄積メディアコマンドアンドコントロール(DSM-CC)仕様書です。この仕様書は、ISO/IEC 13818ビットストリーム(概念とプロトコルはもっと一般的な状況に当てはまるが)を利用するために特定の制御機能およびオペレーションを提供する1セットのプロトコルに関するものです。この論文中で開発され示されたシステムは、DSM-CC特徴の利用により、およびインターネットで利用可能なワールドワイドウェブ(WWW)の情報システムのある方法に類似したサービスを導入することにより、MPEG-2トランスポートストリームの内でマルチメディア情報を伝えることを目指します。コーディング-トランスミッション-デコーディング・プロセスのソフトウェアシミュレーションは既に開発されており、下記に述べられています;シミュレーションは、遠隔のUNIXワークステーション上で走る2つのプロセスによって管理されたクライアント-サーバ・アーキテクチャの生成によって実行されました。そのようなプロセスはソケットインターフェースを通って接続されます。それは、トランスポートストリームへ含まれた、パケットになった情報を要求があり次第送信する、第1のプロセス(サーバ)、およびエンコードされたデータを受け取る第2のもの(クライアント)によって使用されます。〕〈3. HYPERTEXTUAIL INFORMATION SYSTEM BROADCASTING〉〔訳:3. ハイパーテキストの情報システム放送〕 (お)「A hypertext consists of a group of different documents connected to each other via hyperlinks. From the structural viewpoint, a hypertext is comparable to a database where the user can jump from a record to another if they are connected either by a direct link (e.g., a common element) or by other adjacency relations (e.g., consecutive pages in an electronic book). Most of the hypertextual systems allow the generation of multimedia documents, which can include textual information as well as other types of data, like drawings, images, video, animation, and so on. Each of these objects, entirely or partly, can become a link within the hypertext.」(244頁左欄39?52行) 〔訳:ハイパーテキストは、ハイパーリンクによって互いに接続された異なるドキュメントのグループからなります。構造の観点から見ると、ハイパーテキストはデータベースに匹敵します。そのデータベースにおいては、レコードが直接のリンク(例えば共有部分)、あるいは他の連接関係(例えば電子ブック中の連続するページ)によって接続される場合、ユーザがレコードから別のものまでジャンプすることができる。ほとんどのハイパーテキストのシステムは、図面、イメージ、ビデオ、アニメーションなどのように、マルチメディア・ドキュメント(それらは他のタイプのデータと同様に本文の情報も含んでいるかもしれない)の生成を許可します。これらのオブジェクトの各々は完全にあるいは部分的に、ハイパーテキストの内のリンクになることができます。〕 (か)「For the purpose of our work, we refer to the WWW database structure, where each web is made up of HTML files and can include images of different kinds, as well as audio/video sequences. The main characteristic of the WWW database is that it branches out in several local hypertexts, which are separate open systems. This feature can not be directly implemented in a broadcast application, for in this case every transmitted document must be a closed web, that is it must contain every link, as it is not foreseen a return channel for a complete interaction. The implementation of such a service, therefore, requires the whole web file system to be sent, taking care to rebuild, at the client side, a new path for every file in order to preserve its links.」(244頁左欄53行?右欄13行) 〔訳:私たちの研究の目的のために、各々のウェブがHTMLファイルから構成され、オーディオ/ビデオ・シーケンスと同様に異なる種類のイメージを含むことができる、WWWデータベース構造に言及します。WWWデータベースの主な特性は、それがいくつかのローカルのハイパーテキスト中で分かれるということです。いくつかのローカルのハイパーテキストは個別のオープンシステムです。この特徴は、直接放送のアプリケーションにインプリメントすることができません。この場合、すべての送信されたドキュメントはクローズドウェブでなければならない。完全な相互作用のためのリターンチャンネルを予知されるものではないから、クローズドウェブはすべてのリンクを含まなくてはならない。そのようなサービスのインプリメンテーションは、したがって、そのリンクを保存するためにクライアント側で、すべてのファイル用の新しいパスを再建するように注意して、送られる全てのウェブ・ファイルシステムを要求します。〕 (き)「The target service to be offered is a cyclic transmission of a set of file systems (data carousel), where the user can download the webs he is interested in. In order to provide the user with sufficient information to make this selection, the data carousel has to include, within the multimedia data, a directory mechanism that describes the information of the carousel and provides a procedure to group the information.」(244頁右欄14?22行) 〔訳:提示される目標のサービスは、1セットのファイルシステムの周期的な送信(データカルーセル)です。そこでは、ユーザは、彼が興味を持っているウェブをダウンロードすることができます。この選択をするためにユーザに十分な情報を提供するために、データカルーセルは、マルチメディア・データ内に、カルーセルの情報について記述し、情報をグループ化するために手続きを提供するディレクトリメカニズムを含んでいなければなりません。〕〈4. THE BROADCAST DSM-CC DOWNLOAD FUNCTION〉〔訳:4. 放送DSM-CCダウンロード機能〕 (く)「The DSM-CC specification provides a set of protocols to implement different applications such as movie-on-demand, tele-shopping, news-on-demand, remote database access, and so on. To this end, several functions are defined, based on the exchange of messages between the network and the user or between two users. The main characteristic of this syntax is that it does not specify the underlying physical, data-link and transport layers of the global protocol stack. It is intended to provide a unified signalling layer over a wide variety of underlying network topologies.」(244頁右欄24?35行) 〔訳:DSM-CC仕様書は、ムービー-オン-デマンド、テレショッピング、ニュース-オン-デマンド、遠隔データベースアクセスなどの異なるアプリケーションを実行するために1セットのプロトコルを提供します。この目的のために、いくつかの機能は、ネットワークとユーザ、あるいは2人のユーザの間のメッセージの交換に基づいて定義されます。このシンタクスの主な特性は、グローバルなプロトコル・スタックの基本的な物理層、データリンク層およびトランスポート層を指定しないということです。それは、種々様々の基礎となるネットワークトポロジー上の一体になったシグナリング層を提供するように意図されます。〕 (け)「A particular feature of DSM-CC is the download function, which is intended to provide a very lightweight and fast data or software server-to-client download, or network-to-client download. Furthermore, flow-controlled operation and broadcast download are supported, based on the same message set. A complete download operation transfers an "image" data, which is made up of logically separated sections named modules. In order to meet the transmission constraints, such as bit-error rates and maximum transport packet size, each module is then divided into blocks, all with the same size. The overall operation is made up of six messages, which are divided into control messages and data messages; the former are used for setting up the transmission parameters, while the latter convey user information.」(244頁右欄36?52行) 〔訳:DSM-CCの特別の特徴は、ダウンロード機能である。そのダウンロード機能は非常に軽量で速いデータあるいはソフトウェア・サーバー-クライアント・ダウンロードあるいはネットワーク-クライアント・ダウンロードを提供するように意図される。更に、フローコントロールされるオペレーションおよび放送ダウンロードは同じメッセージセットに基づいて支援されます。完全なダウンロード・オペレーションは「イメージ」データを転送します。それはモジュールという名の論理上分離されたセクションから構成されます。ビット誤り率および最大のトランスポートパケットサイズのようなその送信制約を満たすために、各モジュールは同じサイズのブロックに分割されます。全般的なオペレーションは6つのメッセージから構成されます。それはコントロールメッセージおよびデータメッセージに分割されます;前者は送信パラメータのセットアップのために使用され、後者はユーザ情報を伝えます。〕 (こ)「Since our interest is focused onto broadcast transmission, only two messages have to be used in this application. The download parameters are provided by the DownloadInfoResponse message that is sent by the download server to set up the connection; after the connection has been set up, the data blocks are conveyed by the DownloadDataBlock message. The DownloadInfoResponse message contains information about identification of the download session (downloadId), block size, number of modules that compose the image, and specific information on each module. Moreover, the syntax allows to introduce user-defined parameters relevant to the specific application. After the reception of this message, the client is ready to receive and to parse the data messages. The DownloadDataBlock message contains a single block of the download image, and conveys some additional information (encoded within the header of the message) regarding the identity of the module to which it belongs, the version of the data, and the block number.」(244頁右欄53行?245頁左欄20行) 〔訳:私たちの関心が放送送信に集中するので、このアプリケーションの中で2つのメッセージだけを使用しなければなりません。ダウンロードパラメータは、接続をセットアップするためにダウンロードサーバによって送信されるDownloadInfoResponseメッセージによって提供されます;接続がセットアップされた後、データブロックはDownloadDataBlockメッセージによって伝えられます。DownloadInfoResponseメッセージは、ダウンロードセッションの識別(downloadId)、ブロックサイズ、イメージを構成するモジュールの数および各モジュールに関する具体的情報に関する情報を含んでいます。さらに、シンタックスは、特定のアプリケーションに関連するユーザ定義のパラメータを導入することを可能にします。このメッセージの受理の後、クライアントは、受け取り、かつデータ列を解析する準備ができています。 DownloadDataBlockメッセージは、ダウンロードイメージの1つのブロックを含んでおり、それが属するモジュールの同一性、データのバージョンおよびブロック番号に関する追加情報(メッセージのヘッダ内にエンコードされた)を伝えます。〕〈5. THE CODING LAYER STRUCTURE〉〔訳:5. コーディング層構造〕 (さ)「The hypertext coding and transmission are implemented using three layers. The first layer has been introduced to convey specific information about each file, such as the name and the path. This information is necessary for the correct rebuilding of the file system, so that every link is preserved. The second layer provides the functions necessary to set up the connection and to transmit the files to the client. For this purpose the DSM-CC download message structure has been adopted in order to obtain a stream compatible with a generic DSM-CC parser. This choice increases the application portability, at the cost of a slight overhead (due to some unnecessary fields in the command syntax). The third layer is the transport layer, which is the standard MPEG-2 Transport Stream. The following sections provide some design details of the above defined three layers. To ease the comprehension of the protocol syntax, some tables are reported, which make use of the syntax description convention defined in the ISO/ IEC13818 document.」(245頁左欄22?42行) 〔訳:ハイパーテキスト・コーディングおよび送信は3層を使用して実行されます。第1層は名前とパスのような各ファイルに関する具体的情報を伝えるために導入されました。この情報はファイルシステムを正確に再建することために必要です。その結果、すべてのリンクが保存されています。第2層は接続をセットアップし、かつクライアントにファイルを送信するのに必要な機能を提供します。この目的のために、DSM-CCダウンロード・メッセージ構造は総括的なDSM-CCパーザと互換性をもつストリームを得るために採用されました。この選択は、少しのオーバーヘッド(コマンド・シンタクスのいくつかの不必要なフィールドによる)のコストで、アプリケーション・ポータビリティを増加させます。第3層は、標準のMPEG2トランスポートストリームである、トランスポート層です。次のセクションは上記のいくつかの設計詳細に3つの定義された層を供給します。プロトコル・シンタクスの理解を緩和するために、いくつかのテーブルは報告されます。それはISO/IEC13818のドキュメントに定義されたシンタクス記述規則の使用します。〕 (し)「A The file section The file_section is a structure that encapsulates the file. It has been structured in order to include basic file information in the data file. Table I shows the syntax of the file_section; the name_length field contains the length in bytes of the following field file_name (name of the data file, as an ASCII string). The path_code contains the information to uniquely identify the path of each data file (necessary to the hyper-linking operation); since such information is extremely space consuming, a unique code is associated to each path used in the file system. At the decoder, the path-code field is used as an index in a look-up table (LUT), previously sent to the client within a DSM-CC message. 」(245頁左欄43行?右欄6行) 〔訳:A ファイル・セクション file_sectionはファイルをカプセル化する構造です。それはデータ・ファイルに基本的なファイル情報を含むために組み立てられました。テーブルIは、file_sectionのシンタクスを示します;name_lengthフィールドは、次のフィールドfile_name(データ・ファイルの名前、ASCIIストリングとして)のバイトに長さを含んでいます。path_codeは、ユニークに各データ・ファイル(ハイパーリンク処理に必要)のパスを識別するための情報を含んでいます;そのような情報が非常にスペース消費であるので、ユニークなコードはファイルシステムの中で使用される各パスに関連させられます。デコーダでは、path_codeフィールドは以前にDSM-CCメッセージ内でクライアントに送られて、ルックアップテーブル(LUT)の中でインデックスとして使用されます。〕 (す)「Table I. File_section syntax (ISO/IEC 13818 syntax description convention)」〔訳:テーブルI File_sectionシンタクス(ISO/IEC 13818シンタクス記述規則)〕「」 (せ)「Table II. DownloadInfoResponse syntax (ISO/IEC 13818 syntax description convention)」〔訳:テーブルII DownloadInfoResponseシンタクス(ISO/IEC 13818シンタクス記述規則)〕「」 (そ)「B The download layer A complete download operation transfers a web to a client, where each file of the web is a module of the download session. Table II shows the syntax of the DownloadInfoResponse message, where some additional fields were introduced for obeying the message syntax constraints. Furthermore, to the fields having values that are constant or not significant for the application, pre-defined values were assigned; as a matter of fact, these fields could not be removed from the message in order to be correctly parsed by a DSM-CC decoder.」(245頁右欄下から5行?246頁左欄7行) 〔訳:B ダウンロード層完全なダウンロード・オペレーションはクライアントにウェブを転送します。そこでは、ウェブの各ファイルがダウンロード・セッションのモジュールである。テーブルIIはDownloadInfoResponseメッセージのシンタクスを示します。そこでは、いくつかの追加のフィールドがメッセージ・シンタックス制約に従うために導入されています。更に、一定か、又はアプリケーションにとって重要な意義を持たない値を持っているフィールドへ、あらかじめ定義された値は割り当てられました;実際、正確にDSM-CCデコーダによって解析されるためにはメッセージからこれらのフィールドは撤去することができないかもしれません。〕 (た)「The DownloadInfoResponse starts a download session by conveying some general information about the session and specific information related to each module. The downloadId is a 4-byte long field that identifies the download session. The field following the downloadId one conveys the length of each block for the present download session; in our application, the adopted size was 4018 bytes, which is the maximum size allowed by the transport layer (each download message is encapsulated in packets with maximum dimension of 4 Kbytes). This choice has been done in order to minimize the overhead due to the transmission of the header. Each module is associated to an identifier, called the moduleId, which must be unique within one download session. Moreover, the size of the module and its version number must be transmitted. The former (moduleSize field) allows the decoder to identify the end of the data messages, the latter (moduleVersioin field) gives the client a tool to detect image coherency problems. Such problems may arise when the transmitter is updating the information, so that the module has a version that is not consistent with that of the image. In this case, the client can abort the download operation and restart it in a successive cycle.」(246頁左欄8?33行) 〔訳:DownloadInfoResponseは、各モジュールと関係するセッションおよび具体的情報に関するある一般的な情報を伝えることにより、ダウンロード・セッションを始めます。downloadIdはダウンロード・セッションを識別する4バイト長のフィールドです。downloadId フィールドに続くフィールドは、現在のダウンロード・セッションの各ブロックの長さを伝えます;私たちのアプリケーションでは、採用されたサイズは4018バイトで、それはトランスポート層(各ダウンロード・メッセージは4Kbytesの最大の次元を備えたパケット中でカプセルに入れられます)によって許可された最大サイズです。この選択はヘッダの送信により諸経費を最小化するために行われました。各モジュールはmoduleIdと呼ばれる識別子に関連させられます。それは1つのダウンロード・セッション内でユニークでなければならない。さらに、モジュールのサイズとそのバージョン番号は送信されなければならない。前者(moduleSizeフィールド)は、デコーダがデータメッセージのエンドを識別することを可能にします。後者(moduleVersioinフィールド)は、クライアントにイメージ統一問題を検知するツールを与えます。発信機が情報をアップデートしている場合、そのような問題が生じるかもしれません。その結果、モジュールにはイメージのそれと一致していないバージョンがあります。この場合、クライアントはダウンロード・オペレーションを終了させて、連続のサイクルにそれを再開することができます。〕 (ち)「Finally, the original message syntax gives the opportunity to introduce a user-defined moduleInfo field, whose length is coded in the moduleInfoLength field. We used the moduleInfo field to send specific information for each module file, that is the compression state (compression_flag) and the file type (type-code). The former is a 1-bit field that is set to 1 when the file has been compressed (this could happen for a HTML document, in order to reduce the bitrate required for the transmission). The latter is a 6-bit field that conveys the file type, represented by one of the codes reported in Table III. Finally, the message conveys a privateData field that contains general private information about the image. We used this field to introduce the path-description, which provides the tree structure of the file system on a pre-order transversal method. The description given for each node is related to the directory name length (coded in 1 byte), the directory name, and the path code (also coded in 1byte). After the node description, another directory_name_length is expected if the last node is not a leaf, otherwise a back-code of zero value is introduced. The back-code indicates that the next node is located one step back in the path. The end of the description is given by the privateDataLength. As an example, Figure 2 shows an easy tree structure with the corresponding path description fields.」(246頁左欄下から8行?右欄20行) 〔訳:最後に、オリジナルのメッセージ・シンタクスは、ユーザ定義のmoduleInfoフィールドを導入する機会を与えます。その長さはmoduleInfoLengthフィールドでコード化されます。私たちは、各モジュール・ファイル具体的情報(それは圧縮状態(compression_flag)およびファイル・タイプ(type_code)である)を送るためにmoduleInfoフィールドを使用しました。前者は、ファイルが圧縮された場合(これは送信に必要なビット・レートを縮小するためにHTMLドキュメントのために起こるかもしれません)、1にセットされる1ビットのフィールドです。後者は、テーブルIIIの中で報告されたコードのうちの1つによって表わされて、ファイル・タイプを伝える、6ビットのフィールドです。最後に、メッセージは、イメージに関する一般的なプライベート情報を含んでいるprivateDataフィールドを伝えます。私たちは、path_descriptionを導入するためにこのフィールドを使用しました。それは、プレ-オーダ・トランスバーサル方法のファイルシステムのツリー構造を提供します。各ノードに対し与えられた記述は、ディレクトリ名長さ(1バイトでコード化した)、ディレクトリ名およびパス・コード(同じく1バイトでコード化した)と関係があります。ノード記述の後に、最後のノードがリーフでない場合、別のdirectory_name_lengthが期待されます。そうでなければ、0の値のバックコードが導入されます。バックコードは、次のノードがパスにおいて1ステップ後ろに位置することを示します。記述の終了はprivateDataLengthによって与えられます。例として、図2は、対応するパス記述フィールドを備えた容易なツリー構造を示します。〕 (つ)「Once the client has received the whole DownloadInfoResponse message, he is able to parse the data messages and to build the file system through the DownloadDataBlock messages, whose syntax is shown in Table IV. In order to identify the module to which the block belongs, the module identity is transferred; if it is not equal to the moduleId sent in the control message, an error is detected. Also the identity of the subsequent field (i.e., the moduleVersion) must be the same of the control message. The blockNumber is used for numbering the blocks of the module, starting from zero for each module. Finally, the block data are sent in the blockDataBytes field; the relevant size (in bytes) is defined in the field blockSize, and is equal for all blocks but the last, which may be shorter.」(246頁右欄下から12行?247頁4行) 〔訳:一旦クライアントが全体のDownloadInfoResponseメッセージを受け取ったならば、彼はデータ列を解析することができ、DownloadDataBlockメッセージによってファイルシステムを組み立てます。そのシンタクスはテーブルIVの中で示されます。ブロックが属するモジュールを識別するために、モジュール同一性は転送されます;それがコントロール・メッセージ中で送られたmoduleIdと等しくない場合、エラーが検知されます。さらに、後のフィールド(つまりmoduleVersion)の同一性はコントロール・メッセージの同じであるに違いありません。blockNumberは各モジュールのために0からスタートして、モジュールのブロックに番号を付けるために使用されます。最後に、ブロック・データはblockDataBytesフィールドで送信されます;適切なサイズ(バイトで)はフィールドblockSizeに定義されており、短いかもしれない最後のものを除いてすべてのブロックには等しい。〕 (て)「Table IV. DownloadDataBlock syntax.」〔訳:テーブルIV DownloadDataBlock シンタクス〕「」 (と)「Table V. DSM-CC download message header format.」〔訳:テーブルV DSM-CCダウンロード・メッセージ・ヘッダ・フォーマット〕「」 (な)「The DSM-CC download procedure requires also a further encapsulation of the message in a message header, as illustrated in Table V. This header contains information about the type of message being transmitted, as well as any adaptation data needed by the transport mechanism; this includes conditional access information required to decode the data. The first field is used to indicate that the message is a MPEG-2 DSM-CC message. Then, the dsmccType specifies the type of message, and provides also the messageId, which indicates the type of the message that has been sent. The messageId can assume two values, i.e. 0x1002 and 0x1003. The former is associated to the DownloadInfoResponse, while the latter indicates a DownloadDataBlock. The successive is the downloadId, which is used for aspects related to the download session integrity, and correlates the DownloadDataBlock with the download control messages. Finally, the messageLength field is used to indicate the total length of the message following the general message header. The adaptationLength has been set to 0, for no adaptation field is used.」(247頁左欄下から18行?右欄4行) 〔訳:テーブルVで示されるように、DSM-CCダウンロード手続きはメッセージヘッダ中のメッセージの一層のカプセル化も要求します。このヘッダは、トランスポートメカニズムによって必要とされる任意の適応データと同様に送信されているメッセージのタイプに関する情報からなる;これは、データをデコードするのに必要な条件アクセス情報を含んでいます。最初のフィールドはメッセージがMPEG-2 DSM-CCメッセージであることを示すために使用されます。dsmccTypeは、メッセージのタイプを指定し、messageIdも提供します。それは、送信されたメッセージのタイプを示します。messageIdは2つの値、例えば0x1002、0x1003、をとる。前者はDownloadInfoResponseに関連し、後者がDownloadDataBlockを示している。続くものは、downloadId(それはダウンロード・セッション保全と関係する様相に使用される)で、DownloadDataBlockをダウンロード・コントロール・メッセージと関連させます。最後に、messageLengthフィールドは一般的なメッセージヘッダに続くメッセージの長さの合計を示すために使用されます。adaptationLengthは0にセットされました。というのは、適応フィールドは使用されないからです。〕 (に)「C The Transport Layer As already mentioned, the DSM-CC functions are designed to be transport-independent, so as not to be affected by the transport layer; only major constraints concerning the reliability of the data are defined, in order to ensure error detection and rejection of corrupted messages. The MPEG-2 Transport Stream (TS) is a transport layer suitable for this application, as it provides the means for multiplexing the download message data within the MPEG-compressed audio and video streams. Although none of the messages are required to be carried within an MPEG-2 TS, if this transport structure is used the messages may be encapsulated inside a dsmcc_section that inherits all of the MPEG-2 private section syntax. In this section, a single download message is carried each time, with a maximum size of 4 Kbytes. No particular field must be encoded in the private section header but the table_ id, which must be set to the exadecimal value "3B". This field is used to identify the table among other similar tables conveyed within the TS. Each different stream to be multiplexed within the TS is referred to as an elementary stream. During multiplexing, each elementary stream is subdivided into transport packets (TP) with fixed dimension (188 bytes). These packets consist of two parts, the packet header (4 bytes) and the payload containing the elementary stream data. Summarizing, the most significant fields are: - sync_byte: it is an 8-bits field with a fixed value of '01000111' (0x47), used for synchronizing the encoder and the decoder; - packet_ideittity_ituinber (PID): it is a 13-bits field that uniquely identifies the elementary stream carried within the TS packet. Some values are reserved for a particular type of data. - continuity_counter: it is a 4-bits field used for sequence numbering. It is incremented with each Transport Stream packet having the same PID. Two conditions have to be respected, as the first byte of each private section must be the first byte of a transport packet payload, and every TS packet must contain data coming from one private section only. 」(247頁右欄5?49行) 〔訳:C トランスポート層既に言及されていたように、DSM-CC機能はトランスポート層によって影響されないように伝送と独立するようにデザインされる;データの信頼度に関する主な制約だけが悪くなったメッセージのエラー検出および拒絶を保証するために定義されます。 MPEG-2トランスポートストリーム(TS)はこのアプリケーションに適しているトランスポート層です。なぜなら、それがMPEGを圧縮したオーディオおよびビデオストリーム内のダウンロード・メッセージ・データを多重化するための手段を提供するからです。メッセージはMPEG-2 TSの内に運ばれることは要求されませんが、もしこのトランスポート構造が使用されるならば、メッセージは、MPEG-2のプレイベートセクションシンタクスをすべて継承するdsmcc_sectionの内部でカプセル化されるかもしれません。このセクションでは、単一のダウンロード・メッセージは各時間に4Kbytesの最大サイズで運ばれます。特別のフィールドがプライベートセクションヘッダの中でエンコードされるのではなく、table_idがエンコードされてはなりません。そのtable_idはexadecimal[注:hexadecimalの誤り。16進の]値「3B」にセットされなければならない。このフィールドはTSの内に伝えられた他の同様のテーブル中にテーブルを識別するために使用されます。 TSの内に多重化される異なるストリームはそれぞれエレメンタリストリームと呼ばれます。多重化中に、各エレメンタリストリームは固定の次元(188バイト)でトランスポートパケット(TP)へ細分されます。これらのパケットは、2つのパートからなり、パケットヘッダ(4バイト)、およびエレメンタリストリームデータを含んでいるペイロードから成ります。要約して、最も重要なフィールドは次のとおりです; - sync_byte:それは、エンコーダとデコーダを同期させるために使用された「01000111」(0x47)の固定値を備えた8ビットのフィールドです; - packet_identity_number(PID):TSパケットで運ばれたエレメンタリストリームをユニークに識別する13ビットのフィールドです。いくつかの値は特別のタイプのデータのために取っておかれます。 - continuity_counter:それはシーケンスナンバリングに使用された4ビットのフィールドです。それは同じPIDがある各トランスポートパケットでインクリメントされます。各プライベートセクションの最初のバイトがトランスポートパケットペイロードの最初のバイトでなければならないので、2つの条件を尊重しなければなりません。また、すべてのTSパケットは、1つのプライベートセクションのみから来るデータを含んでいるに違いありません。〕 (ぬ)「In a TS, several elementary streams are multiplexed together, each one identified by a PID. Moreover, elementary streams can be grouped together into programs (e.g., the elementary streams containing the audio and the video information of a movie). For this reason, the decoder requires additional information to distinguish the streams included in a program, and to identify the list of programs conveyed within the TS. This information is called Program Specific Information (PSI) and includes a Program Association Table (PAT), as well as a Program Map Table (PMT). The PAT lists all the programs in a transport stream; its position in the stream can be easily located by the decoder, for the TS packets containing the PATS have PID equal to zero. For each program, the PAT gives the PID of the TS packets containing the PMT (each program has a specific PMT). Then each PMT gives specific information about the relevant program and specifies each elementary stream being part of the program. Several webs may be conveyed in a TS, and each download session makes a program of only one elementary stream. Hence, different PID values are assigned to each download session. 」(247頁右欄50行?248頁左欄19行) 〔訳:TSでは、いくつかのエレメンタリストリームはともに多重化され、各エレメンタリストリームはPIDによって識別されます。さらに、エレメンタリストリームはプログラム(例えば映画のオーディオおよびビデオ情報を含んでいるエレメンタリストリーム)へ一まとめにすることができます。この理由で、デコーダは、プログラムに含まれたストリームを識別し、かつTSの内に伝えられたプログラムのリストを識別するために追加情報に要求します。この情報はプログラムスペシフィックインフォメーション(PSI)と呼ばれ、プログラムマップテーブル(PMT)と同様にプログラムアソシエーションテーブル(PAT)を含んでいます。PATは、トランスポートストリームのプログラムをすべてリストします;ストリームのその位置は、容易にデコーダによって位置することができます。というのは、PATを含んでいるTSパケットには0に等しいPIDがあるからです。各プログラムについては、PATは、PMT(プログラムにはそれぞれ特定のPMTがあります)を含んでいるTSパケットのPIDを与えます。その後、PMTはそれぞれ、適切なプログラムに関する具体的情報を与えて、プログラムの一部である各エレメンタリストリームを指定します。いくつかのウェブはTSの中で伝えられるかもしれません。また、ダウンロード・セッションはそれぞれ、たった1つのエレメンタリストリームのプログラムを作ります。従って、異なるPID値は各ダウンロード・セッションに割り当てられます。〕〈6. SIMULATION OF HYPERTEX TRANSMISSION〉〔訳:6. ハイパーテキスト送信のシミュレーション〕 (ね)「In order to simulate the transmission of a hypertext according to the ISO-13818 specifications, we used two UNIX workstations linked together by a LAN. It simulates a distributed application based on a client/server model, where the server implements the encoder that delivers transport packets in response to a client (decoder) calling for a connection. To this end, both a software encoder and a prototype of the corresponding decoder have been implemented. The web data are encoded and multiplexed, by employing the DSM-CC download protocol, so generating a Transport Stream. The decoding process de-multiplexes the stream and rebuilds the file system of the received hyper-document. The two processes communicate by means of a stream socket in the Internet domain.」(248頁左欄20行?右欄5行) 〔訳:ISO-13818仕様書によるハイパーテキストの送信をシミュレートするために、私たちは、LANによってともにリンクした2台のUNIXワークステーションを使用しました。それは、クライアント/サーバ・モデルに基づいた配達されたアプリケーションをシミュレートします。そこで、サーバが接続を要求するクライアント(デコーダ)に応じてトランスポートパケットを運ぶエンコーダをインプリメントする。この目的のために、ソフトウェアエンコーダおよび対応するデコーダのプロトタイプの両方はインプリメントされました。ウェブデータはDSM-CCダウンロード・プロトコルの使用し、トランスポートストリームを生成することにより、エンコードされ多重化されます。デコードするプロセスはストリームを逆多重化し、受信したハイパードキュメントのファイルストリームを再建する。2つのプロセスはインターネットドメインのストリームソケットによって通信します。〕 (の)「A The encoding algorithm The algorithm developed for the simulation of a Transport Stream encoder essentially analyses the directory structure of the hypertext to be transmitted, and executes the multiplexing by inserting all the necessary information. The file systems belonging to the webs to be multiplexed are placed in different "root" directories. The operation of multiplexing data coming from different webs is performed by the encoder through a cyclic scanning of data coming from different file systems, and by assigning equal priority to each web; the operation terminates when all the files have been sent. At the end of one operation, the broadcasting cycle is restarted; this simulates a real application in which all the multimedia information is continuously refreshed, allowing for a real-time updating. This continuous updating of information is particularly useful in certain applications, such as stock data exchange and distributed databases. Furthermore, it allows the user to receive data in every moment, by decoding one of the refresh streams. A general layout of the implementation of the encoding process is presented in Figure 3. In order to assure a high flexibility, a configuration file was introduced, which provides the input data for the encoder; in particular, they consist in the number of webs to be multiplexed, the index of the files belonging to each web, and the "root" directories associated to these webs.」(248頁左欄6行?249頁右欄6行) 〔訳:A 符号化アルゴリズムトランスポートストリームエンコーダのシミュレーションのために本質的に開発されたアルゴリズムは、送信されるハイパーテキストのディレクトリ構造を分析し、必要な情報すべての挿入により多重化を実行します。多重化されるウェブに属するファイルシステムは、異なる「ルート」ディレクトリに置かれます。異なるウェブから来るデータを多重化するオペレーションは、異なるファイルシステムから来るデータの周期的な走査によるエンコーダによって、および各ウェブに等しいプライオリティを付与することによって行なわれます;ファイルがすべて送られた場合、オペレーションは終了します。 1つのオペレーションの終わりに、放送サイクルは再開されます;これは、マルチメディア情報がすべてリアルタイムの更新を考慮に入れて、連続的にリフレッシュされる実際のアプリケーションをシミュレートします。情報の連続的に更新することは、ストック・データ交換および分散型データベースのようなあるアプリケーションに特に役立ちます。更に、それは、ユーザがすべての瞬間の中のデータを受け取ることをリフレッシュストリームのうちの1つのデコードにより可能にします。符号化プロセスのインプリメンテーションの一般的なレイアウトは図3に示されます。高い柔軟性を保証するために、コンフィグレーションファイルは導入されました。それはエンコーダに入力データを供給します;それらは、特に多重化されるウェブの数、各ウェブに属するファイルのインデックス、およびこれらのウェブに関連した「ルート」ディレクトリからなります。〕 (は)「This file can be substituted at every refreshing cycle, during program execution, with the purpose of simulating a real-time updating of the information being transmitted to the decoder. This is achieved by reading the configuration file name from an init file at the beginning of each cycle. Furthermore, this init file is useful in order to stop the program and consequently to suspend data transmission during the execution, by setting a particular flag. In Figure 4, the encoding scheme is shown. After reading both the init and the configuration files, the program performs the coding of the PSI sections. To each web a proper PID is assigned, by starting from the number 16 and by coding the PMT sections without any stream descriptor. As a result, PAT and PMT tables are packetized and multiplexed at the beginning of the Transport Stream. The following step consists in sending the DownloadInfoResponse message, in a private section, for each download session. Finally, the transmission of the files starts, by dividing the data file into blocks, and by coding them within the DownloadDataBlock messages. These messages are first encapsulated into the private section and after divided into 183 bytes sections (the first section) or 184 bytes sections in order to insert the data within the transport packet payload. At this point, the multiplexing is performed by getting a transport packet from a different web at each time.」(249頁右欄1?29行) 〔訳:このファイルはプログラム実行の間にすべてのリフレッシュするサイクルでデコーダに送信されている情報のリアルタイムに更新することをシミュレートする目的として置き換えることができます。これは各サイクルの始めにinitファイルからコンフィグレーションファイル名を読むことにより達成されます。更に、このinitファイルは特別のフラグのセットにより、プログラムを止めるために、そして実行の間にデータ伝送をサスペンドするために有用です。図4において、符号化スキームが示されています。initとコンフィグレーションファイルの両方を読んだ後に、プログラムは、PSIセクションのコーディングを行ないます。各ウェブに、適切なPIDは、No.16からスタートすることにより、およびストリームディスクリプタのないPMTセクションのコード化により割り当てられます。その結果、PATとPMTテーブルはトランスポートストリームの初めにパケット化され、多重化されます。次のステップは各ダウンロード・セッションのためにプライベートセクション中でDownloadInfoResponseメッセージの送信することからなります。最後に、ファイルの送信は、データ・ファイルをブロックに分割することにより、およびDownloadDataBlockメッセージ内にそれらをコード化することによりスタートします。これらのメッセージは、プライベートセクションへ最初にカプセルに入れられます。そして、トランスポートパケット・ペイロード内にデータを挿入するために183バイトのセクション(最初のセクション)あるいは184バイトのセクションに分割されます。このポイントでは、多重化は、毎時に異なるウェブからトランスポートパケットを得ることにより行なわれます。〕 (5)対比ア刊行物1に記載された発明刊行物1には、上記〈Abstract〉の記載から、「デジタルTVチャンネルの内でマルチメディア情報を放送する、新システムの構造」(上記(あ))が開示され、その「スキームは、DSM-CC機能に基づき、効率的にマルチメディア情報を伝えることを可能にする」「プロトコルを使用し」(上記(あ))、「そのような情報には、それがハイパーテキストとして構成されたテキスト、イメージ、音およびアニメーションを含むことができ、WWW環境の中で使用されるHTMLファイルの同じ特性があり」(上記(あ))、「使用されるトランスポート構造はMPEG-2トランスポートストリームで」(上記(い))あり、「プロトタイプソフトウェアは、DSM-CCオペレーションによるファイルシステムをエンコードし、かつMPEG-2の互換性をもつトランスポートストリームにそれを含めるため」(上記(い))のものである。「DSM-CC機能」は、上記〈4. THE BROADCAST DSM-CC DOWNLOAD FUNCTION〉の記載から、「DSM-CC仕様書は、ムービー-オン-デマンド、テレショッピング、ニュース-オン-デマンド、遠隔データベースアクセスなどの異なるアプリケーションを実行するために1セットのプロトコルを提供し」(上記(く))、「DSM-CCの特別の特徴は、ダウンロード機能であ」(上記(け))り、「完全なダウンロード・オペレーションは「イメージ」データを転送し」、「それはモジュールという名の論理上分離されたセクションから構成され」(上記(け))、「各モジュールは同じサイズのブロックに分割され」(上記(け))、「ダウンロードパラメータは、接続をセットアップするためにダウンロードサーバによって送信されるDownloadInfoResponseメッセージによって提供され」(上記(こ))、「接続がセットアップされた後、データブロックはDownloadDataBlockメッセージによって伝えられ」(上記(こ))、「DownloadInfoResponse」は、上記〈5. THE CODING LAYER STRUCTURE〉「B The download layer」の記載から、「各モジュールと関係するセッションおよび具体的情報に関するある一般的な情報を伝えることにより、ダウンロード・セッションを始め」(上記(た))、「各モジュールはmoduleIdと呼ばれる識別子に関連させられ」、「それは1つのダウンロード・セッション内でユニークでなければならな」(上記(た))く、「さらに、モジュールのサイズとそのバージョン番号は送信されなければならない」(上記(た))ものであり、「ハイパーテキスト」は、上記〈3. HYPERTEXTUAIL INFORMATION SYSTEM BROADCASTING〉の記載から、「ハイパーテキストは、ハイパーリンクによって互いに接続された異なるドキュメントのグループからなり」(上記(お))、「すべての送信されたドキュメントはクローズドウェブでなければならな」(上記(か))く、「クローズドウェブはすべてのリンクを含まなくてはならな」(上記(か))く、「1セットのファイルシステムの周期的な送信(データカルーセル)」(上記(き))であり、トランスポートストリームにおいては、上記〈5. THE CODING LAYER STRUCTURE〉「C The Transport Layer 」の記載から、「いくつかのエレメンタリストリームはともに多重化され、」(上記(ぬ)) 「多重化中に、各エレメンタリストリームは固定の次元(188バイト)でトランスポートパケットへ細分され、」(上記(に)) 「各エレメンタリストリームはPIDによって識別され」(上記(ぬ))、識別するための「情報はプログラムスペシフィックインフォメーション(PSI)と呼ばれ、プログラムマップテーブル(PMT)と同様にプログラムアソシエーションテーブル(PAT)を含んでい」(上記(ぬ))る。以上より、刊行物1に開示されている「デジタルTVチャンネルの内でマルチメディア情報を放送する、新システムの構造」が開示されており、「デジタルTVチャンネルの内でマルチメディア情報を放送する、新システムの構造」における放送する動作も開示されているから、その動作を方法の発明として認定することができ、その方法(以下「刊行物1発明」という。)は以下のとおりである。「デジタルTVチャンネルの内でマルチメディア情報を放送する、方法であって、そのスキームは、DSM-CC機能に基づき、効率的にマルチメディア情報を伝えることを可能にするプロトコルを使用し、そのような情報には、それがハイパーテキストとして構成されたテキスト、イメージ、音およびアニメーションを含むことができ、WWW環境の中で使用されるHTMLファイルの同じ特性があり、使用されるトランスポート構造はMPEG-2トランスポートストリームであり、プロトタイプソフトウェアは、DSM-CCオペレーションによるファイルシステムをエンコードし、かつMPEG-2の互換性をもつトランスポートストリームにそれを含めるためのものであり、 DSM-CC機能は、ムービー-オン-デマンド、テレショッピング、ニュース-オン-デマンド、遠隔データベースアクセスなどの異なるアプリケーションを実行するために1セットのプロトコルを提供し、 DSM-CCの特別の特徴は、ダウンロード機能であり、完全なダウンロード・オペレーションはイメージデータを転送し、それはモジュールという名の論理上分離されたセクションから構成され、各モジュールは同じサイズのブロックに分割され、ダウンロードパラメータは、接続をセットアップするためにダウンロードサーバによって送信されるDownloadInfoResponseメッセージによって提供され、接続がセットアップされた後、データブロックはDownloadDataBlockメッセージによって伝えられ、 DownloadInfoResponseは、各モジュールと関係するセッションおよび具体的情報に関するある一般的な情報を伝えることにより、ダウンロード・セッションを始め、各モジュールはmoduleIdと呼ばれる識別子に関連させられ、それは1つのダウンロード・セッション内でユニークでなければならなく、さらに、モジュールのサイズとそのバージョン番号は送信されなければならないものであり、ハイパーテキストは、ハイパーリンクによって互いに接続された異なるドキュメントのグループからなり、すべての送信されたドキュメントはクローズドウェブでなければならなく、クローズドウェブはすべてのリンクを含まなくてはならなく、 1セットのファイルシステムの周期的な送信(データカルーセル)であり、トランスポートストリームにおいては、いくつかのエレメンタリストリームはともに多重化され、各エレメンタリストリームはPIDによって識別され、識別するための情報はプログラムスペシフィックインフォメーション(PSI)と呼ばれ、プログラムマップテーブル(PMT)と同様にプログラムアソシエーションテーブル(PAT)を含んでいる方法。」イ補正後発明と刊行物1発明との対比補正後発明と刊行物1発明とを対比する。 (ア)「データ受信装置にモノメディアデータを伝送する伝送方法」刊行物1発明は「デジタルTVチャンネルの内でマルチメディア情報を放送する、方法」であり、「マルチメディア情報」は「メディアデータ」といえ、「放送」は受信装置にデータを伝送するものであるから、「データ受信装置にメディアデータを伝送する伝送方法」といえる。しかしながら、補正後発明においては、「メディアデータ」が「モノメディアデータ」であるのに対し、刊行物1発明においては、「モノメディアデータ」でない点で相違する。 (イ)「ダウンロードのためのGUI情報を含んでいる上記モノメディアデータをDSM-CC方式に基づいてモジュールを生成し」刊行物1発明は、「そのスキームは、DSM-CC機能に基づき、効率的にマルチメディア情報を伝えることを可能にするプロトコルを使用し、」「DSM-CC機能は、ムービー-オン-デマンド、テレショッピング、ニュース-オン-デマンド、遠隔データベースアクセスなどの異なるアプリケーションを実行するために1セットのプロトコルを提供し、 DSM-CCの特別の特徴は、ダウンロード機能であり、完全なダウンロード・オペレーションはイメージデータを転送し、それはモジュールという名の論理上分離されたセクションから構成され」るから、「メディアデータをDSM-CC方式に基づいてモジュールを生成し」ているといえる。しかしながら、補正後発明においては、「メディアデータ」が「ダウンロードのためのGUI情報を含んでいる上記モノメディアデータ」であるのに対し、刊行物1発明においては、「ダウンロードのためのGUI情報を含んでいる上記モノメディアデータ」でない点で相違する。 (ウ)「上記モジュールを固定長を有するブロックに分割し、上記ブロックに分割されたデータから、DDBメッセージを生成し」刊行物1発明は、「各モジュールは同じサイズのブロックに分割され、」「接続がセットアップされた後、データブロックはDownloadDataBlockメッセージによって伝えられ」るから、「上記モジュールを固定長を有するブロックに分割し、上記ブロックに分割されたデータから、DDBメッセージを生成し」ているといえる。 (エ)「上記モジュールを識別するための情報、当該モジュールの大きさ及びモジュールのバージョンを示す情報を含んでいるDIIメッセージを生成し」刊行物1発明においては、「DownloadInfoResponseは、各モジュールと関係するセッションおよび具体的情報に関するある一般的な情報を伝えることにより、ダウンロード・セッションを始め、各モジュールはmoduleIdと呼ばれる識別子に関連させられ、それは1つのダウンロード・セッション内でユニークでなければならなく、さらに、モジュールのサイズとそのバージョン番号は送信されなければならないものであ」るから、「上記モジュールを識別するための情報、当該モジュールの大きさ及びモジュールのバージョンを示す情報を含んでいるメッセージを生成し」ているといえる。そして、そのメッセージは「上記モジュールを識別するための情報、当該モジュールの大きさ及びモジュールのバージョンを示す情報を含んで(いる)」おり、「各モジュールと関係するセッションおよび具体的情報に関するある一般的な情報を伝えることにより、ダウンロード・セッションを始め」るから、ダウンロードを指示する情報(Download Indication Information)といい得、DIIメッセージといい得る。 (オ)「上記DDBメッセージ及びDIIメッセージをトランスポートストリームに変換して、パケット化し」刊行物1発明は、「使用されるトランスポート構造はMPEG-2トランスポートストリームであり、プロトタイプソフトウェアは、DSM-CCオペレーションによるファイルシステムをエンコードし、かつMPEG-2の互換性をもつトランスポートストリームにそれを含めるためのものであり、」上記(ウ)、(エ)のとおり、DDBメッセージ及びDIIメッセージは生成されるから、「上記DDBメッセージ及びDIIメッセージをトランスポートストリームに変換して」といえる。さらに、刊行物1発明の「トランスポートストリーム」は、「いくつかのエレメンタリストリームはともに多重化され、多重化中に、各エレメンタリストリームは固定の次元(188バイト)でトランスポートパケットへ細分され」るから、「パケット化」するものといえる。 (カ)「さらに、少なくともチャンネルリストを含むNITとチャンネルごとの情報であるPMTとを含むパケット化されたPSIとともに多重化し」刊行物1発明の「トランスポートストリーム」は、「トランスポートストリームにおいては、いくつかのエレメンタリストリームはともに多重化され、多重化中に、各エレメンタリストリームは固定の次元(188バイト)でトランスポートパケットへ細分され、各エレメンタリストリームはPIDによって識別され、識別するための情報はプログラムスペシフィックインフォメーション(PSI)と呼ばれ、プログラムマップテーブル(PMT)と同様にプログラムアソシエーションテーブル(PAT)を含んでいる」から、「PMTを含むパケット化されたPSIとともに多重化し」ているといえる。しかしながら、補正後発明においては、「PMT」が「チャンネルごとの情報であるPMT」であり、「PSI」が「チャンネルリストを含むNITと」を含んでいるのに対し、刊行物1発明においては、そうではない点で相違する。 (キ)「周期的且つ繰り返し送出するカルーセル方式を使って伝送する」刊行物1発明は、「1セットのファイルシステムの周期的な送信(データカルーセル)であ」るから、「周期的且つ繰り返し送出するカルーセル方式を使って伝送する」といえる。ウ一致点、相違点そうすると、補正後発明と刊行物1発明の一致点、相違点は次のとおりである。 [一致点] データ受信装置にメディアデータを伝送する伝送方法において、メディアデータをDSM-CC方式に基づいてモジュールを生成し上記モジュールを固定長を有するブロックに分割し、上記ブロックに分割されたデータから、DDBメッセージを生成し、上記モジュールを識別するための情報、当該モジュールの大きさ及びモジュールのバージョンを示す情報を含んでいるDIIメッセージを生成し、上記DDBメッセージ及びDIIメッセージをトランスポートストリームに変換して、パケット化し、さらに、少なくともPMTを含むパケット化されたPSIとともに多重化し、周期的且つ繰り返し送出するカルーセル方式を使って伝送するデータ伝送方法。 [相違点1] 補正後発明においては、「メディアデータ」が「モノメディアデータ」であるのに対し、刊行物1発明においては、「モノメディアデータ」でなく、さらに、補正後発明においては、「メディアデータ」が「ダウンロードのためのGUI情報を含んでいる上記モノメディアデータ」であるのに対し、刊行物1発明においては、「ダウンロードのためのGUI情報を含んでいる上記モノメディアデータ」でない点。 [相違点2] 補正後発明においては、「PMT」が「チャンネルごとの情報であるPMT」であり、「PSI」が「チャンネルリストを含むNITと」を含んでいるのに対し、刊行物1発明は、そうではない点。 (6)相違点の判断等ア相違点の判断 [相違点1] 刊行物1発明は、「デジタルTVチャンネルの内でマルチメディア情報を放送する、方法であって、そのスキームは、DSM-CC機能に基づき、効率的にマルチメディア情報を伝えることを可能にするプロトコルを使用し、そのような情報には、それがハイパーテキストとして構成されたテキスト、イメージ、音およびアニメーションを含むことができ、WWW環境の中で使用されるHTMLファイルの同じ特性があ(り)」るものであり、「DSM-CC機能は、」「遠隔データベースアクセス」の「アプリケーションを実行するために1セットのプロトコルを提供」(上記(く))するものであるから、その提供をマルチメディア情報として、ハイパーテキストとして構成されたテキスト、イメージ、音およびアニメーションを含めて提供するといえる。そして、「遠隔データデースアクセス」の「アプリケーション」は、ユーザが遠隔データベースにアクセスするために、ユーザインターフェースが必要なことは明らかであり、ユーザの操作のし易さから、GUIとすることは当業者が容易になし得ることである。また、遠隔データベースアクセスは、遠隔にあるデータベースからデータを取ってくるものであり、データをダウンロードするものといえる。そうすると、遠隔データベースアクセスをマルチメディア情報で送ることで、刊行物1発明の「マルチメディア情報」を「ダウンロードのためのGUI情報を含んでいるメディアデータ」をすることは、当業者が容易になし得ることである。そして、刊行物1の3.の記載(上記(か))のようにマルチメディア情報であるクローズドウェブは、すべてのリンクを含むのであるから、リンクを全て送っているものであり、その各々のリンクは、マルチメディア情報を構成するものであり、モノメディアといえる。「マルチメディア情報」は、「モノメディア」データから構成されているから、その「モノメディア」データに注目し、「メディアデータ」を「モノメディアデータ」とし、「ダウンロードのためのGUI情報を含んでいるメディアデータ」を「ダウンロードのためのGUI情報を含んでいるモノメディアデータ」とすることは、当業者が容易になし得ることである。 [相違点2] MPEG-2 TSにおいては、NITを含むPSIは周知であり(下記周知技術、特に[2](4)参照)、デジタルTVチャンネルを用いる刊行物1発明において、PSIがチャンネルリストを含むNITとを含むようにすることは、当業者が容易になし得ることである。そして、下記周知技術[4]には「PATおよびPMTにおいてはプログラム番号が、また、NITではサービスIDが、それぞれ視聴者が選局するチャネル番号に該当します。」と記載されており、チャンネルリストを含むNITとを含むようにしたPSIにおいては、PMTは「チャンネルごとの情報である」PMTといえ、デジタルTVチャンネルを用いる刊行物1発明においてNITを用いるとき、PMTを「チャンネルごとの情報である」PMTとすることは容易に想到できる。したがって、刊行物1発明において、「少なくともチャンネルリストを含むNITとチャンネルごとの情報であるPMTとを含むパケット化されたPSIとともに多重化」するようにすることは、当業者が容易になし得ることである。 [周知技術] マルチメディア通信研究会編「ポイント図解式実践MPEG教科書」、株式会社アスキー、1995年11月1日、初版、143頁?149頁。 (なお、以下「○1」等なる表記は、上記刊行物中の記号「○の中に数字を入れた記号」を示す。情報処理システムの能力上、刊行物中の同記号を表すことができないことによる。) 「[2]PSI(Program Specific Information、プログラム仕様情報)とは? 従来のFM(Frequency Modulation)変調によるアナログCS放送においては、視聴者が番組を選択する際の単位であるチャネルと、放送事業者および衛星オペレータが番組を伝送する際の単位であるトランスポンダは同一(すなわち1本のトランスポンダで放送されるチャネル数は1チャネルのみ)であり、受信機において視聴者が選局したチャネルと実際に受信(復調)すべき変調波は一義的に結びついていました。しかし、ディジタル多チャネルCS放送では、すでに説明したとおり時分割多重を行うため、1本のトランスポンダに4?8チャネル程度の番組が多重化されることになり、信号を復調した後、さらに必要なパケットだけを分離することが必要となります。これらの関係をわかりやすく示すため、前出の図8-7に加え、従来のアナログ方式のシステム・モデルを図8-8に示します。図8-8では、チューナーにおける選局だけで受信が可能となるのに対し、図8-7では、受信操作としてチューナーでの選局と、分離部でのパケットの指定の二つの操作が必要となることがわかります。これを従来のアナログ放送と同様なチャネル(番組)選択だけとし、視聴者が受信する際に、トランスポンダ番号などの伝送路側の仕様をまったく意識しないで選局することを可能にするのがPSIです。」(143?144頁) 「[3]PSIのデータ構成 MPEG2システムの中で規定されているPSIは、四つのテーブルとその中で用途別に用いられるさまざまなディスクリプタ(記述子)からなっています。ここでは、各テーブルの役割とともに、受信操作に重要な三つのテーブルのデータ構成について示します。なお、ここで紹介する衛星放送への適用方法はあくまでも一例であり、絶対的なものではありません。 (1)プログラム・アソシエーション・テーブル(PAT) 各プログラム番号(16ビット)ごとに、そのプログラムを構成するパケットの情報を伝送するプログラム・マップ・テーブル(後述)のPID(パケットID;パケット識別子)を示します。 PAT自体のPIDとしては、固定的にPID=“0”が割り当てられています(図8-9)。次に、主な内容について説明しましょう。 ○1 テーブルID MPEGで規定されており、テーブルの種別を示します。PATは“0X00”(16進表記)です。 ○2 トランスポート・ストリームID ストリーム(多重化された符号化データ)を識別します。衛星の場合はトランスポンダに相当します。 ○3 バージョン番号/カレント・ネクスト・インジケータバージョン番号は、テーブルの内容が更新される都度、加算され、カレント・ネクスト・インジケータは新旧バージョンを同時に伝送する際の識別に用いられます。 ○4 プログラム番号個々のチャネルを識別します。 ○5 ネットワークPID プログラム番号が“0X0000”の場合に、ネットワーク・インフォメーション・テーブル(後述)のPIDを示します。 ○6 プログラム・マップPID プログラム・マップ・テーブル(後述)のPIDを示します。 (2)プログラム・マップ・テーブル(PMT) 各プログラム番号ごとに、そのプログラムを構成する映像、音声、付加データなどのストリームが伝送されるパケットのPIDを示します(図8-10)。PMT自体のPIDはPATで指定されます。 PATと重複しない内容について説明します。 ○1 テーブルID MPEGで規定されており、テーブルの種別を示します。PMTは“0X02”です。 ○2 PCRPID 復号する際の基準となるクロック(PCR)が含まれるパケットのPIDを示します。 ○3 ストリーム・タイプ映像、音声、データなど、ストリームで伝送される信号の種類を示します。 (3)コンデイショナル・アクセス・テーブル(CAT) 有料放送において、スクランブルを解くための暗号解読情報を伝送するパケットのPIDを示します。CAT自体のPIDとしては、固定的にPID=“1”が割り当てられています。 (4)ネットワーク・インフォメーション・テーブル(NIT) 伝送路に関する物理的な情報、すなわち、衛星においては衛星の軌道、偏波、トランスポンダごとの周波数などを示します(図8-11)。 NIT自体のPIDはPATで指定されます。すでに説明した三つのテーブルについては、MPEGシステムでデータ構成の詳細が規定されていまずが、NITはその必要性だけが示され、データ構成についてはプライベートとされています。受信動作の実現にはNITが不可欠です。ここでは前節で説明したDVB (Digital Video Broadcasting、ヨーロッパのディジタル放送標準)の規定を引用し、そのデータ構成を示します。また、この中で用いられるディスクリプタについても一部を紹介します。 PAT、PMTと重複しない内容について説明します。 ○1 テーブルID DVBで規定されており、テーブルの種別を示します。NITについては当該ネットワークが“0X40”、他のネットワークが“0X41”です。 ○2 ネットワークID ネットワークを識別します。衛星の場合は個々の衛星に相当します。さらに、PSIの一部として重要な役割を果たす二つのディスクリプタについて、説明しましょう。 ○3 サテライト・デリバリー・システム・デイスクリプタ TS(トランスポート・ストリーム)ディスクリプタ長に従って繰り返されるディスクリプタの1番目として使用し、TS(トランスポート・ストリーム)ID(識別子)と一対になります(図8-12)。次に、衛星/トランスポンダの仕様を示します。 ●ディスクリプタ・タグ DVBで規定されており、ディスクリプタの種別を示します。このディスクリプタでは“0X43”となります。 ●周波数ストリーム(ここではトランスポンダ)ごとの伝送周波数を示します。 ●軌道/西経・東経フラグ/偏波衛星の軌道、偏波を示します。 ●変調/シンボル・レート/内側誤り訂正符号化率伝送方式に関する仕様を示します。 ○4 サービス・リスト・ディスクリプタ TS(トランスポート・ストリーム)ディスクリプタ長に従って繰り返されるディスクリプタの2番目以降として使用し、当該ストリーム(ここではトランスポンダ)に多重されたサービス(チャネル)のIDを示します(図8-13)。すなわち、一つのTS(トランスポート・ストリーム)IDに複数のサービス・リスト・ディスクリプタが付属します ●ディスクリプタ・タグ DVBで規定されており、ディスクリプタの種別を示します。このディスクリプタでは、“0X41”となります。 ●サービスID サービスを識別します。通常、サービスは視聴者が選局するチャネルと一致します。 ●サービス・タイプ映像、音声、データなど、サービスの内容を示します。」(144?148頁) 「」(148頁) 「[4]受信機における選局動作実際のシステムにおける受信動作は、伝送路の形態およびPSIの利用法によってさまざまな方式が考えられます。ここでは衛星放送に限定し、各テーブルを受信機のメモリに保存することなく、必要なたびに受信するものとした場合の受信動作の一例を図8-14に示します。ここでは、PATおよびPMTにおいてはプログラム番号が、また、NITではサービスIDが、それぞれ視聴者が選局するチャネル番号に該当します。さらに、NITがネットワーク全体、すなわちすべてのトランスポンプの情報を含み、同一のテーブルがすべてのトランスポンダで並行に伝送されるのに対し、PATおよびPMTはそれぞれが伝送されるトランスポンダ内の番組の情報だけからなり、各トランスポンダごとに異なった内容となります。」(148?149頁) 「」(149頁) ウ効果等以上のように、相違点1及び相違点2に係る構成はいずれも当業者が容易に想到できたものである。そして、これらの相違点に係る構成を総合しても、補正後発明が奏する効果は、当業者が容易に予測できたものである。したがって、補正後発明は、刊行物1に記載された発明に基づいて当業者が容易に発明することができたものであるから、特許法29条2項の規定により特許出願の際独立して特許を受けることができない。よって、本件補正は、平成18年法律第55号改正附則第3条第1項によりなお従前の例によるとされる同法による改正前の特許法第17条の2第5項において準用する同法第126条第5項の規定に違反している。 3 まとめしたがって、本件補正は、平成18年法律第55号改正附則第3条第1項によりなお従前の例によるとされる同法による改正前の特許法第17条の2第5項において準用する同法第126条第5項の規定に違反するので、同法第159条第1項において読み替えて準用する同法第53条第1項の規定により却下すべきものである。よって、補正却下の決定の結論のとおり決定する。第3 本願発明について 1 本願発明平成23年4月18日付けの手続補正は、上記のとおり却下されたので、本願の請求項1及び請求項2に係る発明は、平成22年2月22日付け手続補正により補正された明細書及び図面の記載からみて、その特許請求の範囲の請求項1及び請求項2に記載した事項により特定されるとおりのものであるところ、請求項1に係る発明(以下「本願発明」という。)は次のとおりである。「データ受信装置にモノメディアデータを伝送する伝送方法において、上記モノメディアデータをDSM-CC方式に基づいてモジュールを生成し、上記モジュールを固定長を有するブロックに分割し、上記ブロックに分割されたデータから、DDBメッセージを生成し、上記モジュールを識別するための情報、当該モジュールの大きさ及びモジュールのバージョンを示す情報を含んでいるDIIメッセージを生成し、上記DDBメッセージ及びDIIメッセージをトランスポートストリームに変換して、パケット化し、さらに、少なくともチャンネルリストを含むNITとチャンネルごとの情報であるPMTとを含むパケット化されたPSIとともに多重化し、周期的且つ繰り返し送出するカルーセル方式を使って伝送するデータ伝送方法。」 2 引用文献原査定の拒絶の理由に引用された引用文献1の記載事項は、上記第2の2(4)に記載したとおりである。 3 対比・判断 (1)対比本願発明は、補正後発明における「ダウンロードのためのGUI情報を含んでいる上記モノメディアデータ」の「ダウンロードのためのGUI情報を含んでいる」の限定をなくしたものであり、その他は補正後発明と同じである。引用文献1に記載された発明は、上記第2の2(5)アに記載した刊行物1発明と同じである。そうすると、一致点、相違点は以下のとおりである。 [一致点] データ受信装置にメディアデータを伝送する伝送方法において、メディアデータをDSM-CC方式に基づいてモジュールを生成し上記モジュールを固定長を有するブロックに分割し、上記ブロックに分割されたデータから、DDBメッセージを生成し、上記モジュールを識別するための情報、当該モジュールの大きさ及びモジュールのバージョンを示す情報を含んでいるDIIメッセージを生成し、上記DDBメッセージ及びDIIメッセージをトランスポートストリームに変換して、パケット化し、さらに、少なくともPMTを含むパケット化されたPSIとともに多重化し、周期的且つ繰り返し送出するカルーセル方式を使って伝送するデータ伝送方法。 [相違点1] 補正後発明においては、「メディアデータ」が「モノメディアデータ」であるのに対し、刊行物1発明においては、「モノメディアデータ」でない点。 [相違点2] 補正後発明においては、「PMT」が「チャンネルごとの情報であるPMT」であり、「PSI」が「チャンネルリストを含むNITと」を含んでいるのに対し、刊行物1発明は、そうではない点。 (2)判断 [相違点1]の判断は、上記第2の2(6)ア[相違点1]における「モノメディア」についての判断を援用する。 [相違点2]の判断は、上記第2の2(5)ウ[相違点2]と同じであるから、上記第2の2(6)ア[相違点2]の判断を援用する。したがって、本願発明は、引用文献1に記載された発明により当業者が容易に発明できたものである。 5 むすび以上のとおり、本願の請求項1に係る発明は、引用文献1に記載された発明に基づいて、当業者が容易に発明することができたものであるから、特許法第29条第2項の規定により特許を受けることができない。したがって、残る請求項2に係る発明について検討するまでもなく、本願は拒絶されるべきものである。よって、結論のとおり審決する。
審理終結日	2012-05-31
結審通知日	2012-06-05
審決日	2012-06-19
出願番号	特願2006-333699(P2006-333699)
審決分類	P 1 8・ 121- Z (H04N) P 1 8・ 121- Z (H04N) P 1 8・ 575- Z (H04N)
最終処分	不成立
前審関与審査官	田中啓介
特許庁審判長	奥村元宏
特許庁審判官	松尾淳一小池正彦
発明の名称	データ伝送方法及びデータ伝送装置
代理人	脇篤夫
代理人	中川裕人
代理人	鈴木伸夫

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