JP2011512739A - コンテンツをストリーミングするシステム及び方法 - Google Patents

Abstract

本発明は、コンテンツをストリーミングするシステム及び方法に関する。本発明は、ローカルネットワークに位置するアプリケーションサーバでの方法に関し、アプリケーションサーバは、第１のネットワークに接続される。この方法は、第１のネットワークに位置する第１の装置から、ローカルネットワークに位置するローカル装置からコンテンツをストリーミングする要求を有するSIP型メッセージを受信するステップと、ローカルネットワークで利用可能なコンテンツのリストを有するSIP型メッセージを第１の装置に送信するステップと、コンテンツのリストから少なくとも１つのコンテンツのストリーミングを第３のネットワークに位置する少なくとも１つの受信機に対して開始するSIP型メッセージを第１の装置から受信するステップと、第３のネットワークに位置するアプリケーション受信モジュールにSIP型メッセージを送信し、少なくとも１つのコンテンツを受信するように少なくとも１つの受信機を招待するステップとを有する。

Description

本発明は、概してコンテンツ配信に関し、特にコンテンツをストリーミングする方法に関する。

この部分は、読者に当該技術の様々な側面を紹介することを目的としており、これらの様々な側面は、以下に記載する本発明の様々な態様に関係し得る。この説明は、本発明の様々な態様をより良く理解することを促進するために読者に背景情報を提供するのに有用であると考えられる。従って、この記載はこの観点から読まれるべきであり、従来技術の認定として読まれるべきでないことがわかる。

ビデオサービスは、様々な配信モデルでインターネット上に展開されている。第１のモデルは、IPTV及びVODサービスを使用する。サービスプロバイダは、ストリーミングプロトコル（典型的にはRTP）に基づいてテレビ及びVODサービスの提供を顧客に対して行い、チャネル選択のためのIGMPと制御コマンドを再生するためのRTSPとを用いてサービスでの制御を提供する。

コンテンツは、オペレータのネットワークに位置するサーバに格納される。VODの場合、サービスセッションは、エンドユーザの要求で開始される。エンドユーザは、（場合によってはセキュリティの理由でプロキシを介して）コンテンツの配信を制御するコマンドをサーバに送信する。潜在的に、このようなサービスは、オペレータのネットワークに位置する記憶リソースでの記録機能を含む。識別、認証及び許可手順は、サービスオペレータにより処理される。サービスにアクセスする権利は、ユーザがそのアクセスを要求している時点で検査される。識別、認証及び許可は、ユーザの識別情報と安全な交換プロトコルとオペレータ完全な制御下にあるデータベースとに基づく。このようにして、オペレータは、今日のIPTVサービスを配信する。

第２のモデルは、HTTPプロトコルに基づくコンテンツのダウンロードである。エンドユーザは、HTTPプロトコルのためインターネットブラウザで取得できる特定のコンテンツを要求する。コンテンツはストリーミングされないが、プルモードで（ユーザが要求してパケットを取得する）サーバ側から顧客側に転送される。通常では、送信ビットレートは、コンテンツが円滑な処理のために実際に必要とするものより高いため、パケットはエンドユーザ側に一時的に格納される。送信ビットレートが最小の要件より一時的に低い場合、処理はフリーズし、エンドユーザにとって再生がつまずくように見える。アクセスが識別及び許可を必要とする場合、しばしばログイン／パスワード手順に基づく。

現在、ブロードバンドアクセスネットワークは、これらのサービス提供をサポートするように形成されている。ブロードバンドアクセスネットワークは、ダウンストリームで高いビットレート（理論的にはADSL2+で25Mbps）を提供し、アップストリームでかなり低いビットレート（理論的には3Mbpsまで）を提供する。VDSL2+は、100Mbpsの対称的なビットレートを提供するように計画されている。

これは、特に顧客の環境にサービスプロバイダのような機能を与えることにより、サービスが消費される方法に新しい機会を開く。エンドユーザにより永続的に所有されているコンテンツ又はエンドユーザの環境で一時的に利用可能なコンテンツは、異なる消費方法（外部位置からの遠隔アクセス、複数の遠隔位置の間での共有）で遠隔アクセスのために提供され得る。

本発明は、複数の遠隔位置の間でコンテンツをストリーミングする方法を提供することにより、従来技術に関する問題の少なくともいくつかに対処することを目的とする。

本発明は、ローカルネットワークに位置するアプリケーションサーバでの方法に関し、アプリケーションサーバは、第１のネットワークに接続される。この方法は、第１のネットワークに位置する第１の装置から、ローカルネットワークに位置するローカル装置からコンテンツをストリーミングする要求を有するSIP型メッセージ（SIPに基づくメッセージ）を受信するステップと、ローカルネットワークで利用可能なコンテンツのリストを有するSIP型メッセージを第１の装置に送信するステップと、コンテンツのリストから少なくとも１つのコンテンツのストリーミングを第３のネットワークに位置する少なくとも１つの受信機に対して開始するSIP型メッセージを第１の装置から受信するステップと、第３のネットワークに位置するアプリケーション受信モジュールにSIP型メッセージを送信し、少なくとも１つのコンテンツを受信するように少なくとも１つの受信機を招待（invite）するステップとを有する。

本発明によれば、アプリケーションサーバは、他のネットワーク（第３のネットワーク）に位置する装置に対して、ローカルネットワークに格納されたコンテンツのコンテンツストリーミング予約を実行する。予約を設定する制御メッセージは、SIP型メッセージである。アプリケーションサーバは、複数の機能（他のネットワークに位置する受信機にストリーミングされるローカルネットワークで利用可能なコンテンツを検査する機能、ストリーミングセッションを設定する要求を受信する機能、コンテンツを受信するために受信機を招待する機能）を集中管理する。この方法は、第１の装置の制御下で、ストリーミングセッションの設定を簡略化する。

実施例によれば、コンテンツのリストは、コンテンツのストリーミングパラメータを有する。

実施例によれば、この方法は、アプリケーション受信モジュールから応答を受信するステップと、ストリーミングが開始可能であることを装置に通知するSIP型メッセージを第１の装置に送信するステップと、ストリーミングを開始するSIP型メッセージを第１の装置から受信するステップとを有する。

本発明の他の目的は、エンドユーザアプリケーションモジュールでの方法であり、ローカルネットワークに位置するローカル装置からコンテンツをストリーミングする要求を有するSIP型メッセージを、ローカルネットワークに接続されたアプリケーションサーバに送信するステップと、ローカルネットワークで利用可能なコンテンツのリストを有するSIP型メッセージをアプリケーションサーバから受信するステップと、コンテンツのリストから少なくとも１つのコンテンツのストリーミングを第３のネットワークに位置する少なくとも１つの受信機に対して開始するSIP型メッセージをアプリケーションサーバに送信するステップとを有する。

実施例によれば、この方法は、ストリーミングが開始可能であることを通知するSIP型メッセージをアプリケーションサーバから受信するステップと、ストリーミングを開始するSIP型メッセージを送信するステップとを有する。

実施例によれば、この方法は、ストリーミングコンテンツを受信するステップを有する。

本発明の他の目的は、ローカルネットワークに接続されたアプリケーション受信モジュールでの方法であり、ストリーミングコンテンツを受信するためにローカルネットワークに位置する少なくとも１つの受信機を招待するSIP型メッセージをアプリケーションサーバから受信するステップと、ローカルネットワークの少なくとも１つの装置が招待メッセージを処理するように識別された場合、コンテンツを受信するための応答をアプリケーションサーバに送信するステップとを有する。

本発明の他の目的は、プログラムがコンピュータ上で実行されたときに、本発明による処理のステップを実行するプログラムコード命令を有するコンピュータプログラムプロダクトである。“コンピュータプログラムプロダクト”とは、コンピュータプログラムサポートを意味し、これは、ディスク又はカセットのようなプログラムを含む記憶空間だけでなく、電気信号又は光信号のような信号も含む。

実施例に従ったシステムのブロック図 実施例に従ったホーム招待側ネットワーク 実施例に従ったホーム被招待側ネットワーク 実施例に従ったアプリケーションサーバ 実施例に従った方法のフローチャート

記載の実施例に相当する特定の態様が以下に示されている。これらの態様は、単に本発明が取り得る特定の形式の簡単な要約を読者に提供するために提示されており、本発明の範囲を限定することを意図しないことがわかる。実際に、本発明は、以下に記載されないことがある様々な態様を含んでもよい。

本発明は、添付図面を参照して、限定的ではない以下の実施例を用いてより良く理解でき、以下の実施例を用いて示される。

図１、２及び３において、示されているブロックは単に機能的要素であり、必ずしも物理的に別個の要素に対応しない。すなわち、これらは、ハードウェア又はソフトウェアの形式で作られてもよく、１つ又は複数の集積回路で実装されてもよい。

例示的な実施例は、SIP制御コマンド及びRTPストリーミングを使用したコンテンツ配信の枠組み内にあるが、本発明はこの特定の実施例に限定されず、他の枠組み内にも適用可能である。

実施例によるシステム1が図１に示されている。システム1は、エンドユーザ端末2を有する。この端末は、パケット形式の第１のネットワーク5（インターネットネットワーク等）を通じて招待側ホーム（inviting home）3に接続される。特に、エンドユーザ端末は、SIP（Session Initiation Protocol）可能な端末であり、インターネットネットワークは、SIPパケットの伝送を可能にする。特に、エンドユーザ端末は、SIP機能を有するセルラ移動電話である。招待側ホームは、インターネットへのブロードバンドインタフェースを有する。

被招待側ホーム（invitee home）は、第２のネットワークを通じて招待側ホームに接続される。第２のネットワークは、第１のネットワークと同じ形式である。当然に、第１のネットワークと異なる形式のネットワークでもよい。実施例によれば、第２のネットワークは、インターネット形式であり、招待側ホーム及び被招待側ホームは、ブロードバンドインタフェースを通じて第２のネットワークに接続される。唯一の被招待側ホームが図１に示されているが、システムは１つより多くの被招待側ホームを有してもよい。

エンドユーザ装置は、アプリケーション（以下ではエンドユーザアプリケーションと呼ばれ、EUAと記載される）を有する。招待側ホームは、アプリケーションサーバ（ASと記載される）を有する。被招待側ホームは、アプリケーション（以下では被招待側アプリケーションと呼ばれ、IAと記載される）。以下では、EUA、AS及びIAは、招待側ホームと被招待側ホームとエンドユーザとの間にRTPセッションを設定して通信するものとして示される。

招待側ホームが図２に示されている。招待側ホーム2は、第１のネットワーク及び第２のネットワークとインタフェース接続するゲートウェイGWを有する。実施例によれば、第１のネットワーク及び第２のネットワークは、インターネットである。ゲートウェイはまた、ASに接続される。ASは、GW及びIP電話に接続される。招待側ホームはまた、ホームネットワークを有する。ホームネットワークは、複数のオーディオ／ビデオソース装置を有する。ホームネットワークは、Ethernet（登録商標）形式である。当然に、有線又は無線技術の如何なる形式のローカルエリアネットワークでもよい。オーディオ／ビデオソース装置は、ソース装置であり、被招待側ホームに配信されるオーディオ／ビデオコンテンツを格納する格納手段を有する。ゲートウェイ及びASはまた、ローカルホームネットワークに接続される。

アプリケーションサーバは、サーバ装置に埋め込まれる。当然に、アプリケーションサーバは、コンピュータ装置又はゲートウェイに埋め込まれてもよい。

エンドユーザ装置は、ASとSIPコマンドを送信及び受信するように適合されたエンドユーザアプリケーションEUAを有する。エンドユーザ装置はまた、ASとRTPセッションを管理するように適合される。EUAは、SIPアドレスでアドレス指定可能である。

被招待側ホームが図３に示されている。被招待側ホームは、第２のネットワークに接続するゲートウェイGWを有する。被招待側ホームは、ゲートウェイに接続された被招待側アプリケーションIAを有する。IP電話はIAに接続される。IA及びGWは、当業者に周知の形式のローカルネットワークに接続される。オーディオ／ビデオシンク装置もまた、ホームネットワークに接続される。オーディオ／ビデオシンク装置は、IAにより傍受された招待メッセージを受信するように、及び／又はRTPセッションでのオーディオ／ビデオコンテンツを受信するように適合される。IAは、ASと通信して実施例に示す全ての機能を実行する関連モジュール及び手段を有するアプリケーションである。IAはIA装置に埋め込まれてもよい。当然に、IAは、コンピュータ装置又はゲートウェイに埋め込まれたアプリケーションでもよい。

アプリケーションサーバが図４に示されている。アプリケーションサーバは、SIPメッセージを受信するためにゲートウェイへのインタフェースを有する。SIPメッセージ処理モジュールは、ゲートウェイから受信したSIPメッセージを傍受するように適合される。呼モジュールは、IP電話とSIPセッションを設定し、何らかの遠隔装置ともSIPセッションを設定するように適合される。ローカルコンテンツ情報モジュールは、コンテンツが利用可能な装置のリストと共に、ローカルネットワークで利用可能なコンテンツのリストを維持する。

設定されるRTPセッションが図５に示されている。RTPセッションは、招待設定とセッション設定とセッション制御とを有する。実施例による方法は、SDP型ペイロードを有するSIP型メッセージを使用する。招待ステップは以下に示される。

(0)EUAは、ノマディック（nomadic）エンドユーザのセルラ電話にダウンロードされる。セルラ電話が実施例による方法を実行可能にするために、セルラ電話はEUAをダウンロードする。これは、安全な方法でASからダウンロードされる。当然に、EUAはまた、インターネットに位置するサーバからダウンロードされてもよい。

(11)EUAは、１つ以上の被招待側とRTPセッションを設定したいという事実をASに示す。EUAは、招待側ホームとSIP型セッション（招待）を確立する。SIPセッションは、以下に示すステップ16まで続く。

EUAは、ホームのSIPアドレスでSIPメッセージを送信する。SIPメッセージは、セッション記述プロトコル（SDP：session description protocol）に従ったセッション招待を有する。当然に、SIPメッセージは、SIPメッセージに存在する場合にASがSIPメッセージを識別して傍受することを可能にする他の形式のフィールドを有してもよい。

SIPメッセージはゲートウェイで受信される。ゲートウェイは、SIPメッセージをASにルーティングする。ASは、SIPメッセージがSDPセッション記述メッセージを埋め込んでいることを検出する。ASはSIPメッセージを傍受し、SIPメッセージをIP電話に転送しない。

SDPメッセージを埋め込んだSIPメッセージは、ASに到達してホーム内のサービスへのアクセスを起動することを可能にする。

(12)ASが入来する招待を許可し、呼がホーム内のコンテンツへのアクセスの要求として認識されると、ホームネットワークで利用可能なオーディオ／ビデオコンテンツを検査する。ASはまた、コンテンツが送信され得る関係者（relative）のリストを維持する。次に、ASは、関連情報を含むSIPメッセージをEUAに返信する。関連情報は、招待側ホームで利用可能なオーディオ／ビデオコンテンツのリストと、コンテンツが送信され得る関係者のリストとを有する。

XMLフォーマットにされたこの情報は、EUAにより受信される。EUAは、データを端末画面に提示する。エンドユーザは、これらのデータをブラウズし、コンテンツ及びディレクトリの関係者を選択することができる。

関係者のリストはまた、EUAで既に利用可能になってもよい。EUAは、利用可能なコンテンツのリストを提供するようにASに要求するだけでよい。

利用可能なコンテンツのリストと共に、ASは、コンテンツに関係する全ての関連パラメータ（サイズ、符号化フォーマット、コンテンツがストリーミング可能なデータレート等）をEUAに示してもよい。また、コンテンツを受信することができるために受信機でサポートされるべき最小の要件を示してもよい。

(13)エンドユーザの選択情報は、ASに返信される。この情報は、選択されたオーディオ／ビデオの形式と被招待側のリストとを有する。RTPクライアントにコンテンツをストリーミングするために必要な情報も送信される。ASは、サービスセッションの期間にトークンを生成する。このトークンはホーム内の利用のためである。ASは、EUAから受信したその情報を登録する。

また、セッションが後に設定される場合には、選択されたオーディオ／ビデオ装置に通知してもよい。

(14)及び(15)ASは、ビデオ共有セッションに参加する招待を開始するために、被招待側ホームとSIP型メッセージを交換する。招待メッセージは、招待側ホームの指示とコンテンツの機能を有するコンテンツとを有する。このことにより、IAは、コンテンツが被招待側ホームの装置により受信可能であるか否かを認識することが可能になる。

IAのフィルタリング機能は、招待の有効性を検査する。招待が有効である場合、肯定応答がASに返信される。

(16)招待側ホームは、エンドユーザとのSIPセッションをクローズする。次に、被招待側による招待の許可又は拒否の待機期間が存在する。 この期間は可変である。被招待側は、直ちに応答してもよく、遅延の後に応答してもよい。この待機時間を制限するために、任意選択でタイムアウト機能が招待側ホームに実装されてもよい。

RTPセッションの設定について以下に示す。

招待されたホームからの招待の受信時に、被招待側ホームのIAは、被招待側ホームのユーザインタフェースでアラームを起動し、招待の受信をエンドユーザに警告する。AIは、コンテンツ及び／又はアラームの指示を受信するのに利用可能なローカルネットワークの装置を検出するローカル存在検出モジュールを有する。ローカルIP電話は、アラームメッセージを受信するために使用されてもよい。IAは、SIP電話へのSIP呼をシミュレートし、音声メールを電話に送信する。当然に、IAはまた、アラームメッセージを遠隔SIP電話に送信してもよい。

ユーザインタフェースは、招待の受信をエンドユーザに警告することを可能にする如何なる種類の手段でもよい。ラップトップ、テレビ、SIP電話、PDAのような如何なる種類の装置のディスプレイでもよい。アラームは、ディスプレイに現れるポップアップウィンドウでもよい。

アラームは、招待の受信をエンドユーザに警告することを目的としており、エンドユーザが招待を許可又は拒否する手段を提供する。

(21)被招待側が招待を許可すると、回答（yes/no）及びRTPチャネルの設定に関する更なる情報がSIPメッセージでASに送信される。これと並行して、被招待側ホームのシンク装置でRTPクライアントが開始される。RTPクライアントは、このようなオーディオ／ビデオストリームが受信されるとすぐに、RTPストリームを再生する準備ができている。

(22)(23)ASは、EUAにSIP招待メッセージを送信する。これは、RTPセッションが開始可能であることをエンドユーザ端末に通知することを目的とする。ASは、RTPセッションを開始するエンドユーザの許可を待機する。次に、EUAはマスターコントローラとして動作する。EUAは、関連のRTPチャネルの設定を起動し、オーディオ及びビデオストリームの再生を開始するためのコマンドをRTPソース装置に送信する。

これと並行して、エンドユーザ端末は、このようなストリームが受信されるとすぐに、RTPストリームを再生することができるRTPクライアントを開始する。

RTPソース装置へのコマンドは、２つのRTPクライアントが異なる位置で実行している２重の再生の場合に、エンドユーザが被招待側の前にコンテンツを見ることができることを確保するために、正確な同期で送信されなければならない。RTSP／RTPコマンドパラメータの利用により、必要に応じて精度の高い同期が達成できる。

被招待側及びエンドユーザの双方は、招待側ホーム位置で再生／停止／早送り／巻き戻しのような制御コマンドについてRTPS及びRTPメッセージに変換されるSIP型メッセージの利用により、コンテンツの再生を制御することができる。

エンドユーザからの制御コマンドの優先度は、被招待側からのものより高い。

複数の被招待側が同じRTPセッションに招待される場合、エンドユーザは、被招待側に異なる優先レベルを設定してもよい。

エンドユーザが招待側ホームへのアクセスを要求している場合、識別及び許可が必要になってもよい。エンドユーザがセッションを開始するために最初のSIP招待メッセージを送信している場合、SIPメッセージは、関連識別情報を含んでもよい。

被招待側ホームのIAは、招待側SIPアドレスに応じてSIP招待メッセージをフィルタリングし、予め決められたSIP URLのみが許可される。IAはまた、SIP本文のメッセージの主題（件名）に基づいて入来するSIPメッセージをフィルタリングしてもよい。これは、IAがSPAMのような招待を受信することを防止する。

被招待側ホームのIAは、ローカル存在検出情報を使用する。これは、ローカル被招待側ネットワークの関連するアプリケーションの存在を検出することを目的とする。更に、これは、IAが招待メッセージを処理する最善の端末を見つけることを可能にすることを目的とする。被招待側ホームのエンドユーザは、招待を許可してもよく、拒否してもよい。IAは、招待側アプリケーションサーバを介してエンドユーザの移動端末にSIPメッセージを返信し、エンドユーザに判定結果（許可／拒否）を通知する。

実施例による方法では、ASは、STPセッションが開始可能であることをEUAに通知する。次に、EUAがRTPセッションを開始するのを待機する。ここで、EUA及び被招待側は、RTPストリームの受信機である。

代替として、EUAは、RTPストリームの受信機でなくてもよい。被招待側のみがストリームの受信機でもよい。AIから回答を受信すると、ASは、EUAに通知せずに、直接RTPセッションを開始してもよい。ASはまた、選択された被招待側とRTPセッションが開始しているという事実のみをEUAに通知してもよい。EUAは、RTPセッションを制御し、関係する制御コマンドを実行してもよい。

この実施例は、１つの被招待側と１つのRTPクライアントとを有する方法を開示する。当然に、この実施例はまた、１つより多くの被招待側及び／又は１つより多くのRTPクライアントを有するシステムにも適用可能である。

詳細な説明、特許請求の範囲及び図面に開示された言及は、独立して提供されてもよく、如何なる組み合わせで提供されてもよい。必要に応じて、機能はハードウェア、ソフトウェア又はこれら２つの組み合わせで実装されてもよい。

“一実施例”又は“実施例”への言及は、実施例に関して記載した特定の特徴、構造又は特性が本発明の少なくとも１つの実装に含まれ得ることを意味する。明細書の様々な場所に“一実施例”という用語が現れることは、必ずしも同じ実施例を示しているとは限らず、他の実施例と相互排他的な別の実施例又は代替実施例であるとも限らない。特許請求の範囲に現れる参照符号は単なる例示目的であり、決して本発明の範囲に限定的な影響を与えるものではない。

Claims (8)

1. ローカルネットワークに位置するアプリケーションサーバでの方法であり、前記アプリケーションサーバは、第１のネットワークに接続される方法であって、
   前記第１のネットワークに位置する第１の装置から、ローカルネットワークに位置するローカル装置からコンテンツをストリーミングする要求を有するSIP型メッセージを受信するステップと、
   前記ローカルネットワークで利用可能なコンテンツのリストを有するSIP型メッセージを前記第１の装置に送信するステップと、
   前記コンテンツのリストから少なくとも１つのコンテンツのストリーミングを第３のネットワークに位置する少なくとも１つの受信機に対して開始するSIP型メッセージを前記第１の装置から受信するステップと、
   前記第３のネットワークに位置するアプリケーション受信モジュールにSIP型メッセージを送信し、前記少なくとも１つのコンテンツを受信するように前記少なくとも１つの受信機を招待するステップと
   を有する方法。
2. 前記コンテンツのリストは、前記コンテンツのストリーミングパラメータを有する、請求項１に記載の方法。
3. 前記アプリケーション受信モジュールから応答を受信するステップと、
   ストリーミングが開始可能であることを前記装置に通知するSIP型メッセージを前記第１の装置に送信するステップと、
   ストリーミングを開始するSIP型メッセージを前記第１の装置から受信するステップと
   を有する、請求項１又は２に記載の方法。
4. エンドユーザアプリケーションモジュールでの方法であって、
   ローカルネットワークに位置するローカル装置からコンテンツをストリーミングする要求を有するSIP型メッセージを、ローカルネットワークに接続されたアプリケーションサーバに送信するステップと、
   前記ローカルネットワークで利用可能なコンテンツのリストを有するSIP型メッセージを前記アプリケーションサーバから受信するステップと、
   前記コンテンツのリストから少なくとも１つのコンテンツのストリーミングを第３のネットワークに位置する少なくとも１つの受信機に対して開始するSIP型メッセージを前記アプリケーションサーバに送信するステップと
   を有する方法。
5. ストリーミングが開始可能であることを通知するSIP型メッセージを前記アプリケーションサーバから受信するステップと、
   ストリーミングを開始するSIP型メッセージを送信するステップと
   を有する、請求項４に記載の方法。
6. ストリーミングコンテンツを受信するステップを有する、請求項５に記載の方法。
7. ローカルネットワークに接続されたアプリケーション受信モジュールでの方法であって、
   ストリーミングコンテンツを受信するために前記ローカルネットワークに位置する少なくとも１つの受信機を招待するSIP型メッセージをアプリケーションサーバから受信するステップと、
   前記ローカルネットワークの少なくとも１つの装置が招待メッセージを処理するように識別された場合、前記コンテンツを受信するための応答を前記アプリケーションサーバに送信するステップと
   を有する方法。
8. プログラムがコンピュータ上で実行されたときに、請求項１に記載のセキュリティ処理のステップを実行するプログラムコード命令を有するコンピュータプログラム。