• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 特36条4項詳細な説明の記載不備 特許、登録しない(前置又は当審拒絶理由) H04N
管理番号 1284782
審判番号 不服2011-25583  
総通号数 172 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2014-04-25 
種別 拒絶査定不服の審決 
審判請求日 2011-11-28 
確定日 2014-02-12 
事件の表示 特願2007-532477「デジタルコンテンツへの認可されたアクセスを提供するためのシステム及び方法」拒絶査定不服審判事件〔平成18年 3月30日国際公開,WO2006/033997,平成20年 5月 1日国内公表,特表2008-514123〕について,次のとおり審決する。 
結論 本件審判の請求は,成り立たない。 
理由 第1.手続の経緯
本願は,2005年9月16日(パリ条約による優先権主張外国庁受理2004年9月16日 アメリカ合衆国)を国際出願日とする出願であって,
平成19年3月27日付けで特許法第184条の4第1項の規定による明細書,請求の範囲,及び,図面(図面の中の説明に限る)の日本語による翻訳文が提出されると共に審査請求がなされ,平成22年2月16日付けで審査官により拒絶理由が通知され,これに対して平成22年8月23日付けで意見書が提出されると共に手続補正がなされ,平成22年12月16日付けで審査官により拒絶理由が通知され,これに対して平成23年6月21日付けで意見書が提出されると共に手続補正がなされたが,平成23年7月20日付けで審査官により拒絶査定がなされ(謄本送達 平成23年7月26日),これに対して平成23年11月28日付けで審判請求がなされると共に手続補正がなされたので,特許法第162条の規定により前置審査に付され,平成24年3月9日付けで審査官により最後の拒絶理由が通知され,これに対して平成24年9月13日付けで意見書が提出され,平成24年11月26日付けで審査官により特許法第164条第3項の規定に基づく報告がなされ,平成25年1月24日付けで当審により特許法第134条第4項の規定に基づく審尋がなされ,平成25年7月29日付けで回答書の提出があったものである。

第2.本願発明について
本願に係る発明は,平成23年11月28日付けの手続補正により補正された特許請求の範囲の請求項1?請求項14に記載された次の事項により特定されるものである。

「 【請求項1】
サーバおよび該サーバと通信を行うデバイスを含むシステムにおいて,デバイスの受信するコンテンツへのアクセスを認可するように該システムを動作させるための方法において,
サーバがデバイスに公開鍵,秘密鍵及び関連するデジタル証明書を提供する工程と,
サーバが対称鍵アルゴリズムを用いてデバイスに該デバイスに対しユニークであるデバイスユニット鍵を提供する工程であって,デバイスユニット鍵は公開鍵によって暗号化され,秘密鍵によって解読される,前記工程と,
サーバが対称鍵アルゴリズムを用いてデバイスに1つ以上のサービス鍵を提供する工程であって,該1つ以上のサービス鍵はデバイスユニット鍵によって暗号化および認証される,前記工程と,
サーバが対称鍵アルゴリズムを用いてデバイスに1つ以上の番組鍵を提供する工程であって,該1つ以上の番組鍵は第1のタイプのコンテンツアクセス及び別の第2のタイプのコンテンツアクセスを解読するために用いられる,前記工程と,を備え,
第1のタイプのコンテンツアクセスはコンテンツペイパービューイベント用であり,第2のタイプのコンテンツアクセスはコンテンツ加入サービス用であり,
デバイスユニット鍵によって,第1のタイプのコンテンツアクセスを解読するために用いる前記1つ以上の番組鍵の暗号化及び認証が行われ,前記1つ以上のサービス鍵によって,第2のタイプのコンテンツアクセスを解読するために用いる前記1つ以上の番組鍵の暗号化及び認証が行われる,方法。
【請求項2】
デバイスユニット鍵は,
サーバが前記1つ以上のサービス鍵若しくは前記1つ以上の番組鍵の暗号化を行うために用いる第1の対称鍵,又は,
サーバが前記1つ以上のサービス鍵若しくは前記1つ以上の番組鍵の認証を行うために用いる第2の対称鍵,を含む請求項1に記載の方法。
【請求項3】
デバイスユニット鍵は所定の周期で更新される請求項1に記載の方法。
【請求項4】
前記1つ以上のサービス鍵は複数のサービス鍵を含むことと,前記1つ以上の番組鍵は複数の番組鍵を含むことと,前記複数のサービス鍵の各々は前記複数の番組鍵の各々に対しユニークであり,サーバが前記複数の番組鍵の各々の解読を行うために用いられることと,を含む請求項1に記載の方法。
【請求項5】
前記1つ以上のサービス鍵は,
サーバが前記1つ以上の番組鍵の暗号化を行うために用いる第1の対称鍵と,
サーバが前記1つ以上の番組鍵の認証を行うために用いる第2の対称鍵と,を含む請求項1に記載の方法。
【請求項6】
前記1つ以上のサービス鍵は所定の周期で更新される請求項5に記載の方法。
【請求項7】
サーバがデバイスに,前記1つ以上の番組鍵と第2のタイプのコンテンツアクセスによる情報との組合せから導出され,デバイスがコンテンツを解読するために用いられるコンテンツ解読鍵を提供する工程,を含む請求項1に記載の方法。
【請求項8】
公開鍵,秘密鍵及び関連するデジタル証明書,デバイスユニット鍵,サービス鍵,番組鍵,並びにコンテンツ解読鍵は,コンテンツを受信するためにデバイスによってアクセス可能なスマートカード及びコンピュータ可読媒体のうちの一方において符号化されている請求項1に記載の方法。
【請求項9】
サーバおよび該サーバと通信を行うデバイスを含むシステムにおいて,デバイスの受信するコンテンツへの認可されたアクセスを提供するように該システムを動作させるための方法において,
サーバがデバイスからコンテンツアクセスの要求を受信する要求受信工程と,
要求に応答して,サーバがデバイスに公開暗号鍵及び秘密暗号鍵を有する非対称鍵ペアを提供する非対称鍵ペア提供工程と,
サーバがデバイスに資格管理メッセージ(EMM)を提供する管理メッセージ提供工程であって,
a)サーバがデバイスに対しユニークであるデバイスユニット鍵を公開暗号鍵によって暗号化するデバイスユニット鍵暗号化工程と,
b)サーバが,デバイスが番組鍵の解読を行うために用いられるサービス鍵を少なくともデバイスユニット鍵によって暗号化するサービス鍵暗号化工程と,を含む,前記工程と,
サーバがデバイスに第1のタイプのコンテンツアクセス又は別の第2のタイプのコンテンツアクセスの資格制御メッセージ(ECM)を提供する制御メッセージ提供工程であって,
a)サーバが,デバイスによる第1のタイプのコンテンツアクセス又は第2のタイプのコンテンツアクセスの解読のためにECMに番組鍵を提供する番組鍵提供工程と,
b)サーバが第1のタイプのコンテンツアクセス用のサービス鍵によってECMを暗号化する第1ECM暗号化工程と,
c)サーバが第2のタイプのコンテンツアクセス用のデバイスユニット鍵によってECMを暗号化する第2ECM暗号化工程と,を含む,前記工程と,からなり,
第1のタイプのコンテンツアクセスはコンテンツ加入サービスタイプであり,第2のタイプのコンテンツアクセスはコンテンツペイパービューイベントタイプである,方法。
【請求項10】
第1ECM暗号化工程はサーバがサービス鍵によって番組鍵を暗号化する工程を含み,
第2ECM暗号化工程はサーバがデバイスユニット鍵によって番組鍵を暗号化する工程を含む,請求項9に記載の方法。
【請求項11】
管理メッセージ提供工程は,サーバが,デバイスがサービス鍵の失効時に第1のタイプのコンテンツアクセスの解読を行うために用いる別のサービス鍵を少なくともデバイスユニット鍵によって暗号化する工程を含み,EMMはサービス鍵及び別のサービス鍵を含む,請求項9に記載の方法。
【請求項12】
サーバが定期的に管理メッセージ提供工程を反復し,さらなるEMMを生成する工程を含み,各EMMは各EMMの生成の順序に基づき最初から最後へ順次値の増大する鍵識別子を含む,請求項9に記載の方法。
【請求項13】
制御メッセージ提供工程は,
デバイスが番組鍵を用いて第2のタイプのコンテンツアクセスのコンテンツを解読したとき,サーバがデバイスに,同コンテンツがデバイスに記憶される期間の長さを指定する第1のアクセス規則を提供する工程を含む請求項9に記載の方法。
【請求項14】
デバイスは,非対称鍵ペアへのアクセスを有し,かつ,コンテンツへのアクセスを提供する受信機を含む請求項9に記載の方法。」

第3.原審の拒絶理由
平成24年3月9日付けの拒絶理由(以下,これを「前置拒絶理由」という)は,概略,次のとおりである。

「 理 由

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



平成23年11月28日付手続補正により補正された請求項記載の発明について,以下の点で当業者が実施可能に発明を開示していない,ないしは技術的意義が把握できない。

(1)「デバイス秘密鍵をサーバから提供する」ことについて:
本願明細書段落0009-0011の記載ぶりでは,「デバイス秘密鍵」をどのようにしてサーバから端末に安全に届けるのか不明である。
仮に,サーバから送られるデバイス秘密鍵を安全に取得するために,端末に固定的な鍵を用いる,このような固定的な鍵は受信機にユニークなデバイスユニット鍵と同じように用いてよいため,本願のようにわざわざデバイスユニット鍵をサーバから送るようにした(可変な鍵にした)ことの技術的意義も,本願のようなデバイス秘密鍵→デバイスユニット鍵→サービス鍵→番組鍵→コンテンツ鍵のような鍵階層(左から右に行くに従い,上位階層の鍵となる)を用いることの技術的意義も不明である。
この点について,平成24年1月11日付け面接を踏まえた出願人からの平成24年2月16日付け回答FAXの不明点1に対する回答では,実質的に回答がなされていない。
当該事項は,本願発明と,本願出願人によって出願され本願優先権主張日前に公開された引用例1記載の発明との差別化を図る事項であるものと思慮され,上記事項を削除してしまったのでは引用例1記載のものとの差異がないとの心証がある。

(2)「デバイス秘密鍵を送るための対称鍵,非対称鍵」について:
(1)とも関連するが,デバイス秘密鍵を送るための構成が不明であり,当業者が実施可能な程度に発明を開示していないといえる。また,「対称鍵」「非対称鍵」いずれも公開鍵暗号系を用いているものと思われるが,「対称鍵」「非対称鍵」の技術的定義が不明であることとも関連し,デバイス秘密鍵を送るための構成について技術的意義が理解しがたい。
(平成24年1月11日付け面接を踏まえた出願人からの平成24年2月16日付け回答FAXの不明点3に対する回答を踏まえ,請求項記載のものに対し適切な定義を与え,明細書中の記載についても技術的に一貫する釈明をされたい。)

(3)「デバイスユニット鍵をサーバから提供する」ことについて:
これも(1)とも関連するが,本来「デバイス固有の鍵」であり固定的であった「デバイスユニット鍵」を(書き換え可能とするために)サーバから送信するための構成について,「サーバからデバイスに秘密鍵を提供し」,「この秘密鍵を用いてサーバから送られるデバイスユニット鍵を復号する」ものと思われるが,この説明が技術的に正しくなされていない。
(平成24年1月11日付け面接を踏まえた出願人からの平成24年2月16日付け回答FAXの不明点1及び平成24年3月1日付け回答においては,実質的に何の回答もして
いない。さらに,平成24年3月1日付け回答はデバイスユニット鍵に関して,請求項と関係ない回答をしているため,当該回答の意図すらも不明である。)
また,「対称鍵アルゴリズム」というのは,公開鍵暗号系のことを定義したいのか,共有鍵暗号系のことを定義したいのか,技術的に意味不明である。

(4)省略」

第4.当審の判断
1.(1)について
上記「第2.本願発明について」において引用した,平成23年11月28日付けの手続補正により補正された請求項(以下,「本願の請求項」という)1に記載された,
「サーバがデバイスに公開鍵,秘密鍵及び関連するデジタル証明書を提供する工程」,
及び,本願の請求項9に記載された,
「要求に応答して,サーバがデバイスに公開暗号鍵及び秘密暗号鍵を有する非対称鍵ペアを提供する非対称鍵ペア提供工程」,
に関して,本願明細書の発明の詳細な説明には,その段落【0009】に,

「図2を参照すると,各受信機はユニークな公開鍵/秘密鍵ペアを所有し,その鍵ペアのデバイス秘密鍵210が示され,証明機関(CA)によって発行されているX.509など対応するデジタル証明書115によって,公開鍵/秘密鍵ペアによる公開鍵がその特定の受信機に属することが確認される。双方向IPマルチキャスト環境では,受信機は,サービスプロバイダへのユーザの登録中に,その受信機のデジタル証明書115をサービスプロバイダへ送信する。単方向IPマルチキャスト環境では,登録中に受信機に受信機のデジタル証明書を送信させるのではなく,各CAが,オンラインディレクトリ又はサービスプロバイダがアクセス可能な任意のロケーションにおいて,受信機に関するX.509証明書を発行する。それらのデジタル証明書は公開情報しか含まないため,このディレクトリにアクセスするのに特別なセキュリティは要求されない。」(下線は,当審にて,説明の都合上,附加したものである。以下,同じ。)

と記載されて,同じく,本願明細書の段落【0025】に,

「420にて,一実施形態では,登録の一環として,ユーザはサービスプロバイダから受信機を獲得する。この受信機は,ユーザとサービスプロバイダとの間で登録が行われる前に,例えば,製造設備において予めインストールされたユニークな公開鍵/秘密鍵ペア,及びデジタル証明書を備える。この実施形態では,公開鍵/秘密鍵ペア,及び対応するデジタル証明書115は,受信機内に実装され,上述のように,受信機による読み取りのためにアクセス可能なスマートカード(スマートカードモジュール330への挿入用)又はCRM(メモリ360など)の中でセキュリティで保護される。別の実施形態では,サービスプロバイダは,記憶されている情報へのアクセスがユーザの受信機に与えられるように,公開鍵/秘密鍵ペア,及びデジタル証明書が記憶されているスマートカード又はCRMのユーザへ,物理的な配布を行う。さらに別の実施形態では,サービスプロバイダは,陸線データネットワーク(インターネットなど),無線データネットワーク(セルラーネットワークなど),又は陸線データネットワークと無線データネットワークとの組合せを介して,ユーザの受信機の中に(例えば,メモリ360の中に)遠隔的にインストールすることによって,公開鍵/秘密鍵ペア及びデジタル証明書を提供する。」

と記載されていて,上記引用の段落【0009】に記載された,特に下線を附した部分の内容に従えば,本願明細書の発明の詳細な説明においては,「各受信機」,即ち,本願の請求項1,及び,請求項9における「デバイス」は,予め,「ユニークな公開鍵/秘密鍵ペア」を有していることになり,また,上記引用の段落【0025】には,「ユーザの受信機」に「公開鍵/秘密鍵ペア」を配布する態様として,
1.サービスプロバイダによって,製造装置において予め受信機にインストールする。
2.サービスプロバイダが,ユーザに対して,公開鍵/秘密鍵ペアが記憶されているCRMのユーザに,物理的な配布を行う。
3.サービスプロバイダが,陸線データネットワーク(インターネットなど),無線データネットワーク(セルラーネットワークなど),又は陸線データネットワークとの組合せを介して,ユーザの受信機の中に(例えばメモリ360の中に)遠隔的にインストールする。
点が挙げられている。しかしながら,段落【0009】に記載の内容は,本願の請求項1に係る発明における,
「サーバがデバイスに公開鍵,秘密鍵及び関連するデジタル証明書を提供する工程」,
及び,請求項9に係る発明における,
「要求に応答して,サーバがデバイスに公開暗号鍵及び秘密暗号鍵を有する非対称鍵ペアを提供する非対称鍵ペア提供工程」,
ではないことは,明らかであり,段落【0025】に記載された,各態様も,「サービスプロバイダ」によって行われるものであって,特に,段落【0025】に記載の,態様の1と,態様の2は,
“サービスプロバイダを運営する人による,作業工程,或いは,サービス提供のための手順”
であって,“人の作業工程”とも解せるものであるから,サーバによって行われるものでないことは,明らかである。
ここで,段落【0025】に記載された,態様の3は,概略,
“サービスプロバイダが,「公開鍵/秘密鍵ペア」を,通信路を介して受信機に送信する”
というものであるから,これを,
“サービスプロバイダが,サーバを用いて,「公開鍵/秘密鍵ペア」を,通信路を介して受信機に送信する”
と解した場合は,一応,装置による作業工程と解せるものであるが,前置拒絶理由で指摘したように,態様の3において,どのようにして,安全に,「サービスプロバイダ」が,「受信機」に対して,“通信路”を介した「公開鍵/秘密鍵ペア」の「遠隔的にインストールする」ことを実現しているか,段落【0025】,及び,本願明細書,及び,図面の他の記載を全て参酌しても不明である。
以上のとおりであるから,本願明細書の発明の詳細な説明に記載された内容からは,
“「デバイス秘密鍵」をどのようにしてサーバから端末に安全に届けるのか”
は不明である。

この点について,審判請求人は,平成24年9月13日付けの意見書(以下,これを「意見書」という)において,
「「デバイス秘密鍵」がどのようにして各デバイスにインストールされるかについては,本発明の範囲ではありません。「サーバ」が各デバイスに送るのは他の種類の鍵であり,「デバイス秘密鍵」ではありません。
・・・・(中略)・・・・
本願発明は,“「デバイス秘密鍵」をどのようにしてサーバから端末に安全に届けるのか”について何ら定義を行うものではないので,その態様を明らかにすることはできません。」
と述べるに止まるが,
本願の請求項1,及び,請求項9に係る発明においては,上記でも引用したとおり,
「サーバがデバイスに公開鍵,秘密鍵及び関連するデジタル証明書を提供する」,
及び,
「サーバがデバイスに公開暗号鍵及び秘密暗号鍵を有する非対称鍵ペアを提供する」,
と明記されているので,審判請求人の,前記引用の意見書における主張は採用できない。
また,当審の平成25年1月24日付けの審尋に対する,平成25年7月29日付けの回答書(以下,これを「回答書」という)においては,上記の不明点に対して,何らの説明もしていないので,審判請求人による意見書,及び,回答書の内容を加味しても,上記指摘の不明点は解消しない。

さらに,上記引用の意見書の主張について,
本願発明の目的は,本願明細書の段落【0005】に記載されているように,
「デジタル権利管理(DRM)アーキテクチャ用のセキュリティを最大化しながら,帯域幅使用を最小限に抑えるための複数のレベルの鍵管理を含む,DRMアーキテクチャ用の暗号鍵管理のアプローチを提供する」,
ということである。そして,「公開鍵/秘密鍵ペア」の「秘密鍵」は,本願の請求項1,及び,請求項9に係る発明における「デバイスユニット鍵」を暗号化して,「デバイス」に提供するために用いられるものであるから,該「秘密鍵」が安全に「デバイス」に提供できないのであれば,第3者によって,該「秘密鍵」が取得され,該「秘密鍵」によって,暗号化された「デバイスユニット鍵」を,第3者が取得することが可能となるので,「サービス鍵」,「番組鍵」も同様に,第3者が取得可能となり,結果,本願における目的は,全く達成されないことになる。
即ち,本願の“鍵配信のプロトコル”は,最初の,「サーバ」が,「公開鍵/秘密鍵ペア」を,安全に提供する点から始まるものである。
その点が,発明の詳細な説明に明確に記載されていない以上,本願明細書の発明の発明の詳細な説明は,本願の目的を実現するための構成が開示されているとは認められず,
結果として,経済産業省令で定めるところにより,その発明の属する技術分野における通常の知識を有する者がその実施をすることができる程度に明確かつ十分に記述したものとは言えない。

2.(2),及び,(3)について
本願の請求項1に記載された,
「サーバが対称鍵アルゴリズムを用いてデバイスに該デバイスに対するユニークであるデバイスユニット鍵を提供する工程であって,デバイスユニット鍵は公開鍵によって暗号化され,秘密鍵によって解読される,前記工程と」,
に関して,上記引用の本願の請求項1の記載から,本願の請求項1に係る発明においては,「サーバ」から,「デバイス」に,「デバイスユニット鍵」を提供する工程には,「対称鍵アルゴリズム」が用いられていることになる。
ここで,「対称鍵アルゴリズム」とは,
“送信側と,受信側が,同一の鍵を,暗号鍵,復号鍵として用い,送信側が,該暗号鍵で,情報を暗号化して,受信側に送り,受信側は,該復号鍵を用いて,暗号化された情報を復号する”
というアルゴリズムを意味することは,当業者にとって周知の技術事項である。
この点に関して,本願明細書の発明の詳細な説明には,その段落【0012】に,

「このサービスプロバイダは,デバイスユニット鍵220や,デバイス資格及び他の構成データを,ユーザの受信機へ配信する。デバイスユニット鍵220は,配信に先立って,公開鍵/秘密鍵ペアからの公開鍵で暗号化されており,受信機によって受信されると,公開鍵/秘密鍵ペアからのデバイス秘密鍵210によって解読される。」

と記載され,更に,段落【0026】に,

「430にて,やはり登録の一環として,サービスプロバイダはユーザの受信機に関するユニークなデバイスユニット鍵220(図2),また随意では,デバイス構成データや,特定のコンテンツアクセスサービスを指定しない一般的な資格をユーザに提供する(例えば,メモリ320又はメモリ360に記憶)。上述のように,デバイスユニット鍵220は公開鍵で暗号化されて配信され,受信機のユニークな公開鍵/秘密鍵ペアの対応する秘密鍵によって受信機内部で解読される(メモリ360に記憶)。」

と記載されていて,上記引用の段落【0012】,及び,段落【0026】に記載された内容から,「デバイスユニット鍵」は,「ユーザ」に提供される際,「受信機のユニークな公開鍵」で暗号化され,「受信機」において,「受信機のユニークな秘密鍵」で復号される点は記載されているが,これは,“公開鍵暗号系”の処理であるから,この処理が,「対称鍵アルゴリズム」,或いは,「対称鍵アルゴリズム」の一部であるとは言えないことは,明らかである。
そして,本願明細書中には,上記引用の記載内容の他,「受信機」に,「デバイスユニット鍵」を,「対称鍵アルゴリズム」を用いて,提供する構成については,特に,言及されていないので,本願明細書の発明の詳細な説明,及び,図面の記載内容からでは,
“サーバが,対称鍵アルゴリズムを用いて,どのようにして,デバイスに,デバイスユニット鍵を提供しているか”
不明である。

審判請求人は,前置拒絶理由における上記不明点(2),及び,(3)について,意見書,および,回答書において,「対称鍵アルゴリズム」については,何らの主張もなされていない。
よって,意見書,回答書の内容を踏まえても,前置拒絶理由の(2),及び,(3)で指摘した不明点は,依然として解消していない。

なお,「対称鍵アルゴリズム」に関して,平成24年2月16日付けで,審判請求人代理人より提示された書面には,その1頁下から2行?2頁3行に,
「請求項1の「サーバが対称鍵アルゴリズムを用いてデバイスに該デバイスに対しユニークであるデバイスユニット鍵を提供する工程であって,デバイスユニット鍵は公開鍵によって暗号化され,秘密鍵によって解読される,前記工程」における対称鍵アルゴリズムは,公開鍵アルゴリズムの誤りでしたので訂正させて頂きたく存じます」
と記載されているが,上記書面を受けて審査官により通知された,前置拒絶理由に応答して,手続補正はなされておらず,また,該前置拒絶理由に対する意見書についても,上記で引用した程度の主張がなされるに止まり,該前置拒絶理由の(2),(3)において指摘した不明点は,上述のとおり,依然として,解消していない。

以上1.及び,2.において検討したとおりであるから,前置拒絶理由の(1)?(3)において指摘した不明点は,依然として解消していない。
よって,本願明細書の発明の詳細な説明は,経済産業省令で定めるところにより,その発明の属する技術分野における通常の知識を有する者がその実施をすることができる程度に明確かつ十分に記述したものでない。

第5.むすび
したがって,本願は,特許法第36条第4項第1号に規定する要件を満たしていない。

よって,結論のとおり審決する。
 
審理終結日 2013-09-13 
結審通知日 2013-09-17 
審決日 2013-09-30 
出願番号 特願2007-532477(P2007-532477)
審決分類 P 1 8・ 536- WZ (H04N)
最終処分 不成立  
前審関与審査官 川崎 優  
特許庁審判長 仲間 晃
特許庁審判官 原 秀人
石井 茂和
発明の名称 デジタルコンテンツへの認可されたアクセスを提供するためのシステム及び方法  
代理人 恩田 誠  
代理人 恩田 博宣  

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