(57)【要約】【課題】  ネットワークを利用して合奏の効率的な練習を行えるように支援するための技術を提供する。【解決手段】  演奏者Ａ〜Ｃの３人のメンバーによる合奏を仮想的に実現させる場合、その合奏は３段階でそれぞれ行う演奏によって実現させる。第１段階で演奏者Ａが演奏を行って得られる演奏情報は、その次の第２段階の演奏を行う演奏者Ｂに送り、演奏者Ａの演奏を聴きながら演奏を行える環境を提供する。最終の第３段階で演奏を行う演奏者Ｃには、演奏者Ｂから、自身の演奏による演奏情報と併せて、演奏者Ａの演奏による演奏情報を送ることにより、演奏者Ａ、Ｂの演奏を聴きながら演奏を行える環境を提供する。そのようにして、各段階の演奏者には、より上流の段階に位置する演奏者の演奏を聴きながらの合奏を行える環境を提供する。【選択図】      図４
2007041174.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを利用して複数の演奏者による合奏を仮想的に可能とさせるための方法であって、
前記合奏を所望する演奏者毎に、該合奏のために演奏者が行った演奏内容を示す演奏情報を送信すべき他の演奏者を送信対象者として予め設定し、
前記設定により前記送信対象者が存在する演奏者が使用するそれぞれの端末装置に、該演奏者自身の演奏による演奏情報を前記ネットワーク上に送信させ、
前記設定により、前記送信対象者、及び自身を該送信対象者とする他の演奏者が共に存在する演奏者が使用するそれぞれの端末装置に、該他の演奏者の使用する端末装置から送信されて受信される演奏情報を更に前記ネットワーク上に送信させ、
前記送信対象者である各演奏者に、前記端末装置が受信する演奏情報による一人以上の演奏者の演奏と合わせた演奏をそれぞれ行わせて前記合奏を仮想的に実現させる、
ことを特徴とする合奏実現方法。
【請求項２】
ネットワークを介して接続される端末装置のユーザーを対象に合奏を仮想的に実現させるシステムであって、
前記ネットワークを介して、前記ユーザーが楽器に対して行なった演奏内容を示す演奏情報をリアルタイムに前記端末装置から受信する情報受信手段と、
複数のユーザーが合奏を行う場合に、該複数のユーザー間で予め設定される演奏情報を送受信すべき関係に従って、前記情報受信手段が受信した演奏情報を、該演奏情報を送信させた端末装置のユーザーによって特定されるユーザーの使用する端末装置に必要に応じて送信する情報送信手段と、
を具備することを特徴とするネット合奏システム。
【請求項３】
前記合奏のための演奏をユーザーが行っている端末装置から前記情報受信手段が受信する演奏情報を保存する情報保存手段、
を更に具備することを特徴とする請求項２記載のネット合奏システム。
【請求項４】
ネットワークを介して接続される端末装置のユーザーを対象に合奏を仮想的に実現させるネット合奏システムの構築に用いられるデータ処理装置に実行させるプログラムであって、
前記ネットワークを介して、前記ユーザーが楽器に対して行なった演奏内容を示す演奏情報をリアルタイムに前記端末装置から受信する機能と、
複数のユーザーが合奏を行う場合に、該複数のユーザー間で予め設定される演奏情報を送受信すべき関係に従って、前記受信する機能により受信した演奏情報を、該演奏情報を送信させた端末装置のユーザーによって特定されるユーザーの使用する端末装置に必要に応じて送信する機能と、
を実現させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークを利用して複数の演奏者による合奏を仮想的に可能とさせるための技術に関する。
【背景技術】
【０００２】
２つ以上の楽器によって行われる合奏は、一人で演奏するときとは異なる楽しさや充実感を味わうことができ、多くの人に楽しまれている。その合奏では、それを行う全てのメンバー（演奏者）が同じ場所に集まることが望まれる。しかし、それは個々のメンバーの都合や、時間的、或いは地理的な事情によって困難なことも少なくないのが実情である。このようなことから、例えば特許文献１に記載されているように、合奏を行う音楽活動を支援できるものが創案されている。
【０００３】
特許文献１に記載された従来のネット合奏システムでは、ネットワークを介して、各メンバーが行った演奏内容を示す演奏情報をそれぞれ取得し、それらを対応付けて記録するようにしている。それにより、各メンバーがそれぞれ行った演奏を合奏の結果として確認できるようにしている。特許文献２には、音楽的な不具合の発生を回避できるように、ネットワークを介して演奏情報を送信する技術が記載されている。
【０００４】
その従来のネット合奏システムでは、演奏開始を知らせることにより、各メンバーにそれぞれ並行して演奏を行わせるようになっている。そのために、各メンバーは基本的にそれぞれ自身の考えに沿った演奏を行っていた。
【０００５】
周知のように、合奏では全体的なまとまりを考慮する必要がある。そのまとまり感は、各メンバーがそれぞれ自身の考えに沿った演奏（独奏）を行っては得にくいのが実情である。合奏結果を確認することにより、各メンバーはまとまり感を考慮した演奏を行うことができる。しかし、そのためには、合奏結果の確認を随時、行わなければならないことから、演奏（合奏のための演奏）に割り当てられる時間はより短くなる。他のメンバーによる演奏内容を正確に把握するには何度も合奏結果を確認しなければならないのが普通であるから、他のメンバーによる演奏に合った演奏を行えるようになるには通常（同じ場所に集まっての合奏）よりも非常に時間がかかることになる。
【０００６】
上記のようなことから、特許文献１に記載された従来のネット合奏システムでは、所望の合奏を実現できるように効率的な練習を行うことは困難となっていた。考え方や感性は演奏者によって異なるのが普通であり、まとまり感のある合奏を行えるようにするには、数多く合奏の練習をしなければならないのが実情である。このことから、合奏の効率的な練習を行えるようにすることも極めて重要なことであると考えられる。
【特許文献１】特開２００４−２１２６３２号公報
【特許文献２】特開２０００−１８１４４７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
本発明の課題は、ネットワークを利用して合奏の効率的な練習を行えるように支援するための技術を提供することにある。
【課題を解決するための手段】
【０００８】
本発明の合奏実現方法は、ネットワークを利用して複数の演奏者による合奏を仮想的に可能とさせるための方法であって、合奏を所望する演奏者毎に、該合奏のために演奏者が行った演奏内容を示す演奏情報を送信すべき他の演奏者を送信対象者として予め設定し、設定により送信対象者が存在する演奏者が使用するそれぞれの端末装置に、該演奏者自身の演奏による演奏情報をネットワーク上に送信させ、設定により、送信対象者、及び自身を該送信対象者とする他の演奏者が共に存在する演奏者が使用するそれぞれの端末装置に、該他の演奏者の使用する端末装置から送信されて受信される演奏情報を更にネットワーク上に送信させ、送信対象者である各演奏者に、端末装置が受信する演奏情報による一人以上の演奏者の演奏と合わせた演奏をそれぞれ行わせて合奏を仮想的に実現させる。
【０００９】
本発明の第１の態様のネット合奏システムは、ネットワークを介して接続される端末装置のユーザーを対象に合奏を仮想的に実現させるシステムであって、ネットワークを介して、ユーザーが楽器に対して行なった演奏内容を示す演奏情報をリアルタイムに端末装置から受信する情報受信手段と、複数のユーザーが合奏を行う場合に、該複数のユーザー間で予め設定される演奏情報を送受信すべき関係に従って、情報受信手段が受信した演奏情報を、該演奏情報を送信させた端末装置のユーザーによって特定されるユーザーの使用する端末装置に必要に応じて送信する情報送信手段と、を具備する。
【００１０】
本発明の第２の態様のネット合奏システムは、上記第１の態様における構成に加えて、合奏のための演奏をユーザーが行っている端末装置から情報受信手段が受信する演奏情報を保存する情報保存手段、を更に具備する。
【００１１】
本発明のプログラムは、ネットワークを介して接続される端末装置のユーザーを対象に合奏を仮想的に実現させるネット合奏システムの構築に用いられるデータ処理装置に実行させることを前提とし、ネットワークを介して、ユーザーが楽器に対して行なった演奏内容を示す演奏情報をリアルタイムに端末装置から受信する機能と、複数のユーザーが合奏を行う場合に、該複数のユーザー間で予め設定される演奏情報を送受信すべき関係に従って、受信する機能により受信した演奏情報を、該演奏情報を送信させた端末装置のユーザーによって特定されるユーザーの使用する端末装置に必要に応じて送信する機能と、を実現させる。
【発明の効果】
【００１２】
本発明は、合奏を所望する演奏者毎に、その合奏のために演奏者が行った演奏内容を示す演奏情報を送信すべき他の演奏者を送信対象者として予め設定し、その送信対象者が存在する演奏者が使用するそれぞれの端末装置に、自身の演奏による演奏情報をネットワーク上に送信させ、送信対象者、及び自身を送信対象者とする他の演奏者が共に存在する演奏者が使用するそれぞれの端末装置に、その他の演奏者の使用する端末装置から送信されて受信される演奏情報を更にネットワーク上に送信させる。
【００１３】
そのような演奏情報の送受信を行うことにより、送信対象者である各演奏者には、ネットワークを介して、他の一人以上の演奏者の演奏によって得られる演奏情報が送られる。このため、送られる演奏情報によって再生可能な他の一人以上の演奏者の演奏と合わせた演奏を行える環境が提供される。その環境の提供により、送信対象者である演奏者は他の演奏者との合奏を実質的に行える形となる。その結果、よりまとまり感の得られる演奏、或いは全体としてより所望の音楽表現が実現される演奏がより容易となる。
【００１４】
それは、合奏上、より望ましい演奏をより容易に行えるようになることを意味する。このことから、他の演奏者の演奏を聴かないで合奏の練習（演奏）を行う場合と比較して、より質の高い練習を行えるようになる。より多くの演奏者が合奏上、より質の高い演奏を行えるようになるから、合奏結果の確認もより容易、且つより短い時間で行えるようになる。それらは何れもより効率的な練習を行えるように作用する。
【発明を実施するための最良の形態】
【００１５】
以下、本発明の実施の形態について、図面を参照しながら詳細に説明する。
図１は、本実施の形態によるネット合奏システムを用いて構築されたネットワークシステムの構成を説明する図である。
【００１６】
そのネットワークシステムは、図１に示すように、ネットワーク１に対し、サーバー２、各視聴者がそれぞれ使用する端末装置である複数のパーソナルコンピュータ（ＰＣ）３、及び各演奏者がそれぞれ使用する端末装置である複数のＰＣ４、が接続されて構築されている。
【００１７】
上記ネットワーク１は、例えばインターネット、及びＰＣ３、或いは４をインターネットと接続する公衆網を含むものである。演奏者用のＰＣ４にはそれぞれ、そのユーザーが演奏を行う電子楽器５が接続されている。そのＰＣ４は、電子楽器５への演奏操作の内容を示す演奏情報をサーバー２に送信する。そのサーバー２は、ＰＣ４から送信された演奏情報を受信し、他のＰＣ４、或いはＰＣ３に必要に応じて自動的に送信するサービスを提供する。そのサービスにより、ＰＣ３のユーザーはＰＣ４のユーザーによる演奏を視聴できるようになっている。本実施の形態によるネット合奏システムは、そのサーバー２上に実現されている。
【００１８】
図２は、上記サーバー２の構成を説明する図である。図２に示すように、サーバー２は、全体の制御を行うＣＰＵ２１と、そのＣＰＵ２１がワークに用いるＲＡＭ２２と、電源投入時に実行される起動用のプログラム等を格納したＲＯＭ２３と、ネットワーク１を介した通信を行うためのネットワークインターフェース２４と、例えばキーボードやポインティングデバイス（マウス等）、ＣＤ−ＲＯＭやＤＶＤ等の記録媒体にアクセスする媒体駆動装置、及びそれらのインターフェース等からなる入力装置２５と、表示装置に画像を表示させる表示部２６と、例えばハードディスク装置である補助記憶装置２７と、それら各部２１〜２７を互いに接続するバス２８と、を備えた構成となっている。
【００１９】
電源が投入されると、ＣＰＵ２１はＲＯＭ２３に格納された起動用のプログラム読み出して実行することにより、その制御によって補助記憶装置２７にアクセスする。そのアクセスにより、補助記憶装置２７に格納されたＯＳ（オペレーティングシステム）を読み出し、そのＯＳに制御を移す。それ以降は、ＯＳ上で動作するアプリケーション・プログラム（以降「アプリケーション」と略記）を実行する。上記サービスは、対応するアプリケーションを実行することで実現される。
【００２０】
図３は、上記ＰＣ４、及び電子楽器５の構成を説明する図である。
そのＰＣ４は、図３に示すように、ＣＰＵ４１、ＲＡＭ４２、ＲＯＭ４３、ネットワークインターフェース４４、入力装置４５、表示部４６、ＭＩＤＩインターフェース（Ｉ／Ｆ）４７、補助記憶装置４８、及びバス４９を備えた構成となっている。それにより、上記サーバー２と殆ど同じ構成となっている。サーバー２に存在しないＭＩＤＩ  Ｉ／Ｆ４７は、電子楽器５とＭＩＤＩデータの送受信を行うためのものである。
【００２１】
その電子楽器５は、図３に示すように、ＰＣ４とＭＩＤＩデータの送受信を行うためのＭＩＤＩ  Ｉ／Ｆ５１と、演奏操作の対象となるキーボード５２と、放音すべき楽音の波形データを生成して放音する音源・サウンドシステム（以降「音源システム」と略記）５３と、を備えた構成となっている。
【００２２】
電子楽器５のキーボード５２は、例えばユーザーの鍵への操作を検出し、操作を検出した鍵、及びその操作内容を示す操作情報をＭＩＤＩ  Ｉ／Ｆ５１に出力する。そのＩ／Ｆ５１は、例えばその操作情報に対応するＭＩＤＩデータを生成して音源システム５３、及びＰＣ４のＭＩＤＩ  Ｉ／Ｆ４７にそれぞれ出力する。そのＩ／Ｆ４７から入力したＭＩＤＩデータも音源システム５３に出力する。それにより、ユーザーのキーボード５２に対する演奏操作に応じた楽音の放音、及びＰＣ４から出力されたＭＩＤＩデータによる楽音の放音を行わせるようになっている。このことから、ＰＣ４とそれに接続された電子楽器５は、ネットワーク５を介し、ユーザーが電子楽器５に対して行った演奏内容を示す演奏情報を送受信できる演奏者用システムを構成している。本実施の形態では、その演奏情報としてＭＩＤＩデータを採用している。
【００２３】
他方のＰＣ３は、ＰＣ４の構成と同じか、或いは音源システム５３に相当するシステムを搭載しているものである。ここでは説明上、便宜的に、図３に示す構成において、ＭＩＤＩ  Ｉ／Ｆ４７の代わりに音源システム５３を搭載していると想定する。その想定により、構成要素の符号としてＰＣ４のそれを用いることにする。
【００２４】
ＰＣ３、４は、電源が投入されると、ＣＰＵ４１はＲＯＭ４３に格納された起動用のプログラム読み出して実行することにより、その制御によって補助記憶装置４８にアクセスする。そのアクセスにより、補助記憶装置４８に格納されたＯＳ（オペレーティングシステム）を読み出し、そのＯＳに制御を移す。それ以降は、入力装置４５を介したユーザーの指示に応じた制御を行う。ＯＳ上で動作するアプリケーション・プログラム（以降「アプリケーション」と略記）の起動／終了は、その制御によって実現される。
【００２５】
図４は、仮想的な合奏の実現方法を説明する図である。その実現方法は、演奏者Ａ〜Ｃの３人のメンバーによる合奏を仮想的に実現させる場合のものである。
本実施の形態では、図４に示すように、演奏者Ａ〜Ｃの３人のメンバーによる仮想的な合奏は３段階でそれぞれ行う演奏によって実現させるようにしている。第１段階で演奏者Ａが演奏を行って得られる演奏情報は、その次の第２段階の演奏を行う演奏者Ｂに送ることにより、その演奏を聴きながら演奏を行える環境（演奏者Ａとの合奏を行える環境）を演奏者Ｂに提供する。最終の第３段階で演奏を行う演奏者Ｃには、演奏者Ｂから、自身の演奏による演奏情報と共に、演奏者Ａの演奏による演奏情報を送ることにより、演奏者Ａ、Ｂの演奏を聴きながら演奏を行える環境（演奏者Ａ、Ｂとの合奏を行える環境）を演奏者Ｃに提供する。その第３段階で演奏者Ｃが演奏を行うことにより、全ての演奏者Ａ〜Ｃによる合奏の最終結果が得られる。視聴者Ｄは、その結果として得られる、各演奏者Ａ〜Ｃの演奏による演奏情報が送られる人であり、演奏者Ａ〜Ｃの何れも視聴者Ｄとなることができる。
【００２６】
このようにして、本実施の形態では、各演奏段階で演奏を行う演奏者に対し、それよりも上流に位置する演奏段階で行われた演奏による演奏情報を提供することにより、第１段階（最上流の演奏段階）で演奏を行う演奏者Ａ以外は、それよりも上流の演奏段階で行われた演奏を聴きながら、その演奏に合わせた演奏（合奏）を行えるようにさせている。このため、第１段階以外の演奏段階の演奏者にとっては、全体としてまとまり感のある（所望の音楽表現が実現されている）合奏結果が得られるような演奏、つまり合奏のためのより適切な演奏を容易に行うことができるようになる。それにより、合奏のための演奏はより効率的に練習できることとなる。
【００２７】
第１段階以外の演奏段階の演奏者が合奏上、より質の高い演奏を行えるようになると、合奏上、望ましくない演奏方法や演奏箇所はより少なくなる。このため、合奏結果の確認もより容易に行えるようになって、その確認に必要な時間はより短縮させることができる。このことからも、より効率的な練習を行えることとなる。
【００２８】
第１段階の演奏者Ａは、その演奏を聴きながら他の演奏者が演奏を行うことから、他の演奏者が合わせるべき演奏を行う者、合奏曲のベースとなる演奏を行う者、或いは最も演奏の上手な者、とすることが望ましい。そのような者を演奏者Ａとすることにより、より望ましい合奏結果がより容易に得られるようになる。
【００２９】
なお、本実施の形態では、各演奏段階の演奏者を一人のみとしているが、第１段階以外の演奏段階の演奏者は複数であっても良い。その場合、複数の演奏者全てに同じ種類の楽器、或いはパートを演奏させる必要はない。演奏段階数は、２つ以上であればあれば良く、合奏曲、演奏者数、及び演奏するパート数等を考慮して適宜、決定すれば良い。ネットワーク１上に送信される演奏情報はその送信元（演奏者）が明らかとなっているので、何れの演奏段階に複数の演奏者が存在していても、演奏者毎にその演奏情報をまとめることができる。
【００３０】
演奏段階に分けて各演奏者に演奏を行わせる場合、各演奏者に演奏情報を送るべき相手、その演奏者から演奏情報を送るべき相手はその演奏者の演奏段階に応じて自動的に特定することができる。このことから本実施の形態では、図４に示すような実現方法を採用しているが、演奏者に演奏情報を送信すべき他の演奏者を演奏者毎に個別に設定するようにしても良い。演奏情報を送信する流れのパターン（例えば演奏位置と演奏情報が送受信される演奏位置の関係を示すもの）を幾つか用意し、そのパターン上で各演奏者の演奏位置を指定するようにしても良い。当然のことながら、別の方法を採用しても良い。
【００３１】
図４に示すような合奏は、サーバー２、ＰＣ４（ＰＣ３）のＣＰＵ２１、４１がそれぞれ専用のアプリケーションを実行することで実現される。以降は、図５〜図１６の説明図を参照して、サーバー２、ＰＣ４別に、合奏を実現させるための動作について詳細に説明する。
【００３２】
サーバー２は、ＰＣ４間に入って図４に示すような演奏情報の送受信を実現させるサービス（合奏サービス）を提供する。ＰＣ３のユーザー（視聴者Ｄ）に対しては、合奏結果として保存した演奏情報を提供するサービス（視聴サービス）を行う。それらのサービスを提供するために、図５に示すようなデータを管理している。図５（ａ）はサービスを提供するＰＣ３、４のユーザーを管理するためのユーザーデータベース（ＤＢ）のデータ構成を示し、図５（ｂ）はＰＣ４間のデータの送受信用のリングバッファの構成を示している。
【００３３】
図５（ａ）に示すように、ユーザーＤＢには、ユーザー毎に、データｉＦＤ、ｃＵｓｅｒＩＤ、ｃＳｔａｔ、及びｃＵｓｅｒＭｏｄｅが格納されている。データｉＦＤは、ユーザー毎に異なる通信識別用番号であり、ＰＣ３、４は送信するデータにそれを付加するようになっている。データｃＵｓｅｒＩＤはユーザーＩＤ、データｃＳｔａｔは対応するユーザーが接続（ログオン）状態か否かを管理するためのデータ、データｃＵｓｅｒＭｏｄｅは対応するユーザーのモードを管理するためのデータである。そのユーザーモードとしては、ここでは演奏者Ａ〜Ｃ、及び視聴者Ｄのみを考慮することとする。
【００３４】
上記リングバッファは、図５（ｂ）に示すように、「ｂｕｆｆｅｒ」を表記した部分（以降「データバッファ」と呼ぶ）、「ｉＳｉｚｅ」を表記した部分（以降「サイズバッファ」と呼ぶ）、及び「ｉＵＤＢｉｄ」を表記した部分（以降「ユーザーバッファ」と呼ぶ）の３つの部分から構成されている。データバッファにはＰＣ４から受信したデータの本体（実体）が格納される。サイズバッファには、データバッファに格納されたデータのサイズが格納される。ユーザーバッファには、データバッファに格納されたデータを送信させたユーザーを示す識別情報（ここではデータｉＦＤ）が格納される。それにより、リングバッファは、データ本体、データサイズ、及びデータを送信させたユーザーのデータを格納したユーザーＤＢ中のレコードを示すインデクス値をセットで参照できるようになっている。図５（ａ）において［］内に表記の「０」や「ｎ」はそのインデクス値を表している。データのサイズ、及び識別情報は受信データ中から抽出される。
【００３５】
上記ユーザーＤＢは、補助記憶装置２７に保存されており、ＲＡＭ２２に読み出されて参照・更新される。上記リングバッファはＲＡＭ２２に確保された領域である。
図７は、サーバー２が実行する全体処理のフローチャートである。その全体処理は、上記合奏サービス、及び視聴サービスを提供するためにサーバー２が実行する処理を抜粋してその流れを示したものである。それらサービス提供用のアプリケーションを補助記憶装置２７からＲＡＭ２２に読み出してＣＰＵ２１が実行することで実現される。次に図７を参照して、その全体処理について詳細に説明する。
【００３６】
先ず、ステップ１０１では、ユーザーＤＢの読み込みや、各種変数、及びリングバッファの初期化、クライアントであるＰＣ３、４との送受信準備といった初期化を行う。その次に移行するステップ１０２では、並行して実行すべきスレッドを起動させる。そのスレッドの一つとして、図９にフローチャートを示す送信スレッドが存在する。その送信スレッドは、ＰＣ４間のデータの送受信を実現させるためのものである。
【００３７】
ステップ１０２に続くステップ１０３では、変数ｉＣｏｎｔに１を代入する。その代入後はステップ１０４に移行して、変数ｉＣｏｎｔの値は１か否か判定する。その値が１であった場合、判定はＹＥＳとなってステップ１０５に移行し、そうでない場合には、判定はＮＯとなり、ここで一連の処理を終了する。このように変数ｉＣｏｎｔは、アプリケーションの終了を管理するためのものであり、特に詳細な説明は省略するが、管理者の終了指示によって、他のアプリケーション、或いはＯＳが１以外の値を代入するようになっている。
【００３８】
ステップ１０５では、ＰＣ３、４（以降「クライアント」と総称する）からデータを受信するのを待つ。そのデータをネットワークインターフェース２４が受信すると、判定がＹＥＳとなってステップ１０６に移行し、変数ｆｄに０を代入する。その次に移行するステップ１０７では、変数ｆｄの値が、受信データに含まれているデータｉＦＤの値と一致するか否か判定する。それらの値が一致する場合、判定はＹＥＳとなってステップ１０９に移行する。そうでない場合には、判定はＮＯとなり、ステップ１０８で変数ｆｄの値をインクリメントした後、再度、ステップ１０７の判定処理を行う。それにより、受信データに含まれているデータｉＦＤの値の特定を行う。
【００３９】
ステップ１０９では、受信データがログオフを要求するものか否か判定する。そのログオフを要求するものであった場合、判定はＹＥＳとなってステップ１１０に移行し、ユーザーＤＢのログオフを要求したユーザーのレコードに格納されているデータｃＳｔａｔをログオフのものに更新するとともに、ログオン中のユーザーが使用するクライアントにログオフしたユーザーを通知するための情報をネットワークインターフェース２４により送信させた後、上記ステップ１０５に戻る。そうでない場合には、判定はＮＯとなってステップ１１１に移行する。
【００４０】
ステップ１１１では、リングバッファを構成するデータバッファのなかで受信データを格納すべき場所を示す値（図中「リングバッファポインター」と表記）を変数ｂｕｆに代入する。その受信データのデータバッファへの格納に対応して、サイズバッファ、及びユーザーバッファにそれぞれデータを格納すべき場所を示す値（図中、共に「リングバッファポインター」と表記）を変数ｉＳｉｚｅＰｔｒ、及びｉＵＤＢＰｔｒに代入する（ステップ１１２、１１３）。その代入後はステップ１１４に移行して、データバッファ中の変数ｂｕｆの値で指定される場所から受信データを格納し、サイズバッファ中の変数ｉＳｉｚｅＰｔｒの値で指定される場所にそのサイズ（を示す値）を格納する。ステップ１１５にはその格納後に移行する。
【００４１】
ステップ１１５では、変数ｊに０を代入する。続くステップ１１６では、ユーザーＤＢの変数ｊの値をインデクス値として持つレコードに格納されているデータｉＦＤ（図中「ｕｄｂ［ｊ］．ｉＦＤ」と表記。他のデータも同様の表記法を用いる）の値が上記変数ｆｄの値と一致するか否か判定する。それらの値が一致する場合、判定はＹＥＳとなってステップ１１８に移行する。そうでない場合には、判定はＮＯとなり、ステップ１１７で変数ｊの値をインクリメントした後、再度ステップ１１６の判定処理を行う。それにより、受信データを送信させたユーザーに対応するレコードのインデクス値の特定を行う。
【００４２】
ステップ１１８では、ユーザーバッファ中の変数ｉＵＤＢＰｔｒの値で指定される場所に、受信データを送信させたユーザーに対応するレコードのインデクス値として変数ｊの値を格納する。次のステップ１１９では、データバッファ、サイズバッファ、及びユーザーバッファのそれぞれにおいて、次のデータを格納すべき場所を示す値（図中「リングバッファポインター」と表記）を更新する。それらの更新後はステップ１２０に移行する。
【００４３】
クライアントのユーザーがサーバー２に対してログオフ以外の要求を行う場合にも、そのクライアントからその要求に応じたデータがサーバー２に送信される。ステップ１２０以降では、そのようなデータに対応するための処理が行われる。ここではその要求として、ログオン要求、モード変更要求、録音要求、及び再生要求のみを想定することとする。録音要求は、視聴者Ｄが視聴の対象とする合奏結果の録音（保存）を要求するためのものであり、再生要求はその合奏結果の再生を要求するためのものである。
【００４４】
先ず、ステップ１２０では、受信データがログオンを要求するものか否か判定する。そのログオンを要求するものであった場合、判定はＹＥＳとなってステップ１２１に移行し、認証処理を実行した後、上記ステップ１０５に戻る。そうでない場合には、判定はＮＯとなってステップ１２２に移行し、受信データがユーザーモードの変更を要求するものか否か判定する。そのモードの変更を要求するものであった場合、判定はＹＥＳとなり、ステップ１２３でその要求に対応するためのユーザーモード更新処理を実行した後、上記ステップ１０５に戻る。そうでない場合には、判定はＮＯとなってステップ１２４に移行する。
【００４５】
上記ステップ１２３のユーザーモード更新処理では、ユーザーＤＢのなかで変数ｊの値をインデクス値とするレコードに格納されているデータｃＵｓｅｒＭｏｄｅを、受信データで指定されたモードを表すものに更新する。そのような更新を行うことにより、クライアントのユーザーは演奏者Ａ〜Ｃ、視聴者Ｄのうちの何れかに任意に変更できるようになっている。ユーザーモードを変更したレコードは、ログオン中のユーザーが使用するクライアント全てに送信する。
【００４６】
ステップ１２４では、受信データが録音、或いは再生を要求するものか否か判定する。その録音、或いは再生を要求するものであった場合、判定はＹＥＳとなってステップ１２５に移行し、要求された録音、或いは再生を開始するための処理を実行した後、上記ステップ１０５に戻る。そうでない場合には、判定はＮＯとなってそのステップ１０５に戻る。
【００４７】
図８は、上記ステップ１２１として実行される認証処理のフローチャートである。次に図８を参照して、その認証処理について詳細に説明する。
本実施の形態では、上述したように、サーバー２によるサービスを利用するには専用のアプリケーションをクライアントに実行させるようにしている。そのアプリケーションは、アプリケーション毎に異なるＩＤ（データｃＵｓｅｒＩＤ）と共にＣＤ−ＲＯＭ等の記録媒体に記録して、ネットワークを利用した合奏を望む人を対象に配布している。そのアプリケーションは、ログオン要求時に自身に割り当てられたデータｃＵｓｅｒＩＤを送信するようになっている。
【００４８】
ユーザーＤＢに格納されるデータｉＦＤは、ログオンを要求したユーザーに、そのときの状況に応じて割り当てるようにしている。このため、受信データがログオン要求のためのものであった場合、その受信データにはデータｉＦＤに対応するものが付加されていない。そのような受信データに対応するために、特には図示していないが、上記ステップ１０７では受信データにデータｃＵｓｅｒＩＤが付加されていればＹＥＳと判定するようにしている。また、上記ステップ１１６、１１７で形成される処理ループでは、データが格納されていないレコードが見つかるまで、変数ｊの値をインデクス値とするレコードのデータｉＦＤを順次、参照することにより、データｉＦＤとして割り当て可能な値（例えば最小値）を特定し、その特定した値を変数ｆｄに代入するようになっている。認証処理は、そのような値が変数ｆｄに代入されている状況下で実行される。
【００４９】
先ず、ステップ２０１では、変数ｊに０を代入する。続くステップ２０２では、ユーザーＤＢの変数ｊの値をインデクス値とするレコードを参照し、そのレコードにデータが格納されていないか否か判定する。ユーザーＤＢは、データが格納されたレコードは連続するインデクス値の何れかで指定できるようにしている。つまり、ユーザー登録の抹消によりデータを消去したレコードが一つ発生すると、それよりも大きいインデクス値の各レコードのデータをそれまでより一つ小さいインデクス値のレコードにそれぞれコピーするようにしている。このことから、データが格納されている全てのレコードを参照した場合、次に変数ｊの値によって参照するレコードにはデータが格納されていないこととなる。その結果、判定はＹＥＳとなってステップ２０８に移行する。そうでない場合には、判定はＮＯとなってステップ２０３に移行する。そのＹＥＳの判定は、未登録のユーザーがログオン要求を行ったことを意味する。
【００５０】
ステップ２０３では、参照するレコードのデータｃＵｓｅｒＩＤが受信データに存在するデータｃＵｓｅｒＩＤと同じか否か判定する。それらが同じものであった場合、判定はＹＥＳとなってステップ２０５に移行する。そうでない場合には、判定はＮＯとなり、ステップ２０４で変数ｊの値をインクリメントした後、上記ステップ２０２に戻る。そのＹＥＳの判定は、登録済みのユーザーがログオン要求を行ったことを意味する。
【００５１】
ステップ２０５では、ユーザーＤＢの変数ｊの値をインデクス値として持つレコードのデータｉＦＤ（図中「ｕｄｂ［ｊ］．ｉＦＤ」と表記）として変数ｆｄの値を格納する。続くステップ２０６では、そのレコードのデータｃＳｔａｔとして、ログオン状態であることを示す値の１を格納する。次に移行するステップ２０７では、そのレコードのデータｃＵｓｅｒＭｏｄｅとして演奏者Ａを表す値の１を格納し、ユーザーバッファ中の変数ｉＵＤＢＰｔｒのステップ１１９で更新する前の値で指定される場所に、受信データを送信させたユーザーに対応するレコードのインデクス値として変数ｊの値を格納する。その格納を行った後に、認証を行ったユーザーのクライアントにユーザーＤＢを送信する。そのユーザーのレコードは、ログオン中となっている他のユーザーのクライアント全てに送信する。そのような送信を行った後、一連の処理を終了する。
【００５２】
上記全体処理では、受信データを送信させたユーザーに対応するレコードのインデクス値として変数ｊの値をステップ１１８でユーザーバッファに格納するようになっている。しかし、受信データがログオン要求のためのものであった場合、受信データにはデータｉＦＤが付加されていないことから、その変数ｊの値は正しいインデクス値となっていない。このことから、認証処理ではユーザーバッファに格納したインデクス値を正しいインデクス値に更新するようにしている。
【００５３】
上記ステップ２０２の判定がＹＥＳとなって移行するステップ２０８では、変数ｊに０を代入する。次のステップ２０９では、ユーザーＤＢの変数ｊの値をインデクス値とするレコードを参照し、それがデータの格納されていないレコード（未登録エリア）か否か判定する。参照したレコードにデータが格納されていない場合、判定はＹＥＳとなり、ステップ２１１でｕｄｂ［ｊ］．ｉＦＤとして変数ｆｄの値、ｕｄｂ［ｊ］．ｃＵｓｅｒＩＤとして受信データに付加されているデータｃＵｓｅｒＩＤをそれぞれ格納した後、上記ステップ２０６に移行する。そうでない場合には、判定はＮＯとなり、ステップ２１０で変数ｊの値をインクリメントした後、再度、ステップ２０９の判定処理を行う。
【００５４】
図９は、上記送信スレッドの実行によって実現される処理のフローチャートである。その送信スレッドは、図７に示す全体処理内のステップ１０２で起動される。次に図９を参照して、その送信スレッドについて詳細に説明する。その送信スレッドは、上述したように、ＰＣ４間のデータの送受信を実現させるためのものである（図４）。
【００５５】
先ず、ステップ３０１では、送信スレッドの終了を管理するための変数ｉＳｅｎｄＴｈｒｅａｄに１を代入する。続くステップ３０２では、その変数ｉＳｅｎｄＴｈｒｅａｄの値が１か否か判定する。その値が１でなかった場合、判定はＮＯとなってステップ３１８に移行する。そうでない場合には、判定はＹＥＳとなってステップ３０３に移行する。特に詳細な説明は省略するが、変数ｉＳｅｎｄＴｈｒｅａｄへの１以外の値の代入は、例えばＰＣ４からの合奏の停止要求、録音中であれば録音停止要求によって図７に示す全体処理を実現させるアプリケーションが行うようになっている。再度の１の代入は、合奏の開始要求によってそのアプリケーションが行う。
【００５６】
上述したように、クライアント間で送受信させるデータはリングバッファ（図５）に一時的に格納するようになっている。ステップ３０３では、そのリングバッファに送信の対象となるデータがないか否か判定する。そのようなデータがリングバッファに存在していない場合、判定はＹＥＳとなって上記ステップ３０２に戻る。そうでない場合には、判定はＹＥＳとなり、次のステップ３０４で変数ｉに０を代入した後、ステップ３０５に移行する。
【００５７】
ステップ３０５以降では、変数ｉの値を順次、インクリメントしながら、その値をインデクス値とするレコードにデータが格納されたユーザーに、リングバッファに格納されている送信すべき受信データを送信するための処理が行われる。
【００５８】
先ず、ステップ３０５では、変数ｉの値がユーザーＤＢに登録済みのユーザー数ＭＡＸ＿ＵＳＥＲ未満か否か判定する。変数ｉに初期値として代入する値は０であり、その値を順次、インクリメントして更新するようにしている。このため、受信データの送信を考慮すべきユーザーの全てに送信すべき受信データの送信を行った場合、変数ｉの値はユーザー数ＭＡＸ＿ＵＳＥＲ以上となる。その結果、判定はＮＯとなって上記ステップ３０３に戻る。そうでない場合には、判定はＹＥＳとなってステップ３０６に移行する。
【００５９】
ステップ３０６では、リングバッファに格納されている送信対象の受信データがユーザーモード変更要求のためのものか否か判定する。その要求のためのものであった場合、判定はＹＥＳとなり、ステップ３０７で受信データを、変数ｉの値をインデクス値とするレコードにデータが格納されているユーザー宛に送信し、更にステップ３０８で変数ｉの値をインクリメントした後、上記ステップ３０５に戻る。一方、そうでない場合には、判定はＮＯとなってステップ３０９に移行する。
【００６０】
上記ステップ３０７では、受信データと併せてリングバッファに格納されたインデクス値が変数ｉの値と一致している場合、その受信データの送信は行わない。それにより、データを受信したクライアントにそのデータを送信することを回避させている。
【００６１】
ステップ３０９では、送信対象の受信データが録音、或いは再生を指示するためのものか否か判定する。そのような指示のためのものであった場合、判定はＹＥＳとなって上記ステップ３０７に移行する。そうでない場合には、判定はＮＯとなってステップ３１０に移行する。
【００６２】
このようにして本実施の形態では、演奏情報（ＭＩＤＩデータ）以外の受信データは他のユーザーに送信している。それにより、ログオンさせている他のユーザーのユーザーモード、他のユーザーが行っている要求を把握できるようにさせている。これは、合奏を行うためには他のユーザーの動きを把握する必要があるためである。録音の指示のための受信データを送信することにより、合奏を行う演奏者にとっては、録音の開始に合わせて合奏を開始させることができる。視聴者Ｄにとっては、そのような合奏の開始を知ることができる。
【００６３】
ステップ３１０では、受信データと併せてリングバッファに格納されたインデクス値を変数ｉＵＤＢｆｒに代入する。次のステップ３１１では、変数ａに、ユーザーＤＢの変数ｉＵＤＢｆｒの値をインデクス値とするレコードに格納されているデータｃＵｓｅｒＭｏｄｅを代入する。その次のステップ３１２では、変数ｂに、ユーザーＤＢの変数ｉの値をインデクス値とするレコードに格納されているデータｃＵｓｅｒＭｏｄｅを代入する。ステップ３１３にはその後に移行する。上記想定により、ステップ３１３への移行は送信対象とする受信データがＭＩＤＩデータであることを意味する。そのＭＩＤＩデータには、処理すべきタイミングを示す時間データが付加されている。
【００６４】
ステップ３１３では、変数ａの値が示すユーザーモードは演奏者Ａであり、且つ変数ｂの値が示すユーザーモードは演奏者Ｂであるか否か判定する。受信データが演奏者ＡをユーザーモードとするユーザーのＰＣ４から送信されたＭＩＤＩデータ（を含む演奏情報）であり、且つその受信データの送信を考慮しているユーザーのユーザーモードが演奏者Ｂであった場合、判定はＹＥＳとなってステップ３０７に移行する。そうでない場合には、判定はＮＯとなってステップ３１４に移行する。
【００６５】
ステップ３１４では、変数ａの値が示すユーザーモードは演奏者Ｂであり、且つ変数ｂの値が示すユーザーモードは演奏者Ｃであるか否か判定する。受信データが演奏者ＢをユーザーモードとするユーザーのＰＣ４から送信されたＭＩＤＩデータ（を含む演奏情報）であり、且つその受信データの送信を考慮しているユーザーのユーザーモードが演奏者Ｃであった場合、判定はＹＥＳとなってステップ３０７に移行する。そうでない場合には、判定はＮＯとなってステップ３１５に移行する。
【００６６】
ステップ３１５では、変数ａの値が示すユーザーモードは演奏者Ｃであり、且つ変数ｂの値が示すユーザーモードは視聴者Ｄであるか否か判定する。受信データが演奏者ＣをユーザーモードとするユーザーのＰＣ４から送信されたＭＩＤＩデータ（を含む演奏情報）であり、且つその受信データの送信を考慮しているユーザーのユーザーモードが視聴者Ｄであった場合、判定はＹＥＳとなってステップ３１６に移行する。そうでない場合には、判定はＮＯとなってステップ３０８に移行する。
【００６７】
このようにして、ＰＣ４からサーバー２に送信された演奏情報は、そのユーザーによって特定される、それを送信すべきユーザーに限定して送信する。それにより、図４に示すような演奏情報の流れが実現される。
【００６８】
ステップ３１６では、録音を行っているか否か判定する。その録音を行っている場合、判定はＹＥＳとなり、ステップ３１７で受信データを録音用に確保したバッファに保存した後、上記ステップ３０７に移行する。そうでない場合には、判定はＮＯとなり、他のステップの処理を実行することなく、そのステップ３０７に移行する。
【００６９】
上記ステップ３０２の判定がＮＯとなって移行するステップ３１８でも同様に、録音を行っているか否か判定する。その録音を行っている場合、判定はＹＥＳとなり、録音用に確保したバッファに保存した受信データ（演奏情報）をステップ３１９でファイルとして保存した後、一連の処理を終了する。そうでない場合には、判定はＮＯとなり、ここで一連の処理を終了する。
【００７０】
図１０は、再生スレッドの実行によって実現される処理のフローチャートである。その再生スレッドは、再生指示のためのデータを受信した場合に、図７に示す全体処理内のステップ１２５で起動される。次に図１０を参照して、その再生スレッドについて詳細に説明する。その再生スレッドは、上述したようにファイルとして保存した演奏情報を随時、ログオン中の全てのユーザーのクライアントに送信することにより、そのクライアントに合奏結果を再生させて視聴させるためのものである。演奏情報の送信は、再生指示を行った後、再生開始を指示することで開始される。
【００７１】
その演奏情報は、ＭＩＤＩデータに時間データを付加したものである。ＰＣ４は、その時間データとして、ＭＩＤＩデータの発生時刻（を示す値）を付加している。その発生時刻は、ＭＩＤＩデータがキーボード５２への演奏操作によって生成されたものであればその演奏操作が行われた時刻であり、そのＭＩＤＩデータが受信したものであればそれを処理した時刻である。その時刻は、ＣＰＵ２１に搭載されたハードタイマから取得されるものである。これはＰＣ４（ＰＣ３）でも同様である。
【００７２】
先ず、ステップ４０１では、再生スレッドの終了を管理するための変数ｉＰｌａｙＴｈｒｅａｄに１を代入する。続くステップ４０２では、その変数ｉＰｌａｙＴｈｒｅａｄの値が１か否か判定する。その値が１でなかった場合、判定はＮＯとなり、ここで一連の処理を終了する。そうでない場合には、判定はＹＥＳとなってステップ４０３に移行する。特に詳細な説明は省略するが、変数ｉＰｌａｙＴｈｒｅａｄへの１以外の値の代入は、例えばクライアントからの再生の停止要求によってステップ１２５で行われる。
【００７３】
ステップ４０３では、変数ｉＰｌａｙＳｔａｒｔの値が１か否か判定する。その値が１でなかった場合、判定はＮＯとなって上記ステップ４０２に戻る。そうでない場合には、判定はＹＥＳとなってステップ４０４に移行する。変数ｉＰｌａｙＳｔａｒｔへの１の代入は、例えばクライアントからの再生開始要求によってステップ１２５で行われる。ステップ４０２、４０３で形成される処理ループを繰り返し実行することにより、その再生開始要求が行われるのを待つ。
【００７４】
ステップ４０４では、再生の対象とするファイルをオープンする。続くステップ４０５では、送信対象とする演奏情報を管理するための変数ｉＣに０を代入し、変数ｉＦｉｒｓｔＤａｔａに１を代入する。その後は、ステップ４０６で変数ｌＴｉｍｅＯｆｆｓｅｔに現在時刻を示す値を代入してからステップ４０７に移行する。
【００７５】
録音によって得られたファイルは、例えば所定期間、保存するようにしている。そのため、再生の対象となるファイルが複数、存在している場合、その対象とするファイルを選択できるようになっている。ここでは、それらについての詳細な説明は省略する。
【００７６】
ステップ４０７では、変数ｉＰｌａｙＳｔａｒｔの値が１か否か判定する。その値が１であった場合、変数ｉＣの値で指定される演奏情報をステップ４０８でファイルから読み込んだ後、ステップ４０９に移行する。そうでない場合には、判定はＮＯとなって上記ステップ４０２に戻る。
【００７７】
ステップ４０９では、変数ｉＣの値で指定される演奏情報がないか否か判定する。演奏情報の再生（送信）が終了した場合、変数ｉＣの値で指定される演奏情報は存在しなくなることから、判定はＹＥＳとなって上記ステップ４０２に戻る。それにより、演奏情報の再生を先頭から再度、開始させる。一方、そうでない場合には、判定はＮＯとなってステップ４１０に移行する。
【００７８】
ステップ４１０では、ステップ４０８で読み込んだ演奏情報中の時間データを変数ｌＭｉｄｉＴｉｍｅに代入する。続くステップ４１１では、変数ｌＴｉｍｅに、現在時刻を示す値を代入する。その次に移行するステップ４１２では、変数ｉＦｉｒｓｔＤａｔａの値が１か否か判定する。その値が１であった場合、判定はＹＥＳとなり、変数ｌＴｉｍｅＯｆｆｓｅｔの値から変数ｌＭｉｄｉＴｉｍｅの値を減算し、その減算結果に定数ＣＯＮＳＴＡを加算した値（＝ｌＴｉｍｅＯｆｆｓｅｔ−ｌＮｉｄｉＴｉｍｅ＋ＣＯＮＳＴＡ）をステップ４１３で変数ｌＤｉｖに代入し、更にステップ４１４で変数ｉＦｉｒｓｔＤａｔａに０を代入した後、ステップ４１５に移行する。そうでない場合には、判定はＮＯとなり、次にそのステップ４１５に移行する。
【００７９】
ＭＩＤＩデータには発生時刻を示す時間データが付加されている。このため、変数ｌＴｉｍｅＯｆｆｓｅｔの値から変数ｌＭｉｄｉＴｉｍｅの値を減算して得られる値は、サーバー２上の現在時刻と最初のＭＩＤＩデータの発生時刻の時間差を示している。その値に加算する定数ＣＯＮＳＴＡは、ネットワーク１を介した通信に要する時間の変動を吸収するためのものである。
【００８０】
ステップ４１５では、変数ｌＴｉｍｅの値から変数ｌＤｉｖの値を引いた値が、変数ｌＭｉｄｉＴｉｍｅの値より大きいか否か判定する。その大小関係が成立している場合、判定はＹＥＳとなり、ステップ４１７で変数ｊに０を代入した後、ステップ４１８に移行する。そうでない場合には、判定はＮＯとなって上記ステップ４０７に戻る。
【００８１】
変数ｌＤｉｖには上述したような値が代入されている。このため、上記大小関係は、ステップ４０８で読み込んだ演奏情報のＭｉｄｉデータを処理すべきタイミングとなる前に成立することになる。それにより、本実施の形態では、通信に要する時間が変動しても、クライアントに送信したＭＩＤＩデータの処理が遅れるのを確実に回避できるように送信している。
【００８２】
ステップ４１８では、変数ｊの値が上記ユーザー数ＭＡＸ＿ＵＳＥＲ未満か否か判定する。その値がユーザー数ＭＡＸ＿ＵＳＥＲ未満であった場合、判定はＮＯとなってステップ４１９に移行する。そうでない場合には、判定はＹＥＳとなり、ステップ４１６で変数ｉＣの値をインクリメントした後、上記ステップ４０７に戻る。
【００８３】
ステップ４１９では、ユーザーＤＢの変数ｊの値をインデクス値とするレコードのデータｃＳｔａｔの値が１、つまりそのレコードにデータが格納されたユーザーがログオン中か否か判定する。そのユーザーがログオン中であった場合、判定はＹＥＳとなり、ステップ４０８で読み込んだ演奏情報をそのユーザーにステップ４２０で送信し、更にステップ４２１で変数ｊの値をインクリメントした後、上記ステップ４１８に戻る。そうでない場合には、判定はＮＯとなり、次にステップ４２１に移行する。
【００８４】
次にＰＣ４の動作について詳細に説明する。
サーバー２は、ユーザーがログオンしたクライアントにユーザーＤＢ（図５）を送信する。また、図６に示すように、サーバー２が随時、送信するデータは、ヘッダー、及びそれが付加されたデータ本体に分けて、ＲＡＭ４２、或いは補助記憶装置４８に確保した領域であるバッファに格納している。ヘッダーには、データサイズ、データ本体の内容、データ本体の送信者情報、などが格納されている。
【００８５】
上述したように本実施の形態では、サーバー２によるサービスを利用するには専用のアプリケーションをクライアントに実行させるようにしている。以降は、そのアプリケーションを実行することで実現されるＰＣ４の動作について、図１１〜図１６のフローチャートを参照して詳細に説明する。そのアプリケーションは、入力装置４５を構成する媒体駆動装置にそれが格納された記録媒体をセットしてインストールを指示することで補助記憶装置４８に格納される。
【００８６】
図１１は、ＰＣ４が実行する全体処理のフローチャートである。その全体処理は、上記アプリケーションを実行することで実現される。始めに図１１を参照して、その全体処理について詳細に説明する。そのアプリケーションは、例えば補助記憶装置４８からＲＡＭ４２に読み出して実行される。
【００８７】
先ず、ステップ５０１では、各種変数の初期化や図６に示すバッファの確保といった初期化を行う。次のステップ５０２では、ユーザーが入力装置４５を操作して行う入力待ちを行う。その入力が行われることでステップ５０３に移行する。
【００８８】
ステップ５０３では、入力がサーバー２との接続要求のためのものか否か判定する。ユーザーが入力装置４５に対して接続要求のための操作を行った場合、判定はＹＥＳとなり、ステップ５０４でサーバー２との接続を行うための接続処理を実行した後、上記ステップ５０２に戻る。そうでない場合には、つまり再生指示、録音指示、或いはユーザーモード変更指示といった別の目的のための操作をユーザーが行った場合には、判定はＮＯとなり、ステップ５０３でその操作に対応するためのその他の処理を実行した後、そのステップ５０２に戻る。
【００８９】
図１２は、上記ステップ５０４として実行される接続処理のフローチャートである。次に図１２を参照して、その接続処理について詳細に説明する。
先ず、ステップ６０１では、各種変数等の初期化を行う。続くステップ６０２では、サーバー２に接続するための送準備を行う。その準備により、サーバー２との接続を行ううえでの通信条件が確定され、ネットワークインターフェース４４は確定された通信条件に応じて設定される。その準備後に移行するステップ６０３では、ネットワークインターフェース４４を用いて、サーバー２に対する接続要求を行う。この接続要求により、アプリケーションに割り当てられたデータｃＵｓｅｒＩＤが送信される。
【００９０】
ステップ６０３に続くステップ６０４では、サーバー２との接続が確立し、ログオンが承認されたか否か判定する。ログオンが承認された旨がサーバー２から通知された場合、判定はＹＥＳとなってステップ６０５に移行する。そうでない場合には、判定はＮＯとなり、ここで一連の処理を終了する。
【００９１】
ステップ６０５では、ログオンを承認したユーザーに対してサーバー２が送信するユーザーＤＢを受信するのを待って、それをＲＡＭ４２、或いは補助記憶装置４８に保存する。それ以降は、受信スレッド、送信スレッド、ＭＩＤＩアウトスレッドを順次、起動させ（ステップ６０６〜６０８）、変数ｉＯｎＣｏｎｎｅｃｔに１を代入する（ステップ６０９）。一連の処理はその代入を行った後に終了する。
【００９２】
上記変数ｉＯｎＣｏｎｎｅｃｔはサーバー２との接続状態を特定するためのものであり、それに代入した１はサーバー２と接続されていることを示す値である。以降は、接続処理で起動させる各種スレッドについて詳細に説明する。
【００９３】
図１３は、受信スレッドの実行によって実現される処理のフローチャートである。各種スレッドの説明では、始めに図１３を参照してその受信スレッドについて詳細に説明する。その受信スレッドは、サーバー２から受信するデータに対応するためのプログラムである。
【００９４】
先ず、ステップ７０１では、変数ｆｌａｇに１を代入する。その変数ｆｌａｇは、受信スレッドの終了を管理するための変数であり、それに代入した１は、受信スレッドは実行を継続すべき状況にあることを示す値である。それに１を代入した後は、ステップ７０２に移行して、その値が１か否か判定する。その値が１であった場合、判定はＹＥＳとなり、ステップ７０３でサーバー２からデータを受信するのを待つ。一方、そうでない場合には、判定はＮＯとなり、ここで一連の処理を終了する。変数ｆｌａｇへの１以外の値の代入は、例えばアプリケーションが実行を終了させる際に行われる。
【００９５】
サーバー２からデータを受信すると、ステップ７０３の判定がＹＥＳとなってステップ７０４に移行する。そのステップ７０４では、一時的なデータ保存用のバッファｒｅｃｖ＿ｂｕｆに受信データを保存する。次のステップ７０５では、変数ｊに０を代入する。その代入後に移行するステップ７０６では、ユーザーＤＢの変数ｊの値をインデクス値とするレコードのデータｉＦＤの値が、バッファｒｅｃｖ＿ｂｕｆに保存した受信データ中の送信者情報（ここではデータｉＦＤ）の値（図中「ｒｅｃｖ＿ｂｕｆ［ＳＥＮＤ＿ＵＳＥＲ＿ＩＤ］」と表記）と一致するか否か判定する。それらの値が一致する場合、判定はＹＥＳとなってステップ７０８に移行する。そうでない場合には、判定はＮＯとなり、次にステップ７０７で変数ｊの値をインクリメントした後、再度ステップ７０６の判定処理を実行する。
【００９６】
ステップ７０８では、変数ｉＵＤＢｉｄに変数ｊの値を代入する。続くステップ７０９では、受信データがＭＩＤＩデータ（演奏情報）か否か判定する。それがＭＩＤＩデータであった場合、判定はＹＥＳとなり、受信したＭＩＤＩデータに対応するためのＭＩＤＩ処理をステップ７１０で実行した後、上記ステップ７０２に戻る。そうでない場合には、判定はＮＯとなってステップ７１１に移行する。
【００９７】
ステップ７１１では、受信データがユーザーモードの変更要求のためのものか否か判定する。それがその変更要求のためのものであった場合、判定はＹＥＳとなり、その変更要求を送信させたユーザーの変更後のユーザーモードを表示部４６により通知するためのユーザーモード処理をステップ７１２で実行した後、上記ステップ７０２に戻る。そうでない場合には、判定はＮＯとなってステップ７１３に移行する。
【００９８】
ステップ７１３では、受信データがユーザーＤＢのレコードのデータか否か判定する。そのレコードのデータを受信した場合、判定はＹＥＳとなり、保存しているユーザーＤＢにそのレコードのデータを格納して更新するためのユーザーＤＢ処理を実行した後、上記ステップ７０２に戻る。そうでない場合には、判定はＮＯとなってステップ７１５に移行する。
【００９９】
上述したようにサーバー２は、ユーザーＤＢの更新を行うと、その更新によって内容が変化したレコードのデータを各クライアントに送信する。そのため、各クライアントは、サーバー２で行われたユーザーＤＢに対する更新に連動させる形で自身が管理するユーザーＤＢを更新し、サーバー２が更新後のユーザーＤＢを実現させる。そのようにして、サーバー２、クライアントに同じユーザーＤＢを共有化させることから、そのレコードに格納するデータの設定により、クライアント間で送受信すべきデータの送受信を自動的に行わせることができる。それにより、例えば或る演奏者による音色の変更、音響効果の付加／解除、或いは付加する音響効果の変更、等の設定変更に対し、他のユーザーが使用する各クライアントに自動的に対応させることができるようになる。その結果、各クライアントのユーザーは、演奏者のより実際の演奏に近い演奏を自動的に聴くことができるから、高い利便性が得られる。
【０１００】
上記設定変更は、再生する演奏情報に対して行うことができる。つまり、オリジナルの演奏の音色を変更させることや、種類、或いは内容がオリジナルとは異なる音響効果を付加させるといったことができる。そのような設定変更をクライアントのユーザーが行っても、各演奏者が演奏を行った際の設定内容を示すデータがユーザーＤＢに残っていれば、変更前の設定内容に自動的、或いはユーザーの指示により戻すことができる。
【０１０１】
ステップ７１５では、受信データが録音、或いは再生を指示するためのものか否か判定する。録音、或いは再生を指示するためのデータを受信した場合、判定はＹＥＳとなり、その指示内容を表示部４６により通知するための録音・再生処理をステップ７１６で実行した後、上記ステップ７０２に戻る。そうでない場合には、判定はＮＯとなって次にそのステップ７０２に移行する。
【０１０２】
図１４は、上記ステップ７１０として実行されるＭＩＤＩ処理のフローチャートである。次にそのＭＩＤＩ処理について、図１４に示すそのフローチャートを参照して詳細に説明する。
【０１０３】
先ず、ステップ８０１では、変数ｉＦｉｒｓｔＭｉｄｉの値が１か否か判定する。その値が１だった場合、判定はＹＥＳとなってステップ８０２に移行し、そうでない場合には、判定はＮＯとなってステップ８０６に移行する。その変数ｉＦｉｒｓｔＭｉｄｉへの１の代入は、図１２に示す接続処理内のステップ６０１で行われる。
【０１０４】
ステップ８０２では、変数ｉＦｉｒｓｔＭｉｄｉに０を代入する。続くステップ８０３では、変数ｌＳｔａｒｔＴｉｍｅに現在時刻を示す値を代入する。それに続くステップ８０４では、変数ｕｌＭに、受信データに付加された時間データを代入する。その代入後はステップ８０５に移行する。その時間データは、ＭＩＤＩデータの後に付加されて送信される。
【０１０５】
ステップ８０５では、変数ｌＴｉｍｅＯｆｆｓｅｔに、変数ｌＳｔａｒｔＴｉｍｅの値から変数ｕｌＭの値を減算した値（＝ｌＳｔａｒｔＴｉｍｅ−ｕｌＭ）を代入する。次のステップ８０６では、電子楽器５に出力すべきＭＩＤＩデータ用に確保したバッファ（ＭＩＤＩアウトバッファ）の変数ｗＰｔｒの値で指定される場所、及びその値をインクリメントした値で指定される場所（図中それらは「ｌＭｉｄｉＯｕｔＢｕｆ［ｗＰｔｒ，ｗＰｔｒ＋Ｐ１］」と表記）に、バッファｒｅｃｖ＿ｂｕｆに格納した受信データ中のＭＩＤＩデータ、時間データをそれぞれ格納する。その次のステップ８０７では、変数ｗＰｔｒの値を更新、ここではそれまでの値に２を加算した値への更新を行う。その後、一連の処理を終了する。
【０１０６】
その変数ｗＰｔｒは、図１２に示す接続処理内のステップ６０１で初期値（例えば０）が代入される変数である。変数ｌＴｉｍｅＯｆｆｓｅｔに代入する、変数ｌＳｔａｒｔＴｉｍｅの値から変数ｕｌＭの値を減算した値（＝ｌＳｔａｒｔＴｉｍｅ−ｕｌＭ）は、現在時刻を基準にした場合に、最初の受信したＭＩＤＩデータに付加されている時間データが示す発生時刻の考慮すべきシフト量（時間差）を表している。
【０１０７】
図１５は、図１２に示す接続処理内のステップ６０７で起動される送信スレッドの実行によって実現される処理のフローチャートである。次に図１５を参照して、その送信スレッドについて詳細に説明する。
【０１０８】
サーバー２に送信する対象とすべきＭＩＤＩデータは時間データと共にその送信用に確保したバッファ（送信バッファ）に格納するようにしている。図１５中に表記の「ｒＰｔｒＳ」は、そのバッファからデータを読み出す場所を管理するための変数であり、図１２に示す接続処理内のステップ６０１で初期値（例えば０）が代入される。また、表記の「ｉＭｉｄｉＳｅｎｄＴｈｒｅａｄＣｏｎｔ」は、送信スレッドの終了を管理するための変数である。
【０１０９】
先ず、ステップ９０１では、変数ｉＭｉｄｉＳｅｎｄＴｈｒｅａｄＣｏｎｔに１を代入する。続くステップ９０２では、変数ｉＭｉｄｉＳｅｎｄＴｈｒｅａｄＣｏｎｔの値が１か否か判定する。その値が１でなかった場合、判定はＮＯとなり、ここで一連の処理を終了する。そうでない場合には、判定はＹＥＳとなってステップ９０３に移行する。
【０１１０】
その変数ｉＭｉｄｉＳｅｎｄＴｈｒｅａｄＣｏｎｔへの１以外の値の代入は、例えばユーザーがユーザーモードとして視聴者Ｄへの変更を要求した場合に、図１１に示す全体処理内のステップ５０５で行われる。そのステップ５０５では、視聴者Ｄから演奏者Ａ〜Ｃへのユーザーモードの変更が要求された場合に、初期化を行い送信スレッドを起動させるようになっている。
【０１１１】
ステップ９０３では、送信バッファに送信すべきデータがないか否か判定する。送信すべきデータが存在していない場合、判定はＹＥＳとなって上記ステップ９０２に戻る。そうでない場合には、判定はＮＯとなってステップ９０４に移行する。
【０１１２】
ステップ９０４では、変数ｗＰａｒａｍに、送信バッファの変数ｒＰｔｒＳの値で指定される場所に格納されているデータ（図中「ｕｌＭｉｄｉＳｅｎｄＢｕｆ［ｗＰｔｒＳ］」と表記のＭＩＤＩデータ）を代入する。その次に移行するステップ９０５では、変数ｌＰａｒａｍに、送信バッファの変数ｒＰｔｒＳの値をインクリメントした値で指定される場所に格納されているデータ（図中「ｕｌＭｉｄｉＳｅｎｄＢｕｆ［ｗＰｔｒＳ＋１］」と表記の時間データ）を代入する。その後に実行するステップ９０６では、ＭＩＤＩデータ送信用のヘッダーを生成しバッファｓｅｎｄ＿ｂｕｆにセットする。以降は、変数ｗＰａｒａｍ、ｌＰａｒａｍｒにそれぞれ代入した値をバッファｓｅｎｄ＿ｂｕｆにセットし（ステップ９０７）、バッファｓｅｎｄ＿ｂｕｆにセットしたデータをサーバー２に送信させ（ステップ９０８）、変数ｒＰｔｒＳにそれまでの値に２を加算した値を新たに代入する（ステップ９０９）。ステップ９１０にはその代入後に移行する。
【０１１３】
ステップ９１０では、変数ｒＰｔｒＳの値が送信バッファにデータを格納可能な最大数ＳＩＺＥ以上か否か判定する。その値が最大数ＳＩＺＥ以上であった場合、判定はＹＥＳとなり、ステップ９１１で変数ｒＰｔｒＳに０を代入した後、上記ステップ９０３に戻る。そうでない場合には、判定はＮＯとなり、他のステップの処理を実行することなく、そのステップ９０３に戻る。
【０１１４】
図１６は、図１２に示す接続処理内のステップ６０８で起動されるＭＩＤＩアウトスレッドの実行によって実現される処理のフローチャートである。最後に図１６を参照して、そのアウトスレッドについて詳細に説明する。そのアウトスレッドは、ＭＩＤＩアウトバッファに格納されたＭＩＤＩデータの処理、処理したＭＩＤＩデータ、及び電子楽器５から入力したＭＩＤＩデータの送信バッファへの格納を実現させるためのものである。
【０１１５】
クライアント間で送受信すべき演奏情報の送受信はサーバー２の制御下で行われる。このことから、ＭＩＤＩアウトスレッドは、受信したＭＩＤＩデータ、及び電子楽器５から入力したＭＩＤＩデータを共にサーバー２に送信する対象としている。ＭＩＤＩデータに付加された時間データが示す発生時刻は、それを送信したＰＣ４での過去のものであるから、そのＭＩＤＩデータを処理した時刻に変更している。それにより、受信したＭＩＤＩデータ、及び電子楽器５から入力したＭＩＤＩデータの時間データはそれらを送信するＰＣ４を基準としたものとさせている。このため、送信したＭＩＤＩデータを受信するクライアントは、ＭＩＤＩデータを区別することなく、全てのＭＩＤＩデータを適切に処理することができる。
【０１１６】
図１６中に表記の「ｒＰｔｒ」は、送信バッファからデータを読み出す場所を管理するための変数であり、図１２に示す接続処理内のステップ６０１で初期値（例えば０）が代入される。また、表記の「ｉＭｉｄｉＯｕｔＴｈｒｅａｄＣｏｎｔ」は、ＭＩＤＩアウトスレッドの終了を管理するための変数である。
【０１１７】
先ず、ステップ１００１では、変数ｉＭｉｄｉＯｕｔＴｈｒｅａｄＣｏｎｔに１を代入する。続くステップ１００２では、変数ｉＭｉｄｉＯｕｔＴｈｒｅａｄＣｏｎｔの値が１か否か判定する。その値が１でなかった場合、判定はＮＯとなり、ここで一連の処理を終了する。そうでない場合には、判定はＹＥＳとなってステップ１００３に移行する。
【０１１８】
その変数ｉＭｉｄｉＯｕｔＴｈｒｅａｄＣｏｎｔへの１以外の値の代入は、例えばユーザーがユーザーモードとして視聴者Ｄへの変更を要求した場合に、図１１に示す全体処理内のステップ５０５で行われる。そのステップ５０５では、視聴者Ｄから演奏者Ａ〜Ｃへのユーザーモードの変更が要求された場合に、初期化を行いＭＩＤＩアウトスレッドを起動させるようになっている。
【０１１９】
ステップ１００３では、変数ｌＮｏｗＴｉｍｅに現在時刻を示す値を代入する。続くステップ１００４では、定数ｌＤｅｌａｙ、及びＭＩＤＩアウトバッファの変数ｒＰｔｒの値をインクリメントした値で指定される場所に格納された時間データ（図中「ｌＭｉｄｉＯｕｔＢｕｆ［ｒＰｔｒ＋１］」と表記）の値をそれぞれ変数ｌＴｉｍｅＯｆｆｓｅｔの値に加算し、その加算結果を変数ｌＮｏｗＴｉｍｅの値から減算した値（＝ｌＮｏｗＴｉｍｅ−（ｌＴｉｍｅＯｆｆｓｅｔ＋ｌＤｅｌａｙ＋ｌＭｉｄｉＯｕｔＢｕｆ［ｒＰｔｒ＋１］））を変数ａに代入する。その代入後はステップ１００５に移行する。
【０１２０】
上記定数ｌＤｅｌａｙは、ネットワーク１、及びサーバー２を介した送受信に係る通信時間の変動を吸収するために定めた定数である。変数ｌＴｉｍｅＯｆｆｓｅｔの値は上記時間データ（ｉＭｉｄｉＯｕｔＢｕｆ［ｒＰｔｒ＋１］）が示す発生時刻の考慮すべきシフト量（時間差）を表していることから、ステップ１００４で変数ａに代入する値は、その時間データが付加されたＭＩＤＩデータを処理すべきタイミングが到来することで０以上の値となる。その定数ｌＤｅｌａｙは各クライアントのユーザーが変更できるようにしても良い。
【０１２１】
ステップ１００５では、その変数ａの値が０以上か否か判定する。その値が０未満であった場合、判定はＮＯとなってステップ１０１２に移行する。そうでない場合には、判定はＹＥＳとなってステップ１００６に移行し、ＭＩＤＩアウトバッファの変数ｒＰｔｒの値で指定される場所に格納されたＭＩＤＩデータ（図中「ｌＭｉｄｉＯｕｔＢｕｆ［ｒＰｔｒ］」と表記）が楽音の発音に係わるものか否か判定する。そのＭＩＤＩデータが楽音の発音に係わるものでない場合、判定はＮＯとなってステップ１０１２に移行する。そうでない場合には、判定はＹＥＳとなってステップ１００７に移行する。
【０１２２】
ステップ１００７では、そのＭＩＤＩデータをＭＩＤＩ  Ｉ／Ｆ４７により電子楽器５に出力させる。次のステップ１００８では、ユーザーのユーザーモードを示す値を変数ｂに代入する。それに続くステップ１００９では、変数ｂの値とステップ１００７で処理したＭＩＤＩデータの送信者のユーザーモードを示す値（図中「ＵＳＥＲ＿ＭＯＤＥ＿ＰＬＡＹＥＲＭＡＸ」と表記。そのＭＩＤＩデータのヘッダーに格納されているデータｉＦＤを用いてユーザーＤＢを参照することにより特定される）の大小関係を比較して、その送信者がユーザーよりも上流で演奏する演奏者か否か判定する。その送信者がユーザーよりも上流で演奏する演奏者であった場合、判定はＹＥＳとなってステップ１０１０に移行する。そうでない場合には、判定はＮＯとなって上記ステップ１００４に戻る。
【０１２３】
ステップ１０１０では、変数ｂの値と視聴者Ｄのユーザーモードを示す値（図中「ＵＳＥＲ＿ＭＯＤＥ＿ＡＵＤＩＥＮＣＥ」と表記）の大小関係を比較して、ユーザーが視聴者Ｄでないか否か判定する。そのユーザーが視聴者Ｄでない場合、判定はＹＥＳとなり、ステップ１００７で処理したＭＩＤＩデータ、及び時間データとして変数ｌＮｏｗＴｉｍｅの値をステップ１０１１で送信バッファに格納した後、上記ステップ１００４に戻る。そうでない場合には、判定はＮＯとなり、他のステップの処理を実行することなく、そのステップ１００４に戻る。ＭＩＤＩデータに時間データとして変数ｌＮｏｗＴｉｍｅの値を付加することにより、そのＭＩＤＩデータの発生時刻はそのＭＩＤＩデータを送信するＰＣ４で処理した時刻に更新される。
【０１２４】
上記ステップ１００５、或いは１００６の判定がＮＯとなって移行するステップ１０１２では、電子楽器５からＭＩＤＩデータを入力したか否か判定する。そのＭＩＤＩデータを入力した場合、判定はＹＥＳとなってステップ１０１１に移行し、そのＭＩＤＩデータ、及び時間データとしての変数ｌＮｏｗＴｉｍｅの値を送信バッファに格納する。一方、そうでない場合には、判定はＮＯとなって上記ステップ１００２に戻る。
【０１２５】
なお、本実施の形態では、演奏操作の内容を示すデータとしてＭＩＤＩデータを採用しているが、別のデータ、例えば楽音の波高値を示す波形データ、或いはその符号化データを採用しても良い。時間データも同様に、発生時刻を示すものではなくとも良い。例えば直前に送信した演奏情報との間の処理タイミングの差を示すものであっても良い。ネットワーク２の送信に要する通信時間に生じる変動分が無視できるような場合には、時間データは付加しなくとも良い。
【０１２６】
また、合奏結果として録音する対象は、演奏者ＣをユーザーモードとするユーザーのＰＣ４から送信されるＭＩＤＩデータ（演奏情報）としているが、その対象を任意に選択できるようにしても良い。ＰＣ４の複数のユーザーがその選択をそれぞれ行えるようにしても良い。送信される演奏情報には送信者を示す情報が付加されていることから、複数のユーザーのそれぞれの要望に沿った録音を並行して行うことは容易である。
【０１２７】
上述したようなサーバー２（ネット合奏システム）を実現させるようなプログラム（アプリケーション）は、ＣＤ−ＲＯＭ、ＤＶＤ、或いは着脱自在なフラッシュメモリ等の記録媒体に記録させて配布しても良い。公衆網等のネットワークを介して、そのプログラムの一部、若しくは全部を配信するようにしても良い。そのようにした場合には、ユーザーはプログラムを取得してデータ処理装置にロードすることにより、その装置を用いて本発明を適用したネット合奏システムを構築することができる。このことから、記録媒体は、プログラムを配信する装置がアクセスできるものであっても良い。
【図面の簡単な説明】
【０１２８】
【図１】本実施の形態によるネット合奏システムを用いて構築されたネットワークシステムの構成を説明する図である。
【図２】本実施の形態によるネット合奏システムを搭載したサーバーの構成を説明する図である。
【図３】合奏を行う演奏者が使用するパーソナルコンピューター、及び電子楽器の構成を説明する図である。
【図４】仮想的な合奏の実現方法を説明する図である。
【図５】本実施の形態によるネット合奏システムを搭載したサーバーが合奏実現用に管理するデータを説明する図である。
【図６】パーソナルコンピューターによる受信したデータの保存方法を説明する図である。
【図７】本実施の形態によるネット合奏システムを搭載したサーバーが実行する全体処理のフローチャートである。
【図８】認証処理のフローチャートである。
【図９】図７に示す全体処理で起動される送信スレッドの実行によって実現される処理のフローチャートである。
【図１０】図７に示す全体処理で起動される再生スレッドの実行によって実現される処理のフローチャートである。
【図１１】合奏を行う演奏者のパーソナルコンピューターが実行する全体処理のフローチャートである。
【図１２】接続処理のフローチャートである。
【図１３】図１２に示す接続処理で起動される受信スレッドの実行によって実現される処理のフローチャートである。
【図１４】ＭＩＤＩ処理のフローチャートである。
【図１５】図１２に示す接続処理で起動される送信スレッドの実行によって実現される処理のフローチャートである。
【図１６】図１２に示す接続処理で起動されるＭＩＤＩアウトスレッドの実行によって実現される処理のフローチャートである。
【符号の説明】
【０１２９】
１    ネットワーク
２    サーバー
３、４    パーソナルコンピューター
５    電子楽器
２１、４１    ＣＰＵ
２２、４２    ＲＡＭ
２３、４３    ＲＯＭ
２４、４４    ネットワークインターフェース
２５、４５    入力装置
２７、４８    補助記憶装置
２８、４９    バス
４７、５１    ＭＩＤＩ  Ｉ／Ｆ
５２    キーボード
５３    音源・サウンドシステム
【図１】
2007041174.tif 000003
【図２】
2007041174.tif 000004
【図３】
2007041174.tif 000005
【図４】
2007041174.tif 000006
【図５】
2007041174.tif 000007
【図６】
2007041174.tif 000008
【図７】
2007041174.tif 000009
【図８】
2007041174.tif 000010
【図９】
2007041174.tif 000011
【図１０】
2007041174.tif 000012
【図１１】
2007041174.tif 000013
【図１２】
2007041174.tif 000014
【図１３】
2007041174.tif 000015
【図１４】
2007041174.tif 000016
【図１５】
2007041174.tif 000017
【図１６】
2007041174.tif 000018