通信装置及びコンピュータプログラム
【課題】 一対のデバイス間の通信負荷が大きくなるのを抑制する。
【解決手段】 多機能機は、第１期間では、最初に、「ｍ＝ａｕｄｉｏ」を含むＩＮＶＩＴＥコマンドを送信し、第２期間では、最初に、「ｍ＝ｖｉｄｅｏ」を含むＩＮＶＩＴＥコマンドを送信する。多機能機は、第１期間内の所定のタイミングで、最初に、「ｍ＝ｖｉｄｅｏ」を含むＩＮＶＩＴＥコマンドを送信する処理を試行する。その結果、通信セッションが確立されなかった場合（図６の上段）に、第１期間が継続し、通信セッションが確立された場合（図６の下段）に、第１期間から第２期間に移行する。
【解決手段】 多機能機は、第１期間では、最初に、「ｍ＝ａｕｄｉｏ」を含むＩＮＶＩＴＥコマンドを送信し、第２期間では、最初に、「ｍ＝ｖｉｄｅｏ」を含むＩＮＶＩＴＥコマンドを送信する。多機能機は、第１期間内の所定のタイミングで、最初に、「ｍ＝ｖｉｄｅｏ」を含むＩＮＶＩＴＥコマンドを送信する処理を試行する。その結果、通信セッションが確立されなかった場合（図６の上段）に、第１期間が継続し、通信セッションが確立された場合（図６の下段）に、第１期間から第２期間に移行する。
【発明の詳細な説明】
【技術分野】
【０００１】
本明細書は、通信対象の対象データを通信先デバイスと通信する通信装置を開示する。
【背景技術】
【０００２】
例えば、特許文献１には、以下の技術が開示されている。送信側装置は、自身が利用可能な全ての符号化方式（メディアタイプ）を受信側装置に送信する。受信側装置は、自身が利用可能な１個以上の符号化方式を送信側装置に送信する。送信側装置は、受信側装置から受信される１個以上の符号化方式の中から１個の符号化方式を選択する。送信側装置は、選択した１個の符号化方式を含むＩＮＶＩＴＥコマンドを受信側装置に送信する。その結果、受信側装置と送信側装置との間で通信セッションが確立される。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】国際公開２００３／０２１９１１号パンフレット
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ところで、送信側装置から受信側装置に送信される符号化方式の中に、受信側装置が利用不可能な符号化方式が含まれていると、受信側装置が利用可能な符号化方式を送信側装置に送信せずに、ＮＧコマンドを送信側装置に送信するタイプ（以下では「特定のタイプ」と呼ぶ）の受信側装置が存在する。
【０００５】
本明細書では、一対のデバイス間で適切に通信セッションを確立し得る技術を提供する。
【課題を解決するための手段】
【０００６】
本明細書は、通信装置を開示する。通信装置は、要求実行部と、対象データ通信部と、動作制御部と、を備える。要求実行部は、通信対象の対象データが通信先デバイスと通信されるべき際に、通信装置と通信先デバイスとの間で通信セッションを確立するために、第１種の要求処理と第２種の要求処理とを含む複数種類の要求処理のうちのいずれかを実行する。第１種の要求処理は、複数種類の情報のうちの第１種の情報を含む第１種の通信要求を、複数種類の情報のうちの第２種の情報を含む第２種の通信要求よりも先に通信先デバイスに送信する処理と、第１種の通信要求を送信することによって通信セッションが確立されなかった場合に、第２種の通信要求を通信先デバイスに送信する処理と、を含む。第２種の要求処理は、第２種の通信要求を、第１種の通信要求よりも先に通信先デバイスに送信する処理と、第２種の通信要求を送信することによって通信セッションが確立されなかった場合に、第１種の通信要求を通信先デバイスに送信する処理と、を含む。対象データ通信部は、通信装置と通信先デバイスとの間で通信セッションが確立されている状態で、対象データを通信先デバイスと通信する。動作制御部は、要求実行部の動作を制御する。動作制御部は、（Ａ）第１期間では、対象データが通信先デバイスと通信されるべき毎に、要求実行部に第１種の要求処理を実行させ、（Ｂ）第１期間内の所定のタイミングで、要求実行部に第２種の要求処理を試行させ、（Ｃ）試行において、第２種の通信要求を送信することによって通信セッションが確立されなかった場合に、第１期間を継続し、（Ｄ）試行において、第２種の通信要求を送信することによって通信セッションが確立された場合に、第１期間から第２期間に移行させ、（Ｅ）第２期間では、対象データが通信先デバイスと通信されるべき毎に、要求実行部に第２種の要求処理を実行させる。
【０００７】
上記の構成によると、通信装置は、第１種の通信要求（第２種の通信要求）を送信することによって通信セッションが確立されなかった場合に、第２種の通信要求（第１種の通信要求）を通信先デバイスに送信する処理を実行することができる。そのため、例えば、通信先デバイスが上記の特定のタイプのデバイスであった場合であっても、適切にセッションが確立されるように、通信要求に含まれる情報を変えながら、通信要求の送信を繰り返すことができる。さらに、通信装置は、第１期間では、通常、第１種の通信要求を第２種の通信要求よりも先に送信する第１種の要求処理を実行し、第２期間では、通常、第２種の通信要求を第１種の通信要求よりも先に送信する第２種の要求処理を実行する。通信装置は、第１期間内の所定のタイミングで第２種の要求処理を試行する。当該試行において第２種の通信要求を送信することによって通信セッションが確立された場合に、第１期間から第２期間に移行させる。この結果、通信装置は、通常、通信セッションが確立される可能性が高い通信要求（第２種の通信要求）を先に送信することになる。従って、通信装置が、第２種の通信要求を送信した後に、第１種の通信要求を送信する可能性が低くなる。このために、通信装置と通信先デバイスとの間の通信負荷が大きくなるのを抑制し得る。
【０００８】
なお、上記の通信装置のための制御方法、コンピュータプログラム、及び、当該コンピュータプログラムを格納するコンピュータ読取可能記録媒体も、新規で有用である。さらに、上記の通信装置と上記の通信先デバイスとを備えるシステムも、新規で有用である。
【図面の簡単な説明】
【０００９】
【図１】通信システムの構成を示す。
【図２】起動処理のフローチャートを示す。
【図３】メイン処理のフローチャートを示す。
【図４】優先順序に従った通信処理のフローチャートを示す。
【図５】デフォルト通信処理のフローチャートを示す。
【図６】第１実施例の多機能機の処理のタイムチャートの一例を示す。
【図７】第２実施例の多機能機の処理のタイムチャートの一例を示す。
【発明を実施するための形態】
【００１０】
（第１実施例）
（システムの構成）
図１に示すように、通信システム２は、ＬＡＮ４と、インターネット６と、多機能機１０、９０と、ＤＨＣＰ（Dynamic Host Configuration Protocol）サーバ６０と、ＳＩＰ（Session Initiation Protocol）サーバ７０と、を備える。多機能機１０とＤＨＣＰサーバ６０とは、ＬＡＮ４に接続されている。多機能機１０とＤＨＣＰサーバ６０とは、ＬＡＮ４を介して相互に通信可能である。ＳＩＰサーバ７０と多機能機９０とは、インターネット６に接続されている。多機能機１０と多機能機９０とＳＩＰサーバ７０とは、インターネット６を介して相互に通信可能である。
【００１１】
（多機能機１０の構成）
多機能機１０は、ＩＰ音声電話機能、ＩＰＴＶ電話機能、ＳＭＳ（ショートメッセージサービス）機能等を含む多機能を実行可能である。ＩＰ音声電話機能は、ＳＩＰＵＲＩ（SIP Uniform Resource Identifier）を用いて、音声データを通信するための機能である。なお、ＩＰ音声電話機能では、映像データは通信されない。ＩＰＴＶ電話機能は、ＳＩＰＵＲＩを用いて、音声データ及び映像データを通信するための機能である。ＳＭＳ機能は、ＳＩＰＵＲＩを用いて、メッセージを通信するための機能である。
【００１２】
多機能機１０は、表示部１２と、操作部１４と、ネットワークインターフェイス１６と、通話デバイス１８と、撮像部１９と、制御部２０と、を備える。各部１２〜２０は、バス線２２に接続されている。なお、多機能機９０も、上記の多機能機１０と同様の構成を備える。
【００１３】
表示部１２は、様々な情報を表示するためのディスプレイである。操作部１４は、複数のキーによって構成されている。ユーザは、操作部１４を操作することによって、様々な指示を多機能機１０に入力することができる。ネットワークインターフェイス１６は、ＬＡＮ４と接続されている。通話デバイス１８は、スピーカ及びマイク（図示省略）を備える。ユーザは、通話デバイス１８のスピーカ及びマイクを用いて、音声通話を行うことができる。撮像部１９は、ＣＣＤ等の撮像素子を備え、撮影対象物を撮影することによって、映像データを生成する。
【００１４】
制御部２０は、ＣＰＵ３０とメモリ３２とを備える。メモリ３２は、プログラム３４、enterprise-numberリスト３６、アドレス帳３８、及び、優先順序テーブル４０を格納する。ＣＰＵ３０は、メモリ３２に格納されているプログラム３４に従って様々な処理を実行する。ＣＰＵ３０が当該プログラム３４に従って処理を実行することによって、各部５０〜５６の機能が実現される。
【００１５】
（enterprise-numberリスト３６）
enterprise-numberリスト３６は、多機能機１０のＳＩＰ通信を実現するための複数のプロバイダを識別する複数のenterprise-numberを含む。enterprise-numberリスト３６は、多機能機１０の出荷段階において、メモリ３２内に予め格納されている。多機能機１０のベンダは、ＩＰＴＶ電話機能を実現不可能であるが、ＩＰ音声電話機能を実現可能であるＳＩＰサーバを提供している各プロバイダを調査して、当該各プロバイダのenterprise-numberをenterprise-numberリスト３６に登録する。このようなＳＩＰサーバは、将来的に、ＩＰＴＶ電話機能が実現可能な仕様に変更される可能性がある。即ち、enterprise-numberリスト３６には、現時点ではＩＰＴＶ電話機能を実現不可能な仕様であるが、将来的にＩＰＴＶ電話機能を実現可能な仕様に変更され得るプロバイダが登録される。
【００１６】
（アドレス帳３８）
アドレス帳３８は、ユーザによって入力されたＳＩＰＵＲＩ、メールアドレス、電話番号等を含む。
【００１７】
（優先順序テーブル４０）
優先順序テーブル４０は、ＳＩＰＵＲＩと、各メディアタイプの優先順序と、変更フラグと、指定日時と、が関連付けられたテーブルである。各メディアタイプの優先順序は、「ａｕｄｉｏ」、「ｖｉｄｅｏ」、及び、「ａｐｐｌｉｃａｔｉｏｎ」の３種類のメディアタイプの優先順序を示す。なお、「ａｕｄｉｏ」はＩＰ音声電話機能に対応し、「ｖｉｄｅｏ」はＩＰＴＶ電話機能に対応し、「ａｐｐｌｉｃａｔｉｏｎ」は音声データ、映像データ、メッセージデータ（ＳＭＳ）を同時に通信する機能に対応する。後で詳しく説明するが、多機能機１０は、ＳＩＰＵＲＩによって特定される通信先デバイスと通信が実行されるべき際に、当該ＳＩＰＵＲＩに関連付けられている優先順序に従って、メディアタイプを利用する。変更フラグは、優先順序が変更済みか否かを示すフラグである。本実施例では、「０」が未変更を示し、「１」が変更済みを示す。指定日時は、優先順序を一時的に変更するか否かの基準となる日時である。なお、優先順序テーブル４０内の各情報は、後述の図３のＳ３６の処理で優先順序テーブル４０に書き込まれる。
【００１８】
（ＳＩＰサーバ７０の構成）
ＳＩＰサーバ７０は、複数のデバイス（例えば多機能機１０、９０）のそれぞれについて、当該デバイスのＩＰアドレスと、当該デバイスのＳＩＰＵＲＩと、を対応付けて記憶している。ＳＩＰサーバ７０は、一対のデバイスの間で通信セッションを確立するために、一方のデバイスから送信されるコマンドを、他方のデバイスに転送する。
【００１９】
（ＤＨＣＰサーバ６０の構成）
ＤＨＣＰサーバ６０は、ＬＡＮ４に接続されている各デバイス（多機能機１０等）にＩＰアドレスを割り当てる。また、ＤＨＣＰサーバ７０は、ＤＨＣＰ情報を記憶している。ＤＨＣＰ情報は、後で説明するｏｐｔｉｏｎ１２０（ＳＩＰサーバ７０のＩＰアドレス）、及び、ｏｐｔｉｏｎ１２５（プロバイダを示すプロバイダ情報）を含む。
【００２０】
（ユーザの事前準備）
多機能機１０が実行する各処理について説明する前に、多機能機１０のユーザが行うべき事前準備について説明する。まず、ユーザは、いずれかのプロバイダと契約することによって、多機能機１０がＳＩＰ通信を実行可能な状態を構築する。以下では、ユーザによって契約されたプロバイダのことを「契約プロバイダ」と呼ぶ。契約プロバイダは、多機能機１０にＳＩＰＵＲＩを割り当てる。多機能機１０のＳＩＰＵＲＩは、契約プロバイダによって提供されるＳＩＰサーバ（例えばＳＩＰサーバ７０）に登録される。これにより、多機能機１０は、当該ＳＩＰサーバを介して、他のデバイスとの間で通信セッションを確立することができる。
【００２１】
さらに、ユーザは、契約プロバイダを示すenterprise-numberと、契約プロバイダによって提供されるＳＩＰサーバのＩＰアドレスと、をＤＨＣＰサーバ６０に登録する。この登録作業は、例えば、ＬＡＮ４に接続されている図示省略のＰＣによって実行される。なお、以下では、契約プロバイダによって提供されるＳＩＰサーバが、ＳＩＰサーバ７０である場合を例として、説明を続ける。
【００２２】
（多機能機１０が実行する処理）
続いて、図２〜図５を参照して、多機能機１０の制御部２０が実行する各処理について説明する。
【００２３】
（起動処理）
図２の起動処理は、多機能機１０が特定の状態であるか否かを判断する処理である。上記の特定の状態は、多機能機１０が、enterprise-numberリスト３６に登録されているいずれかのプロバイダによって提供されるＳＩＰサーバを介して、他のデバイスとの間の通信セッションを確立可能な状態である。換言すると、上記の特定の状態は、多機能機１０のユーザが、enterprise-numberリスト３６に登録されているいずれかのプロバイダと契約している状態である。
【００２４】
多機能機１０の電源がＯＮにされると、Ｓ２において、判断部５６（図１参照）は、ＬＡＮ４に接続されているＤＨＣＰサーバ６０を探索するための探索コマンドをブロードキャストする。ＬＡＮ４に接続されているＤＨＣＰサーバ６０は、探索コマンドを受信すると、自身のＩＰアドレスを含む応答パケットを多機能機１０に送信する。判断部５６は、探索コマンドをブロードキャストすると、Ｓ４において、ＬＡＮ４に接続されるＤＨＣＰサーバ６０が発見されたか否かを判断する。判断部５６は、探索コマンドをブロードキャストしてから所定の時間内に応答パケットを受信した場合に、Ｓ４でＹＥＳと判断する。Ｓ４でＹＥＳの場合、Ｓ６に進む。一方、Ｓ４でＮＯの場合、Ｓ２０に進む。
【００２５】
Ｓ６では、判断部５６は、ｏｐｔｉｏｎ１２０及びｏｐｔｉｏｎ１２５を含むＤＨＣＰ情報の送信を要求する要求コマンドを、ＤＨＣＰサーバ６０に送信する。ＤＨＣＰサーバ６０は、要求コマンドを受信すると、ＤＨＣＰ情報を多機能機１０に送信する。なお、ｏｐｔｉｏｎ１２０は、契約プロバイダによって提供されるＳＩＰサーバ７０のＩＰアドレスを含み、ｏｐｔｉｏｎ１２５は、上記の契約プロバイダを示すプロバイダ情報を含む。ｏｐｔｉｏｎ１２５に含まれるプロバイダ情報は、上記の契約プロバイダのenterprise-numberを含む。Ｓ８において、判断部５６は、ＤＨＣＰサーバ６０から送信されたＤＨＣＰ情報を受信する。
【００２６】
次いで、Ｓ１０において、判断部５６は、受信したＤＨＣＰ情報がｏｐｔｉｏｎ１２０を含むか否かを判断する。例えば、ＳＩＰサーバ７０のＩＰアドレスが、ユーザによってＤＨＣＰサーバ６０に予め登録されている場合には、ＤＨＣＰ情報は、ＳＩＰサーバ７０のＩＰアドレスを示すｏｐｔｉｏｎ１２０を含む。この場合、Ｓ１０でＹＥＳと判断される。一方において、例えば、ＳＩＰサーバ７０のＩＰアドレスが、ユーザによってＤＨＣＰサーバ６０に登録されていない場合（例えばユーザがプロバイダと契約していない場合）には、ＤＨＣＰ情報は、ｏｐｔｉｏｎ１２０を含まない。この場合、Ｓ１０でＮＯと判断される。
【００２７】
ＤＨＣＰ情報がｏｐｔｉｏｎ１２０を含む場合（即ちＳ１０でＹＥＳの場合）、Ｓ１２において、判断部５６は、ＤＨＣＰ情報がｏｐｔｉｏｎ１２５を含むか否かを判断する。例えば、契約プロバイダのenterprise-numberが、ＤＨＣＰサーバ６０に予め登録されている場合には、ＤＨＣＰ情報は、契約プロバイダのenterprise-numberを示すｏｐｔｉｏｎ１２５を含む。この場合、Ｓ１２でＹＥＳと判断される。一方において、例えば、契約プロバイダのenterprise-numberが、ＤＨＣＰサーバ６０に登録されていない場合（例えばユーザがプロバイダと契約していない場合）には、ＤＨＣＰ情報は、ｏｐｔｉｏｎ１２５を含まない。この場合、Ｓ１２でＮＯと判断される。
【００２８】
ＤＨＣＰ情報がｏｐｔｉｏｎ１２５を含む場合（即ちＳ１２でＹＥＳの場合）、Ｓ１４において、判断部５６は、ｏｐｔｉｏｎ１２５に含まれるenterprise-numberが、enterprise-numberリスト３６（図１参照）に含まれるのか否かを判断する。Ｓ１４でＹＥＳの場合、Ｓ１６において、判断部５６は、ｏｐｔｉｏｎ１２０が示す値を、ＳＩＰサーバ７０のＩＰアドレスとして、メモリ３２に記憶させる。次いで、Ｓ１８において、判断部５６は、多機能機１０が上記の特定の状態であることを示す判断結果情報をメモリ３２に記憶させる。Ｓ１８を終えると、起動処理が終了する。
【００２９】
なお、上記のＳ４、Ｓ１０、Ｓ１２、Ｓ１４のいずれかにおいてＮＯと判断される場合、Ｓ２０において、判断部５６は、多機能機１０が上記の特定の状態でないことを示す判断結果情報をメモリ３２に記憶させる。Ｓ２０を終えると、起動処理が終了する。
【００３０】
（メイン処理）
続いて、多機能機１０が多機能機９０と通信する場合を例として、図３のメイン処理の内容を説明する。
【００３１】
この処理が行われるためには、前提条件として、メモリ３２内に、ＳＩＰサーバ７０のＩＰアドレスが記憶されていることが必要である。上記の起動処理で、多機能機１０が上記の特定の状態であると判断された場合（図２のＳ１４でＹＥＳの場合）には、ＳＩＰサーバ７０のＩＰアドレスがメモリ３２に記憶されている（図２のＳ１６）。しかしながら、上記の起動処理で、多機能機１０が上記の特定の状態でないと判断された場合には、ＳＩＰサーバ７０のＩＰアドレスはメモリ３２に記憶されない。この場合、ユーザは、例えば、ＬＡＮ４に接続されている図示省略のＰＣを用いて、契約プロバイダのホームページにアクセスするなどすることによって、ＳＩＰサーバ７０のＩＰアドレスを知ることができる。そして、ユーザは、多機能機１０の操作部１４を操作して、ＳＩＰサーバ７０のＩＰアドレスをメモリ３２に記憶させることができる。
【００３２】
ユーザは、操作部１４を操作して、多機能機９０のＳＩＰＵＲＩを通信先として指定することができる。この指定操作は、アドレス帳３８から多機能機９０のＳＩＰＵＲＩを選択するための操作であってもよいし、多機能機９０のＳＩＰＵＲＩを構成する各文字を多機能機１０に入力するための操作であってもよい。上記の指定操作が実行されると、制御部２０は、図３のメイン処理を実行する。
【００３３】
Ｓ３０において、動作制御部５４（図１参照）は、多機能機１０が上記の特定の状態であるか否かを確認する。具体的には、動作制御部５４は、メモリ３２に記憶されている判断結果情報を読み出し、読み出された判断結果情報が、多機能機１０が上記の特定の状態であることを示す情報であるか否か判断する。判断結果情報が、多機能機１０が上記の特定の状態であることを示す情報である場合、動作制御部５４は、Ｓ３０でＹＥＳと判断する。
【００３４】
本実施例では、上記の起動処理（図２参照）において、判断部５６が既に多機能機１０が上記の特定の状態であるか否か判断している。そのため、ユーザによって上記の指定操作が行われる場合に、制御部２０は、上記の判断を再び実行する必要がなく（即ち図２のＳ２〜Ｓ１４の処理を実行する必要がなく）、判断結果を確認すれば済む（Ｓ３０）。メモリ３２に記憶されている判断結果情報を確認するための処理負荷よりも、上記の判断の処理負荷の方が高いために、多機能機１０の処理負荷が少なくて済む。
【００３５】
（多機能機１０が上記の特定の状態である場合）
多機能機１０が上記の特定の状態である場合（即ちＳ３０でＹＥＳの場合）、Ｓ３４において、動作制御部５４は、ユーザによって指定された多機能機９０のＳＩＰＵＲＩが、メモリ３２内の優先順序テーブル４０内に存在するか否かを判断する。ユーザによって指定された多機能機９０のＳＩＰＵＲＩが、優先順序テーブル４０内に存在する場合（即ちＳ３４でＹＥＳの場合）、Ｓ３８に進む。
【００３６】
一方、ユーザによって指定された多機能機９０のＳＩＰＵＲＩが、優先順序テーブル４０内に存在しない場合（即ちＳ３４でＮＯの場合）、Ｓ３６において、動作制御部５４は、多機能機９０のＳＩＰＵＲＩを、優先順序テーブル４０に書き込む。Ｓ３６では、さらに、動作制御部５４は、多機能機９０のＳＩＰＵＲＩに関連付けて、各メディアタイプの優先順序と、変更フラグと、指定日時と、を優先順序テーブル４０に書き込む。Ｓ３６で書き込まれる各メディアタイプの優先順序は、予め決められており、１位が「ａｕｄｉｏ」であり、２位が「ｖｉｄｅｏ」であり、３位が「ａｐｐｌｉｃａｔｉｏｎ」である。また、変更フラグとして「０」が書き込まれ、指定日時として現在日時の次の月の１日の０時０分が書き込まれる。例えば、現在日時が２０１０年９月１０日１５時０分であった場合、Ｓ３６では、動作制御部５４は、指定日時として「２０１０年１０月１日０時０分」を書き込む。Ｓ３６を終えると、Ｓ３８に進む。
【００３７】
Ｓ３８では、動作制御部５４は、多機能機９０のＳＩＰＵＲＩに関連付けられている変更フラグが「１」であるか否かを判断する。変更フラグが「１」である場合（即ちＳ３８でＹＥＳの場合）、Ｓ４６において、要求実行部５０（図１参照）は、通信処理を実行する。一方、変更フラグが「０」である場合（即ちＳ３８でＮＯの場合）、Ｓ４０において、動作制御部５４は、現在日時が、多機能機９０のＳＩＰＵＲＩに関連付けられている指定日時を経過しているか否かを判断する。現在日時が指定日時を経過していない場合（即ちＳ４０でＮＯの場合）、Ｓ４６において、要求実行部５０は、通信処理を実行する。
【００３８】
一方、現在日時が指定日時を経過している場合（即ちＳ４０でＹＥＳの場合）、Ｓ４２において、動作制御部５４は、多機能機９０のＳＩＰＵＲＩに関連付けられている優先順序を一時的に変更する。具体的には、Ｓ４２では、動作制御部５４は、１位のメディアタイプ（ａｕｄｉｏ）を最下位（３位）に繰り下げるとともに、２位のメディアタイプ（ｖｉｄｅｏ）、３位のメディアタイプ（ａｐｐｌｉｃａｔｉｏｎ）を、それぞれ、１位、２位に繰り上げる。Ｓ４２を終了すると、Ｓ４４において、要求実行部５０は、通信処理を実行する。
【００３９】
（優先順序に従った通信処理（図３のＳ４４及びＳ４６））
図４に示すように、Ｓ６０では、要求実行部５０は、多機能機９０のＳＩＰＵＲＩに関連付けられた優先順序を、優先順序テーブル４０から取得する。例えば、図３のＳ４２で優先順序が一時的に変更されていれば、Ｓ６０では、要求実行部５０は、変更後の優先順序を取得する。
【００４０】
次いで、Ｓ６２において、要求実行部５０は、Ｓ６０で取得された優先順序の１位のメディアタイプを含むＩＮＶＩＴＥコマンドを生成する。具体的には、Ｓ６２では、要求実行部５０は、１位のメディアタイプを表わす情報（例えば「ｖｉｄｅｏ」等）を、ＩＮＶＩＴＥコマンドのｍ行に書き込む。なお、以下では、ＩＮＶＩＴＥコマンドのｍ行にメディアタイプを表わす情報が書き込まれている状態のことを、「ｍ＝書き込まれたメディアタイプ（例えばｖｉｄｅｏ）」と表現する場合がある。Ｓ６２では、さらに、要求実行部５０は、多機能機９０のＳＩＰＵＲＩを送信先として、ＩＮＶＩＴＥコマンドをＳＩＰサーバ７０に送信する（Ｓ６２）。
【００４１】
ＳＩＰサーバ７０は、ＩＮＶＩＴＥコマンドに含まれるメディアタイプが、ＳＩＰサーバ７０自身が利用可能なメディアタイプである場合に、ＩＮＶＩＴＥコマンドを多機能機９０に転送する。一方、ＳＩＰサーバ７０は、ＩＮＶＩＴＥコマンドに含まれるメディアタイプが、ＳＩＰサーバ７０自身が利用不可能なメディアタイプである場合、ＩＮＶＩＴＥコマンドを多機能機９０に転送せずに、多機能機１０にＮＧコマンド（具体的には４８８ Ｎｏｔ Ａｃｃｅｐｔａｂｌｅ Ｈｅｒｅ）を送信する。例えば、ＳＩＰサーバ７０が、ＩＰ音声電話機能を実現可能であるが、ＩＰＴＶ電話機能を実現不可能である状態で、「ｍ＝ｖｉｄｅｏ」を含むＩＮＶＩＴＥコマンドを受信すると、多機能機１０にＮＧコマンドを送信する。
【００４２】
多機能機９０は、ＳＩＰサーバ７０から受信したＩＮＶＩＴＥコマンドに含まれるメディアタイプが、多機能機９０自身が利用可能なメディアタイプである場合、２００ＯＫコマンドをＳＩＰサーバ７０に送信する。この場合、ＳＩＰサーバ７０は、２００ＯＫコマンドを多機能機１０に転送する。一方、多機能機９０は、ＩＮＶＩＴＥコマンドに含まれるメディアタイプが、多機能機９０自身が利用不可能なメディアタイプである場合、ＮＧコマンドをＳＩＰサーバ７０に送信する。この場合、ＳＩＰサーバ７０は、ＮＧコマンドを多機能機１０に転送する。
【００４３】
Ｓ６４において、要求実行部５０は、２００ＯＫコマンドを受信することを監視する。要求実行部５０は、２００ＯＫコマンドを受信した場合（即ちＳ６４でＹＥＳの場合）に、多機能機９０のＳＩＰＵＲＩを送信先として、ＳＩＰサーバ７０にＡＣＫコマンドを送信する。ＳＩＰサーバ７０は、ＡＣＫコマンドを多機能機９０に転送する。これにより、多機能機１０と多機能機９０との間で、ＩＮＶＩＴＥコマンドに含まれるメディアタイプに対応する通信セッションが確立する。例えば、ＩＮＶＩＴＥコマンドが「ｍ＝ａｕｄｉｏ」である場合、メディアタイプ「ａｕｄｉｏ」に対応する通信セッション（ＩＰ音声電話機能のためのＲＴＰ（Real-time Transport Protocol）通信セッション）が確立する。この場合、当該通信セッションを用いて、音声データを通信可能である（映像データを通信不可能である）。また、例えば、ＩＮＶＩＴＥコマンドが「ｍ＝ｖｉｄｅｏ」である場合、メディアタイプ「ｖｉｄｅｏ」に対応する通信セッションが確立する。この場合、当該通信セッションを用いて、音声データ及び映像データを通信可能である。
【００４４】
次いで、Ｓ７０において、対象データ通信部５２（図１参照）は、Ｓ６４で確立された通信セッションを用いて、ＳＩＰサーバ７０を介さずに、通信対象の対象データを多機能機９０と通信する。即ち、多機能機１０と多機能機９０とは、ピアツーピアの通信を実行することによって、対象データの通信を実行する。なお、対象データは、確立済みの通信セッションに対応するメディアタイプに依存する。例えば、確立済みの通信セッションに対応するメディアタイプが「ａｕｄｉｏ」の場合、対象データは、多機能機１０のマイクに入力される音声データと、多機能機９０のマイクに入力される音声データと、を含む。例えば、確立済みの通信セッションに対応するメディアタイプが「ｖｉｄｅｏ」の場合、対象データは、各多機能機１０，９０のマイクに入力される音声データのみならず、多機能機１０の撮像部１９で生成される映像データと、多機能機９０の撮像部で生成される映像データと、を含む。また、例えば、確立済みの通信セッションのメディアタイプが「ａｐｐｌｉｃａｔｉｏｎ」の場合、対象データは、各多機能機１０，９０のマイクに入力される音声データと、多機能機１０の撮像部１９で生成される映像データと、多機能機１０、９０の操作部１２に入力されるメッセージデータである。Ｓ７０が終了すると、図４の通信処理が終了する。
【００４５】
上述したように、多機能機１０は、２００ＯＫコマンドを受信せずに、ＮＧコマンドをＳＩＰサーバ７０から受信することがある。この場合、要求実行部５０は、Ｓ６４でＮＯと判断し、次いで、Ｓ６６において、全てのメディアタイプの試行が終了したか否かを判断する。「ａｕｄｉｏ」、「ｖｉｄｅｏ」、及び、「ａｐｐｌｉｃａｔｉｏｎ」の３種類の全てについて、ＩＮＶＩＴＥコマンドの送信の試行が終了している場合に、要求実行部５０はＳ６６でＹＥＳと判断する。Ｓ６６でＹＥＳの場合、図４の通信処理が終了する。この場合、多機能機１０と多機能機９０との間で通信セッションが確立されず、対象データの通信が実行されない。
【００４６】
一方、全てのメディアタイプの試行が終了していない場合（即ちＳ６６でＮＯの場合）、Ｓ６８において、要求実行部５０は、次の順位のメディアタイプを含むＩＮＶＩＴＥコマンドを、多機能機９０のＳＩＰＵＲＩを送信先として送信する。次いで、要求実行部５０は、Ｓ６４に戻って、２００ＯＫコマンドを受信することを監視する。その後の各処理については、上述の通りである。
【００４７】
図３のＳ４６の通信処理が終了すると、メイン処理が終了する。一方、図３のＳ４４の通信処理が終了すると、Ｓ４８において、動作制御部５４は、１位のメディアタイプを含むＩＮＶＩＴＥコマンドを送信することによって、通信セッションが確立されたのか否かを判断する。ここでＹＥＳの場合、Ｓ５０において、動作制御部５４は、多機能機９０のＳＩＰＵＲＩに関連付けられている変更フラグを「０」から「１」に変更する。さらに、Ｓ５０では、動作制御部５４は、多機能機９０のＳＩＰＵＲＩに関連付けられている指定日時を消去する。Ｓ５０が終了すると、図３のメイン処理が終了する。
【００４８】
一方、１位のメディアタイプを含むＩＮＶＩＴＥコマンドを送信することによって、通信セッションが確立されなかった場合（即ちＳ４８でＮＯの場合）、Ｓ５２において、動作制御部５４は、Ｓ４２で一時的に変更した優先順序を元に戻す。次いで、Ｓ５４において、動作制御部５４は、多機能機９０のＳＩＰＵＲＩに関連付けられている指定日時を更新する。具体的に言うと、動作制御部５４は、新たな指定日時として、現在日時の次の月の１日の０時０分を書き込む。Ｓ５４を終えると、図３のメイン処理が終了する。
【００４９】
（多機能機１０が上記の特定の状態でない場合）
多機能機１０が上記の特定の状態でない場合（即ちＳ３０でＮＯの場合）、Ｓ３２に進む。Ｓ３２では、要求実行部５０は、デフォルト通信処理（図５参照）を実行する。
【００５０】
（デフォルト通信処理（図３のＳ３２））
図５に示すように、Ｓ８０では、要求実行部５０は、多機能機９０のＳＩＰＵＲＩを送信先として、「ｍ＝ｖｉｄｅｏ」を含むＩＮＶＩＴＥコマンドをＳＩＰサーバ７０に送信する。この場合のＳＩＰサーバ７０の動作は、上述の通りである。
【００５１】
Ｓ８２において、要求実行部５０は、２００ＯＫコマンドを受信することを監視する。要求実行部５０は、２００ＯＫコマンドを受信した場合（即ちＳ８２でＹＥＳの場合）に、多機能機９０のＳＩＰＵＲＩを送信先として、ＡＣＫコマンドをＳＩＰサーバ７０に送信する。ＳＩＰサーバ７０は、ＡＣＫコマンドを多機能機９０に転送する。これにより、多機能機１０と多機能機９０との間で、ＩＮＶＩＴＥコマンドに含まれるメディアタイプ「ｖｉｄｅｏ」に対応する通信セッションが確立する。
【００５２】
次いで、Ｓ８４において、対象データ通信部５２は、Ｓ８２で確立された通信セッションを用いて、ＳＩＰサーバ７０を介さずに、通信対象の対象データ（即ち音声データ及び映像データ）を多機能機９０と通信する。Ｓ８４が終了すると、図５のデフォルト通信処理が終了する。
【００５３】
一方、多機能機１０が、２００ＯＫコマンドを受信せずに、ＮＧコマンドを受信した場合（即ちＳ８２でＮＯの場合）、図５のデフォルト通信処理が終了する。この場合、多機能機１０と多機能機９０との間で通信セッションが確立されず、対象データの通信が実行されない。図５のデフォルト通信処理（図３のＳ３２）が終了すると、図３のメイン処理が終了する。
【００５４】
上述の通り、多機能機１０が上記の特定の状態である場合（Ｓ３０でＹＥＳの場合）には、多機能機１０のユーザが、enterprise-numberリスト３６に登録されているいずれかのプロバイダと契約している。従って、多機能機１０が上記の特定の状態である場合、ＳＩＰサーバ７０は、ＩＰＴＶ電話機能が実現可能な仕様に変更されない限り、ＩＰＴＶ電話機能を実現不可能であり、ＩＰ音声電話機能を実現可能である。このために、多機能機１０は、図３のＳ３６で、１位の順位として「ａｕｄｉｏ」を記憶して、通信セッションが確立される可能性が高い「ｍ＝ａｕｄｉｏ」のＩＮＶＩＴＥコマンドを優先的に送信する。一方、多機能機１０が上記の特定の状態でない場合（図３のＳ３２でＮＯの場合）には、ＳＩＰサーバ７０がＩＰＴＶ電話機能を実現可能である可能性が高い。従って、多機能機１０が上記の特定の状態でない場合、多機能機１０は、「ｍ＝ｖｉｄｅｏ」のＩＮＶＩＴＥコマンドを送信する（図５のＳ８０参照）。この構成によると、多機能機１０は、多機能機１０が上記の特定の状態であるのか否かに応じて、適切なＩＮＶＩＴＥコマンドを送信することができる。即ち、通信セッションが確立される可能性が低いＩＮＶＩＴＥコマンドが送信されることを抑制し得る。従って、多機能機１０と多機能機９０との間の通信負荷が大きくなるのを抑制し得る。
【００５５】
（具体例：図６のタイムチャート）
上記の図２〜図５のフローチャートに従って実現される多機能機１０の処理の具体例を説明する。図６の例では、多機能機１０は、上記の特定の状態である。そのため、ＳＩＰサーバ７０は、ＩＰＴＶ電話機能を実現可能な仕様に変更されない限り、ＩＰＴＶ電話機能を実現不可能であり、ＩＰ音声電話機能を実現可能である。従って、図３のＳ３６において、動作制御部５４は、優先順序テーブル４０に、各メディアタイプの優先順序として、１位「ａｕｄｉｏ」、２位「ｖｉｄｅｏ」、３位「ａｐｐｌｉｃａｔｉｏｎ」を記憶させる。以下では、この優先順序のことを「デフォルト優先順序」と呼ぶ。また、Ｓ３６では、動作制御部５４は、優先順序テーブル４０に変更フラグ「０」を記憶させる。この状態では、指定日時が経過する前に、通信指示Ｉ１（即ち多機能機９０のＳＩＰＵＲＩの指定操作）が入力されると、要求実行部５０は、デフォルト優先順序に従って、最初に、「ｍ＝ａｕｄｉｏ」を含むＩＮＶＩＴＥコマンドを送信する。これにより、多機能機１０と多機能機９０との間で通信セッションが適切に確立される。対象データ通信部５２は、メディアタイプ「ａｕｄｉｏ」に従って、対象データ（即ち音声データ）を多機能機９０と通信する。なお、以下では、多機能機９０のＳＩＰＵＲＩに関連付けてデフォルト優先順序が優先順序テーブル４０に継続的に記憶される期間のことを「第１期間」と呼ぶ。
【００５６】
上述の通り、ＳＩＰサーバ７０は、将来的に、ＩＰＴＶ電話機能を実現可能な仕様に変更される可能性がある。そのような仕様の変更の有無を確認するために、指定日時が経過した後に通信指示Ｉ２が入力されると、動作制御部５４は、優先順序テーブル４０内のデフォルト優先順序を他の優先順序に一時的に変更する（図３のＳ４２）。上記の他の優先順序は、１位「ｖｉｄｅｏ」、２位「ａｐｐｌｉｃａｔｉｏｎ」、３位「ａｕｄｉｏ」である。以下では、この優先順序のことを「変更後優先順序」と呼ぶ。この状態では、要求実行部５０は、最初に、「ｍ＝ｖｉｄｅｏ」を含むＩＮＶＩＴＥコマンドを送信することを試行する。なお、以下では、多機能機９０のＳＩＰＵＲＩに関連付けて変更後優先順序が優先順序テーブル４０に一時的に記憶される期間のことを「第３期間」と呼ぶ。なお、変更後優先順序は、ＳＩＰサーバ７０の仕様の変更の有無を確認するために一時的に利用される優先順序である。即ち、「ｍ＝ｖｉｄｅｏ」を含むＩＮＶＩＴＥコマンドによって通信セッションが確立されない場合には、変更後優先順序からデフォルト優先順序に再び変更される。従って、デフォルト優先順序が継続的に記憶される第１期間の中に、変更後優先順序が一時的に記憶される第３期間が含まれると考えることができる。
【００５７】
（ＳＩＰサーバ７０がＩＰＴＶ電話機能を実現可能な仕様に変更されない場合）
通信指示Ｉ２が入力される時点で、ＳＩＰサーバ７０が、ＩＰＴＶ電話機能を実現可能な仕様に変更されていない場合について説明する。この場合、図６の上段に示すように、上記の第３期間において、「ｍ＝ｖｉｄｅｏ」を含むＩＮＶＩＴＥコマンドが送信されても、通信セッションが確立されない（多機能機１０はＮＧコマンドを受信する）。従って、動作制御部５４は、変更後優先順序をデフォルト優先順序に戻す（図３のＳ５２）。また、動作制御部５４は、指定日時を更新する（図３のＳ５４）。この例では、第１期間が継続する。
【００５８】
第１期間が継続する場合には、更新済みの指定日時が経過する前に通信指示Ｉ３が入力されると、多機能機１０は、デフォルト優先順位に従って、上記の通信指示Ｉ１が入力された場合と同様の処理を実行する。また、更新済みの指定日時が経過した後に通信指示Ｉ４が入力されると、多機能機１０は、変更後優先順位に従って、上記の通信指示Ｉ２が入力された場合と同様の処理を実行する。
【００５９】
（ＳＩＰサーバ７０がＩＰＴＶ電話機能を実現可能な仕様に変更される場合）
上記の通信指示Ｉ２が入力される時点で、ＳＩＰサーバ７０が、ＩＰＴＶ電話機能を実現可能な仕様に変更されている場合について説明する。この場合、図６の下段に示すように、「ｍ＝ｖｉｄｅｏ」を含むＩＮＶＩＴＥコマンドによって通信セッションが確立される。この場合、対象データ通信部５２は、メディアタイプ「ｖｉｄｅｏ」に従って、対象データ（即ち音声データ及び映像データ）を多機能機９０と通信する。次いで、動作制御部５４は、多機能機９０のＳＩＰＵＲＩに関連付けられている変更フラグを「１」に変更する（図３のＳ４８でＹＥＳ、Ｓ５０）。この例では、デフォルト優先順位に戻ることなく、変更後優先順序が維持される。この場合、変更後優先順序から他の優先順序にさらに変更されることがなく、変更後優先順序が継続的に記憶される。即ち、多機能機９０のＳＩＰＵＲＩに関連付けて変更後優先順序が優先順序テーブル４０に継続的に記憶される期間に移行する。以下では、この期間のことを「第２期間」と呼ぶ。
【００６０】
第２期間に移行した後に通信指示Ｉ５が入力されると、要求実行部５０は、変更後優先順序に従って、最初に、「ｍ＝ｖｉｄｅｏ」を含むＩＮＶＩＴＥコマンドを送信する。これにより、多機能機１０と多機能機９０との間で通信セッションが適切に確立される。この場合、対象データ通信部５２は、メディアタイプ「ｖｉｄｅｏ」に従って、対象データ（音声データ及び映像データ）を多機能機９０との間で通信する。
【００６１】
（本実施例の効果）
本実施例の通信システム２について詳しく説明した。図６に示すように、第１期間では、「ｍ＝ａｕｄｉｏ」を含むＩＮＶＩＴＥコマンドによって通信セッションが確立されなかった場合に、「ｍ＝ｖｉｄｅｏ」を含むＩＮＶＩＴＥコマンドを送信する。そのため、多機能機９０が、受信したＩＮＶＩＴＥコマンドに含まれるメディアタイプが利用不可能なメディアタイプである場合にＮＧコマンドを送信する（上記の特定のタイプ）場合であっても、多機能機１０は、多機能機９０との間で適切にセッションが確立されるように、ＩＮＶＩＴＥに含まれる情報を変えながら、ＩＮＶＩＴＥの送信を繰り返すことができる。
【００６２】
また、本実施例では、図６に示すように、第１期間（例えば「第１動作モード」と言い換えてもよい）では、最初に、「ｍ＝ａｕｄｉｏ」を含むＩＮＶＩＴＥコマンドが送信され、第２期間（例えば「第２動作モード」と言い換えてもよい）では、最初に、「ｍ＝ｖｉｄｅｏ」を含むＩＮＶＩＴＥコマンドが送信される。指定日時が経過した後に、通信指示Ｉ２が入力されると、第１期間内の第３期間（例えば「第３動作モード」と言い換えてもよい）に移行する。ここで、「ｍ＝ｖｉｄｅｏ」を含むＩＮＶＩＴＥコマンドによって通信セッションが確立されなかった場合（図６の上段）には、第１期間が継続する。一方、「ｍ＝ｖｉｄｅｏ」を含むＩＮＶＩＴＥコマンドによって通信セッションが確立された場合（図６の下段）には、第１期間内の第３期間から第２期間に移行する。第２期間に移行した後に通信指示Ｉ５が入力されると、通信セッションが確立される可能性が高い「ｍ＝ｖｉｄｅｏ」を含むＩＮＶＩＴＥコマンドが最初に送信される。そのため、「ｍ＝ａｕｄｉｏ」を含むＩＮＶＩＴＥコマンドが送信される可能性が低くなる。本実施例によると、通信セッションが確立される可能性が低いＩＮＶＩＴＥコマンドが送信されることを抑制し得る。従って、多機能機１０と多機能機９０との間の通信負荷が大きくなるのを抑制し得る。
【００６３】
また、第１期間が継続する場合（図６の上段）には、指定日時が経過する前に通信指示Ｉ３が入力されると、通信セッションが確立される可能性が高い「ｍ＝ａｕｄｉｏ」を含むＩＮＶＩＴＥコマンドが最初に送信される。そのため、「ｍ＝ｖｉｄｅｏ」を含むＩＮＶＩＴＥコマンドが送信される可能性が低くなる。通信セッションが確立される可能性が低いＩＮＶＩＴＥコマンドが送信されることを抑制し得る。従って、多機能機１０と多機能機９０との間の通信負荷が大きくなるのを抑制し得る。
【００６４】
多機能機９０（通信相手となるデバイス）やＳＩＰサーバ７０は、ファームウェア更新や利用者による機器の買い替えなどにより、利用可能なメディアタイプが変更される可能性がある。メディアタイプが変更された場合に、その通知を受けなければ、送信側装置（多機能機１０）はその変更があったことを知ることができない。したがって、今まで利用不可能なメディアタイプが利用可能に変更されたり、今まで利用可能なメディアタイプが利用不可能に変更されたりした場合、多機能機１０では対応できない。本実施例の多機能機１０は、所定のタイミングで、優先順序を変更したＩＮＶＩＴＥコマンドを送信する。そのため、多機能機９０やＳＩＰサーバ７０が利用可能なメディアタイプが変更された場合であっても、多機能機１０と多機能機９０との間の通信負荷を抑制する順序でのＩＮＶＩＴＥコマンドの送信を行うことができる。
【００６５】
多機能機１０が特定の状態である場合において、所定のタイミングで「ｍ＝ｖｉｄｅｏ」を含むＩＮＶＩＴＥコマンドを送信して通信セッションが確立されなかった場合は、多機能機９０やＳＩＰサーバ７０で、ＩＰＴＶ電話機能（「ｍ＝ｖｉｄｅｏ」）を実現可能とするための仕様変更が行われていないことを意味する。その場合、本実施例の多機能機１０は、指定期間を更新する。従って、通信が実行される毎に、「ｍ＝ｖｉｄｅｏ」を含むＩＮＶＩＴＥコマンドの送信が試行される場合と比べて、多機能機１０と多機能機９０との間の通信負荷が大きくなることを抑制し得る。
【００６６】
また、本実施例では、通信先デバイス（ＳＩＰＵＲＩ）毎に、上記の各処理を行うため、通信先デバイス毎に、適切な優先順序でＩＮＶＩＴＥコマンドを送信することができる。
【００６７】
本実施例の各要素と本発明の各要素の対応関係を記載しておく。「ａｕｄｉｏ」、「ｖｉｄｅｏ」、及び、「ａｐｐｌｉｃａｔｉｏｎ」の３種類の情報が「複数種類の情報」の一例である。「ａｕｄｉｏ」、「ｖｉｄｅｏ」が、それぞれ、「第１種の情報」、「第２種の情報」の一例である。なお、「複数種類の情報」の語は、「異なるメディアタイプに対応する複数種類の情報」と言い換えてもよい。「ｍ＝ａｕｄｉｏ」を含むＩＮＶＩＴＥコマンド、「ｍ＝ｖｉｄｅｏ」を含むＩＮＶＩＴＥコマンドが、それぞれ、「第１種の通信要求」、「第２種の通信要求」の一例である。図５のＳ８０で送信される「ｍ＝ｖｉｄｅｏ」を含むＩＮＶＩＴＥコマンドが「第３種の通信要求」の一例である。デフォルト優先順序、変更後優先順序が、それぞれ、「第１種のデータ」、「第２種のデータ」の一例である。
【００６８】
（第２実施例）
図７のタイムチャートを用いて、第１実施例と異なる点を中心に説明する。第１期間において、指定日時が経過する前に、通信指示Ｉ１１が入力された場合の処理は、図６の例で通信指示Ｉ１が入力された場合の処理と同様である。ただし、第２実施例では、指定日時が経過した後に、通信指示Ｉ１２が入力された場合の処理が、図６の例で通信指示Ｉ２が入力された場合の処理と異なる。即ち、動作制御部５４は、優先順序テーブル４０内のデフォルト優先順序を変更後優先順序に一時的に変更しない。ただし、要求実行部５０は、変更後優先順序に従って、最初に、「ｍ＝ｖｉｄｅｏ」を含むＩＮＶＩＴＥコマンドを送信する。
【００６９】
（ＳＩＰサーバ７０がＩＰＴＶ電話機能を実現可能な仕様に変更されない場合）
図７の上段に示すように、「ｍ＝ｖｉｄｅｏ」を含むＩＮＶＩＴＥコマンドによって通信セッションが確立されない。この場合、動作制御部５４は、指定日時を更新する。第１期間が継続する。その後、更新済みの指定日時が経過する前に通信指示Ｉ１３が入力されると、多機能機１０は、上記の通信指示Ｉ１１が入力された場合と同様の処理を実行する。また、更新済みの指定日時が経過した後に通信指示Ｉ１４が入力されると、多機能機１０は、上記の通信指示Ｉ１２が入力された場合と同様の処理を実行する。
【００７０】
（ＳＩＰサーバ７０がＩＰＴＶ電話機能を実現可能な仕様に変更される場合）
図７の下段に示すように、「ｍ＝ｖｉｄｅｏ」を含むＩＮＶＩＴＥコマンドによって通信セッションが確立される。対象データ通信部５２は、メディアタイプ「ｖｉｄｅｏ」に従って、対象データ（即ち音声データ及び映像データ）を多機能機９０と通信する。次いで、動作制御部５４は、優先順序テーブル４０内のデフォルト優先順序を変更後優先順序に変更する。さらに、動作制御部５４は、変更フラグを「１」に変更する。この場合、変更後優先順序から他の優先順序にさらに変更されることがなく、変更後優先順序が継続的に記憶される。即ち、第１期間から第２期間に移行する。第２期間に移行した後に通信指示Ｉ１５が入力されると、要求実行部５０は、変更後優先順序に従って、最初に、「ｍ＝ｖｉｄｅｏ」を含むＩＮＶＩＴＥコマンドを送信する。これにより、多機能機１０と多機能機９０との間で通信セッションが適切に確立される。対象データ通信部５２は、メディアタイプ「ｖｉｄｅｏ」に従って、対象データ（即ち音声データ及び映像データ）を多機能機９０と通信する。
【００７１】
以上、本発明の具体例を詳細に説明したが、これらは例示にすぎず、特許請求の範囲を限定するものではない。特許請求の範囲に記載の技術には、以上に例示した具体例を様々に変形、変更したものが含まれる。例えば、以下の変形例を採用してもよい。
【００７２】
（変形例１）上記の各実施例では、多機能機１０は、インターネット６を介して、多機能機９０及びＳＩＰサーバ７０と通信可能である。これに代えて、多機能機１０は、ＮＧＮ（Next Generation Network：次世代ネットワーク）を介して、多機能機９０及びＳＩＰサーバ７０と通信可能であってもよい。
【００７３】
（変形例２）上記の各実施例では、優先順序テーブル４０内には、ＳＩＰＵＲＩに関連付けて、各メディアタイプの優先順序が記憶される。これに代えて、メモリ３２内には、ＳＩＰＵＲＩに関連付けて、順位フラグ（「１」又は「０」）が記憶されていてもよい。この場合、要求実行部５０は、ユーザによって指定された通信先のＳＩＰＵＲＩに関連付けられている順位フラグが「０」である場合には、第１種の要求処理を実行し、当該順位フラグが「１」である場合には、第２種の要求処理を実行してもよい。本変形例では、順位フラグ「０」、「１」が、それぞれ、「第１種のデータ」、「第２種のデータ」の一例である。
【００７４】
（変形例３）上記の各実施例では、各メディアタイプの優先順序を変更する際に、１位のメディアタイプを最下位（３位）に変更し、２位、３位のメディアタイプをそれぞれ１位、２位に変更する。これに代えて、１位のメディアタイプと２位のメディアタイプとを入れ替え、３位のメディアタイプの順位を維持してもよい。。
【００７５】
（変形例４）上記の各実施例では、動作制御部５４は、第２期間に移行した後に、変更後優先順序をさらに変更しない。即ち、一般的に言うと、動作制御部５４は、第２期間に移行した後に、要求実行部５０に第２種の要求処理のみを実行させる。これに代えて、動作制御部５４は、第２期間に移行した後に、所定のタイミングで第１種の要求処理を要求実行部５０に試行させてもよい。動作制御部５４は、当該試行において、第１種の通信要求によって通信セッションが確立されなかった場合に、第２期間を維持し、当該試行において、第１種の通信要求によって通信セッションが確立された場合に、第１期間に再び移行させてもよい。
【００７６】
（変形例５）上記の各実施例では、動作制御部５４は、対象データが通信されるべき際に、現在日時が指定日時を経過している場合（図３のＳ４０でＹＥＳの場合）に、各メディアタイプの優先順序を一時的に変更する（Ｓ４２）。即ち、一般的に言うと、所定のタイミングは、現在日時が所定日時を経過している状態で、対象データが通信先デバイスと通信されるべきタイミングである。これに代えて、所定のタイミングは、例えば、通信先デバイスの通信識別情報を送信先として通信要求が送信された回数が所定回数を超えた後に、対象データが通信先デバイスと通信されるべきタイミングであってもよい。また、所定のタイミングは、対象データが通信先デバイスと通信されるべきタイミングでなくてもよく、例えば、通信装置のベンダによって予め決められた日時（例えば毎月１日の０時０分）であってもよい。
【００７７】
（変形例６）上記の各実施例では、例えば、図６の上段の例に示されるように、指定日時が経過する毎に、デフォルト優先順序から変更後優先順序に一時的に変更される。即ち、一般的に言うと、第１期間内に所定のタイミングが２回以上設けられ得る。これに代えて、所定のタイミングが１回のみ設けられるようにしてもよい。即ち、第１期間内に第２種の要求処理が試行された後に、第２種の要求処理が再び試行されないようにしてもよい。
【００７８】
本明細書または図面に説明した技術要素は、単独であるいは各種の組合せによって技術的有用性を発揮するものであり、出願時請求項記載の組合せに限定されるものではない。また、本明細書または図面に例示した技術は複数目的を同時に達成するものであり、そのうちの一つの目的を達成すること自体で技術的有用性を持つものである。
【符号の説明】
【００７９】
２：通信システム、４：ＬＡＮ、６：インターネット、１０：多機能機、６０：ＤＨＣＰサーバ、７０：ＳＩＰサーバ、９０：多機能機
【技術分野】
【０００１】
本明細書は、通信対象の対象データを通信先デバイスと通信する通信装置を開示する。
【背景技術】
【０００２】
例えば、特許文献１には、以下の技術が開示されている。送信側装置は、自身が利用可能な全ての符号化方式（メディアタイプ）を受信側装置に送信する。受信側装置は、自身が利用可能な１個以上の符号化方式を送信側装置に送信する。送信側装置は、受信側装置から受信される１個以上の符号化方式の中から１個の符号化方式を選択する。送信側装置は、選択した１個の符号化方式を含むＩＮＶＩＴＥコマンドを受信側装置に送信する。その結果、受信側装置と送信側装置との間で通信セッションが確立される。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】国際公開２００３／０２１９１１号パンフレット
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ところで、送信側装置から受信側装置に送信される符号化方式の中に、受信側装置が利用不可能な符号化方式が含まれていると、受信側装置が利用可能な符号化方式を送信側装置に送信せずに、ＮＧコマンドを送信側装置に送信するタイプ（以下では「特定のタイプ」と呼ぶ）の受信側装置が存在する。
【０００５】
本明細書では、一対のデバイス間で適切に通信セッションを確立し得る技術を提供する。
【課題を解決するための手段】
【０００６】
本明細書は、通信装置を開示する。通信装置は、要求実行部と、対象データ通信部と、動作制御部と、を備える。要求実行部は、通信対象の対象データが通信先デバイスと通信されるべき際に、通信装置と通信先デバイスとの間で通信セッションを確立するために、第１種の要求処理と第２種の要求処理とを含む複数種類の要求処理のうちのいずれかを実行する。第１種の要求処理は、複数種類の情報のうちの第１種の情報を含む第１種の通信要求を、複数種類の情報のうちの第２種の情報を含む第２種の通信要求よりも先に通信先デバイスに送信する処理と、第１種の通信要求を送信することによって通信セッションが確立されなかった場合に、第２種の通信要求を通信先デバイスに送信する処理と、を含む。第２種の要求処理は、第２種の通信要求を、第１種の通信要求よりも先に通信先デバイスに送信する処理と、第２種の通信要求を送信することによって通信セッションが確立されなかった場合に、第１種の通信要求を通信先デバイスに送信する処理と、を含む。対象データ通信部は、通信装置と通信先デバイスとの間で通信セッションが確立されている状態で、対象データを通信先デバイスと通信する。動作制御部は、要求実行部の動作を制御する。動作制御部は、（Ａ）第１期間では、対象データが通信先デバイスと通信されるべき毎に、要求実行部に第１種の要求処理を実行させ、（Ｂ）第１期間内の所定のタイミングで、要求実行部に第２種の要求処理を試行させ、（Ｃ）試行において、第２種の通信要求を送信することによって通信セッションが確立されなかった場合に、第１期間を継続し、（Ｄ）試行において、第２種の通信要求を送信することによって通信セッションが確立された場合に、第１期間から第２期間に移行させ、（Ｅ）第２期間では、対象データが通信先デバイスと通信されるべき毎に、要求実行部に第２種の要求処理を実行させる。
【０００７】
上記の構成によると、通信装置は、第１種の通信要求（第２種の通信要求）を送信することによって通信セッションが確立されなかった場合に、第２種の通信要求（第１種の通信要求）を通信先デバイスに送信する処理を実行することができる。そのため、例えば、通信先デバイスが上記の特定のタイプのデバイスであった場合であっても、適切にセッションが確立されるように、通信要求に含まれる情報を変えながら、通信要求の送信を繰り返すことができる。さらに、通信装置は、第１期間では、通常、第１種の通信要求を第２種の通信要求よりも先に送信する第１種の要求処理を実行し、第２期間では、通常、第２種の通信要求を第１種の通信要求よりも先に送信する第２種の要求処理を実行する。通信装置は、第１期間内の所定のタイミングで第２種の要求処理を試行する。当該試行において第２種の通信要求を送信することによって通信セッションが確立された場合に、第１期間から第２期間に移行させる。この結果、通信装置は、通常、通信セッションが確立される可能性が高い通信要求（第２種の通信要求）を先に送信することになる。従って、通信装置が、第２種の通信要求を送信した後に、第１種の通信要求を送信する可能性が低くなる。このために、通信装置と通信先デバイスとの間の通信負荷が大きくなるのを抑制し得る。
【０００８】
なお、上記の通信装置のための制御方法、コンピュータプログラム、及び、当該コンピュータプログラムを格納するコンピュータ読取可能記録媒体も、新規で有用である。さらに、上記の通信装置と上記の通信先デバイスとを備えるシステムも、新規で有用である。
【図面の簡単な説明】
【０００９】
【図１】通信システムの構成を示す。
【図２】起動処理のフローチャートを示す。
【図３】メイン処理のフローチャートを示す。
【図４】優先順序に従った通信処理のフローチャートを示す。
【図５】デフォルト通信処理のフローチャートを示す。
【図６】第１実施例の多機能機の処理のタイムチャートの一例を示す。
【図７】第２実施例の多機能機の処理のタイムチャートの一例を示す。
【発明を実施するための形態】
【００１０】
（第１実施例）
（システムの構成）
図１に示すように、通信システム２は、ＬＡＮ４と、インターネット６と、多機能機１０、９０と、ＤＨＣＰ（Dynamic Host Configuration Protocol）サーバ６０と、ＳＩＰ（Session Initiation Protocol）サーバ７０と、を備える。多機能機１０とＤＨＣＰサーバ６０とは、ＬＡＮ４に接続されている。多機能機１０とＤＨＣＰサーバ６０とは、ＬＡＮ４を介して相互に通信可能である。ＳＩＰサーバ７０と多機能機９０とは、インターネット６に接続されている。多機能機１０と多機能機９０とＳＩＰサーバ７０とは、インターネット６を介して相互に通信可能である。
【００１１】
（多機能機１０の構成）
多機能機１０は、ＩＰ音声電話機能、ＩＰＴＶ電話機能、ＳＭＳ（ショートメッセージサービス）機能等を含む多機能を実行可能である。ＩＰ音声電話機能は、ＳＩＰＵＲＩ（SIP Uniform Resource Identifier）を用いて、音声データを通信するための機能である。なお、ＩＰ音声電話機能では、映像データは通信されない。ＩＰＴＶ電話機能は、ＳＩＰＵＲＩを用いて、音声データ及び映像データを通信するための機能である。ＳＭＳ機能は、ＳＩＰＵＲＩを用いて、メッセージを通信するための機能である。
【００１２】
多機能機１０は、表示部１２と、操作部１４と、ネットワークインターフェイス１６と、通話デバイス１８と、撮像部１９と、制御部２０と、を備える。各部１２〜２０は、バス線２２に接続されている。なお、多機能機９０も、上記の多機能機１０と同様の構成を備える。
【００１３】
表示部１２は、様々な情報を表示するためのディスプレイである。操作部１４は、複数のキーによって構成されている。ユーザは、操作部１４を操作することによって、様々な指示を多機能機１０に入力することができる。ネットワークインターフェイス１６は、ＬＡＮ４と接続されている。通話デバイス１８は、スピーカ及びマイク（図示省略）を備える。ユーザは、通話デバイス１８のスピーカ及びマイクを用いて、音声通話を行うことができる。撮像部１９は、ＣＣＤ等の撮像素子を備え、撮影対象物を撮影することによって、映像データを生成する。
【００１４】
制御部２０は、ＣＰＵ３０とメモリ３２とを備える。メモリ３２は、プログラム３４、enterprise-numberリスト３６、アドレス帳３８、及び、優先順序テーブル４０を格納する。ＣＰＵ３０は、メモリ３２に格納されているプログラム３４に従って様々な処理を実行する。ＣＰＵ３０が当該プログラム３４に従って処理を実行することによって、各部５０〜５６の機能が実現される。
【００１５】
（enterprise-numberリスト３６）
enterprise-numberリスト３６は、多機能機１０のＳＩＰ通信を実現するための複数のプロバイダを識別する複数のenterprise-numberを含む。enterprise-numberリスト３６は、多機能機１０の出荷段階において、メモリ３２内に予め格納されている。多機能機１０のベンダは、ＩＰＴＶ電話機能を実現不可能であるが、ＩＰ音声電話機能を実現可能であるＳＩＰサーバを提供している各プロバイダを調査して、当該各プロバイダのenterprise-numberをenterprise-numberリスト３６に登録する。このようなＳＩＰサーバは、将来的に、ＩＰＴＶ電話機能が実現可能な仕様に変更される可能性がある。即ち、enterprise-numberリスト３６には、現時点ではＩＰＴＶ電話機能を実現不可能な仕様であるが、将来的にＩＰＴＶ電話機能を実現可能な仕様に変更され得るプロバイダが登録される。
【００１６】
（アドレス帳３８）
アドレス帳３８は、ユーザによって入力されたＳＩＰＵＲＩ、メールアドレス、電話番号等を含む。
【００１７】
（優先順序テーブル４０）
優先順序テーブル４０は、ＳＩＰＵＲＩと、各メディアタイプの優先順序と、変更フラグと、指定日時と、が関連付けられたテーブルである。各メディアタイプの優先順序は、「ａｕｄｉｏ」、「ｖｉｄｅｏ」、及び、「ａｐｐｌｉｃａｔｉｏｎ」の３種類のメディアタイプの優先順序を示す。なお、「ａｕｄｉｏ」はＩＰ音声電話機能に対応し、「ｖｉｄｅｏ」はＩＰＴＶ電話機能に対応し、「ａｐｐｌｉｃａｔｉｏｎ」は音声データ、映像データ、メッセージデータ（ＳＭＳ）を同時に通信する機能に対応する。後で詳しく説明するが、多機能機１０は、ＳＩＰＵＲＩによって特定される通信先デバイスと通信が実行されるべき際に、当該ＳＩＰＵＲＩに関連付けられている優先順序に従って、メディアタイプを利用する。変更フラグは、優先順序が変更済みか否かを示すフラグである。本実施例では、「０」が未変更を示し、「１」が変更済みを示す。指定日時は、優先順序を一時的に変更するか否かの基準となる日時である。なお、優先順序テーブル４０内の各情報は、後述の図３のＳ３６の処理で優先順序テーブル４０に書き込まれる。
【００１８】
（ＳＩＰサーバ７０の構成）
ＳＩＰサーバ７０は、複数のデバイス（例えば多機能機１０、９０）のそれぞれについて、当該デバイスのＩＰアドレスと、当該デバイスのＳＩＰＵＲＩと、を対応付けて記憶している。ＳＩＰサーバ７０は、一対のデバイスの間で通信セッションを確立するために、一方のデバイスから送信されるコマンドを、他方のデバイスに転送する。
【００１９】
（ＤＨＣＰサーバ６０の構成）
ＤＨＣＰサーバ６０は、ＬＡＮ４に接続されている各デバイス（多機能機１０等）にＩＰアドレスを割り当てる。また、ＤＨＣＰサーバ７０は、ＤＨＣＰ情報を記憶している。ＤＨＣＰ情報は、後で説明するｏｐｔｉｏｎ１２０（ＳＩＰサーバ７０のＩＰアドレス）、及び、ｏｐｔｉｏｎ１２５（プロバイダを示すプロバイダ情報）を含む。
【００２０】
（ユーザの事前準備）
多機能機１０が実行する各処理について説明する前に、多機能機１０のユーザが行うべき事前準備について説明する。まず、ユーザは、いずれかのプロバイダと契約することによって、多機能機１０がＳＩＰ通信を実行可能な状態を構築する。以下では、ユーザによって契約されたプロバイダのことを「契約プロバイダ」と呼ぶ。契約プロバイダは、多機能機１０にＳＩＰＵＲＩを割り当てる。多機能機１０のＳＩＰＵＲＩは、契約プロバイダによって提供されるＳＩＰサーバ（例えばＳＩＰサーバ７０）に登録される。これにより、多機能機１０は、当該ＳＩＰサーバを介して、他のデバイスとの間で通信セッションを確立することができる。
【００２１】
さらに、ユーザは、契約プロバイダを示すenterprise-numberと、契約プロバイダによって提供されるＳＩＰサーバのＩＰアドレスと、をＤＨＣＰサーバ６０に登録する。この登録作業は、例えば、ＬＡＮ４に接続されている図示省略のＰＣによって実行される。なお、以下では、契約プロバイダによって提供されるＳＩＰサーバが、ＳＩＰサーバ７０である場合を例として、説明を続ける。
【００２２】
（多機能機１０が実行する処理）
続いて、図２〜図５を参照して、多機能機１０の制御部２０が実行する各処理について説明する。
【００２３】
（起動処理）
図２の起動処理は、多機能機１０が特定の状態であるか否かを判断する処理である。上記の特定の状態は、多機能機１０が、enterprise-numberリスト３６に登録されているいずれかのプロバイダによって提供されるＳＩＰサーバを介して、他のデバイスとの間の通信セッションを確立可能な状態である。換言すると、上記の特定の状態は、多機能機１０のユーザが、enterprise-numberリスト３６に登録されているいずれかのプロバイダと契約している状態である。
【００２４】
多機能機１０の電源がＯＮにされると、Ｓ２において、判断部５６（図１参照）は、ＬＡＮ４に接続されているＤＨＣＰサーバ６０を探索するための探索コマンドをブロードキャストする。ＬＡＮ４に接続されているＤＨＣＰサーバ６０は、探索コマンドを受信すると、自身のＩＰアドレスを含む応答パケットを多機能機１０に送信する。判断部５６は、探索コマンドをブロードキャストすると、Ｓ４において、ＬＡＮ４に接続されるＤＨＣＰサーバ６０が発見されたか否かを判断する。判断部５６は、探索コマンドをブロードキャストしてから所定の時間内に応答パケットを受信した場合に、Ｓ４でＹＥＳと判断する。Ｓ４でＹＥＳの場合、Ｓ６に進む。一方、Ｓ４でＮＯの場合、Ｓ２０に進む。
【００２５】
Ｓ６では、判断部５６は、ｏｐｔｉｏｎ１２０及びｏｐｔｉｏｎ１２５を含むＤＨＣＰ情報の送信を要求する要求コマンドを、ＤＨＣＰサーバ６０に送信する。ＤＨＣＰサーバ６０は、要求コマンドを受信すると、ＤＨＣＰ情報を多機能機１０に送信する。なお、ｏｐｔｉｏｎ１２０は、契約プロバイダによって提供されるＳＩＰサーバ７０のＩＰアドレスを含み、ｏｐｔｉｏｎ１２５は、上記の契約プロバイダを示すプロバイダ情報を含む。ｏｐｔｉｏｎ１２５に含まれるプロバイダ情報は、上記の契約プロバイダのenterprise-numberを含む。Ｓ８において、判断部５６は、ＤＨＣＰサーバ６０から送信されたＤＨＣＰ情報を受信する。
【００２６】
次いで、Ｓ１０において、判断部５６は、受信したＤＨＣＰ情報がｏｐｔｉｏｎ１２０を含むか否かを判断する。例えば、ＳＩＰサーバ７０のＩＰアドレスが、ユーザによってＤＨＣＰサーバ６０に予め登録されている場合には、ＤＨＣＰ情報は、ＳＩＰサーバ７０のＩＰアドレスを示すｏｐｔｉｏｎ１２０を含む。この場合、Ｓ１０でＹＥＳと判断される。一方において、例えば、ＳＩＰサーバ７０のＩＰアドレスが、ユーザによってＤＨＣＰサーバ６０に登録されていない場合（例えばユーザがプロバイダと契約していない場合）には、ＤＨＣＰ情報は、ｏｐｔｉｏｎ１２０を含まない。この場合、Ｓ１０でＮＯと判断される。
【００２７】
ＤＨＣＰ情報がｏｐｔｉｏｎ１２０を含む場合（即ちＳ１０でＹＥＳの場合）、Ｓ１２において、判断部５６は、ＤＨＣＰ情報がｏｐｔｉｏｎ１２５を含むか否かを判断する。例えば、契約プロバイダのenterprise-numberが、ＤＨＣＰサーバ６０に予め登録されている場合には、ＤＨＣＰ情報は、契約プロバイダのenterprise-numberを示すｏｐｔｉｏｎ１２５を含む。この場合、Ｓ１２でＹＥＳと判断される。一方において、例えば、契約プロバイダのenterprise-numberが、ＤＨＣＰサーバ６０に登録されていない場合（例えばユーザがプロバイダと契約していない場合）には、ＤＨＣＰ情報は、ｏｐｔｉｏｎ１２５を含まない。この場合、Ｓ１２でＮＯと判断される。
【００２８】
ＤＨＣＰ情報がｏｐｔｉｏｎ１２５を含む場合（即ちＳ１２でＹＥＳの場合）、Ｓ１４において、判断部５６は、ｏｐｔｉｏｎ１２５に含まれるenterprise-numberが、enterprise-numberリスト３６（図１参照）に含まれるのか否かを判断する。Ｓ１４でＹＥＳの場合、Ｓ１６において、判断部５６は、ｏｐｔｉｏｎ１２０が示す値を、ＳＩＰサーバ７０のＩＰアドレスとして、メモリ３２に記憶させる。次いで、Ｓ１８において、判断部５６は、多機能機１０が上記の特定の状態であることを示す判断結果情報をメモリ３２に記憶させる。Ｓ１８を終えると、起動処理が終了する。
【００２９】
なお、上記のＳ４、Ｓ１０、Ｓ１２、Ｓ１４のいずれかにおいてＮＯと判断される場合、Ｓ２０において、判断部５６は、多機能機１０が上記の特定の状態でないことを示す判断結果情報をメモリ３２に記憶させる。Ｓ２０を終えると、起動処理が終了する。
【００３０】
（メイン処理）
続いて、多機能機１０が多機能機９０と通信する場合を例として、図３のメイン処理の内容を説明する。
【００３１】
この処理が行われるためには、前提条件として、メモリ３２内に、ＳＩＰサーバ７０のＩＰアドレスが記憶されていることが必要である。上記の起動処理で、多機能機１０が上記の特定の状態であると判断された場合（図２のＳ１４でＹＥＳの場合）には、ＳＩＰサーバ７０のＩＰアドレスがメモリ３２に記憶されている（図２のＳ１６）。しかしながら、上記の起動処理で、多機能機１０が上記の特定の状態でないと判断された場合には、ＳＩＰサーバ７０のＩＰアドレスはメモリ３２に記憶されない。この場合、ユーザは、例えば、ＬＡＮ４に接続されている図示省略のＰＣを用いて、契約プロバイダのホームページにアクセスするなどすることによって、ＳＩＰサーバ７０のＩＰアドレスを知ることができる。そして、ユーザは、多機能機１０の操作部１４を操作して、ＳＩＰサーバ７０のＩＰアドレスをメモリ３２に記憶させることができる。
【００３２】
ユーザは、操作部１４を操作して、多機能機９０のＳＩＰＵＲＩを通信先として指定することができる。この指定操作は、アドレス帳３８から多機能機９０のＳＩＰＵＲＩを選択するための操作であってもよいし、多機能機９０のＳＩＰＵＲＩを構成する各文字を多機能機１０に入力するための操作であってもよい。上記の指定操作が実行されると、制御部２０は、図３のメイン処理を実行する。
【００３３】
Ｓ３０において、動作制御部５４（図１参照）は、多機能機１０が上記の特定の状態であるか否かを確認する。具体的には、動作制御部５４は、メモリ３２に記憶されている判断結果情報を読み出し、読み出された判断結果情報が、多機能機１０が上記の特定の状態であることを示す情報であるか否か判断する。判断結果情報が、多機能機１０が上記の特定の状態であることを示す情報である場合、動作制御部５４は、Ｓ３０でＹＥＳと判断する。
【００３４】
本実施例では、上記の起動処理（図２参照）において、判断部５６が既に多機能機１０が上記の特定の状態であるか否か判断している。そのため、ユーザによって上記の指定操作が行われる場合に、制御部２０は、上記の判断を再び実行する必要がなく（即ち図２のＳ２〜Ｓ１４の処理を実行する必要がなく）、判断結果を確認すれば済む（Ｓ３０）。メモリ３２に記憶されている判断結果情報を確認するための処理負荷よりも、上記の判断の処理負荷の方が高いために、多機能機１０の処理負荷が少なくて済む。
【００３５】
（多機能機１０が上記の特定の状態である場合）
多機能機１０が上記の特定の状態である場合（即ちＳ３０でＹＥＳの場合）、Ｓ３４において、動作制御部５４は、ユーザによって指定された多機能機９０のＳＩＰＵＲＩが、メモリ３２内の優先順序テーブル４０内に存在するか否かを判断する。ユーザによって指定された多機能機９０のＳＩＰＵＲＩが、優先順序テーブル４０内に存在する場合（即ちＳ３４でＹＥＳの場合）、Ｓ３８に進む。
【００３６】
一方、ユーザによって指定された多機能機９０のＳＩＰＵＲＩが、優先順序テーブル４０内に存在しない場合（即ちＳ３４でＮＯの場合）、Ｓ３６において、動作制御部５４は、多機能機９０のＳＩＰＵＲＩを、優先順序テーブル４０に書き込む。Ｓ３６では、さらに、動作制御部５４は、多機能機９０のＳＩＰＵＲＩに関連付けて、各メディアタイプの優先順序と、変更フラグと、指定日時と、を優先順序テーブル４０に書き込む。Ｓ３６で書き込まれる各メディアタイプの優先順序は、予め決められており、１位が「ａｕｄｉｏ」であり、２位が「ｖｉｄｅｏ」であり、３位が「ａｐｐｌｉｃａｔｉｏｎ」である。また、変更フラグとして「０」が書き込まれ、指定日時として現在日時の次の月の１日の０時０分が書き込まれる。例えば、現在日時が２０１０年９月１０日１５時０分であった場合、Ｓ３６では、動作制御部５４は、指定日時として「２０１０年１０月１日０時０分」を書き込む。Ｓ３６を終えると、Ｓ３８に進む。
【００３７】
Ｓ３８では、動作制御部５４は、多機能機９０のＳＩＰＵＲＩに関連付けられている変更フラグが「１」であるか否かを判断する。変更フラグが「１」である場合（即ちＳ３８でＹＥＳの場合）、Ｓ４６において、要求実行部５０（図１参照）は、通信処理を実行する。一方、変更フラグが「０」である場合（即ちＳ３８でＮＯの場合）、Ｓ４０において、動作制御部５４は、現在日時が、多機能機９０のＳＩＰＵＲＩに関連付けられている指定日時を経過しているか否かを判断する。現在日時が指定日時を経過していない場合（即ちＳ４０でＮＯの場合）、Ｓ４６において、要求実行部５０は、通信処理を実行する。
【００３８】
一方、現在日時が指定日時を経過している場合（即ちＳ４０でＹＥＳの場合）、Ｓ４２において、動作制御部５４は、多機能機９０のＳＩＰＵＲＩに関連付けられている優先順序を一時的に変更する。具体的には、Ｓ４２では、動作制御部５４は、１位のメディアタイプ（ａｕｄｉｏ）を最下位（３位）に繰り下げるとともに、２位のメディアタイプ（ｖｉｄｅｏ）、３位のメディアタイプ（ａｐｐｌｉｃａｔｉｏｎ）を、それぞれ、１位、２位に繰り上げる。Ｓ４２を終了すると、Ｓ４４において、要求実行部５０は、通信処理を実行する。
【００３９】
（優先順序に従った通信処理（図３のＳ４４及びＳ４６））
図４に示すように、Ｓ６０では、要求実行部５０は、多機能機９０のＳＩＰＵＲＩに関連付けられた優先順序を、優先順序テーブル４０から取得する。例えば、図３のＳ４２で優先順序が一時的に変更されていれば、Ｓ６０では、要求実行部５０は、変更後の優先順序を取得する。
【００４０】
次いで、Ｓ６２において、要求実行部５０は、Ｓ６０で取得された優先順序の１位のメディアタイプを含むＩＮＶＩＴＥコマンドを生成する。具体的には、Ｓ６２では、要求実行部５０は、１位のメディアタイプを表わす情報（例えば「ｖｉｄｅｏ」等）を、ＩＮＶＩＴＥコマンドのｍ行に書き込む。なお、以下では、ＩＮＶＩＴＥコマンドのｍ行にメディアタイプを表わす情報が書き込まれている状態のことを、「ｍ＝書き込まれたメディアタイプ（例えばｖｉｄｅｏ）」と表現する場合がある。Ｓ６２では、さらに、要求実行部５０は、多機能機９０のＳＩＰＵＲＩを送信先として、ＩＮＶＩＴＥコマンドをＳＩＰサーバ７０に送信する（Ｓ６２）。
【００４１】
ＳＩＰサーバ７０は、ＩＮＶＩＴＥコマンドに含まれるメディアタイプが、ＳＩＰサーバ７０自身が利用可能なメディアタイプである場合に、ＩＮＶＩＴＥコマンドを多機能機９０に転送する。一方、ＳＩＰサーバ７０は、ＩＮＶＩＴＥコマンドに含まれるメディアタイプが、ＳＩＰサーバ７０自身が利用不可能なメディアタイプである場合、ＩＮＶＩＴＥコマンドを多機能機９０に転送せずに、多機能機１０にＮＧコマンド（具体的には４８８ Ｎｏｔ Ａｃｃｅｐｔａｂｌｅ Ｈｅｒｅ）を送信する。例えば、ＳＩＰサーバ７０が、ＩＰ音声電話機能を実現可能であるが、ＩＰＴＶ電話機能を実現不可能である状態で、「ｍ＝ｖｉｄｅｏ」を含むＩＮＶＩＴＥコマンドを受信すると、多機能機１０にＮＧコマンドを送信する。
【００４２】
多機能機９０は、ＳＩＰサーバ７０から受信したＩＮＶＩＴＥコマンドに含まれるメディアタイプが、多機能機９０自身が利用可能なメディアタイプである場合、２００ＯＫコマンドをＳＩＰサーバ７０に送信する。この場合、ＳＩＰサーバ７０は、２００ＯＫコマンドを多機能機１０に転送する。一方、多機能機９０は、ＩＮＶＩＴＥコマンドに含まれるメディアタイプが、多機能機９０自身が利用不可能なメディアタイプである場合、ＮＧコマンドをＳＩＰサーバ７０に送信する。この場合、ＳＩＰサーバ７０は、ＮＧコマンドを多機能機１０に転送する。
【００４３】
Ｓ６４において、要求実行部５０は、２００ＯＫコマンドを受信することを監視する。要求実行部５０は、２００ＯＫコマンドを受信した場合（即ちＳ６４でＹＥＳの場合）に、多機能機９０のＳＩＰＵＲＩを送信先として、ＳＩＰサーバ７０にＡＣＫコマンドを送信する。ＳＩＰサーバ７０は、ＡＣＫコマンドを多機能機９０に転送する。これにより、多機能機１０と多機能機９０との間で、ＩＮＶＩＴＥコマンドに含まれるメディアタイプに対応する通信セッションが確立する。例えば、ＩＮＶＩＴＥコマンドが「ｍ＝ａｕｄｉｏ」である場合、メディアタイプ「ａｕｄｉｏ」に対応する通信セッション（ＩＰ音声電話機能のためのＲＴＰ（Real-time Transport Protocol）通信セッション）が確立する。この場合、当該通信セッションを用いて、音声データを通信可能である（映像データを通信不可能である）。また、例えば、ＩＮＶＩＴＥコマンドが「ｍ＝ｖｉｄｅｏ」である場合、メディアタイプ「ｖｉｄｅｏ」に対応する通信セッションが確立する。この場合、当該通信セッションを用いて、音声データ及び映像データを通信可能である。
【００４４】
次いで、Ｓ７０において、対象データ通信部５２（図１参照）は、Ｓ６４で確立された通信セッションを用いて、ＳＩＰサーバ７０を介さずに、通信対象の対象データを多機能機９０と通信する。即ち、多機能機１０と多機能機９０とは、ピアツーピアの通信を実行することによって、対象データの通信を実行する。なお、対象データは、確立済みの通信セッションに対応するメディアタイプに依存する。例えば、確立済みの通信セッションに対応するメディアタイプが「ａｕｄｉｏ」の場合、対象データは、多機能機１０のマイクに入力される音声データと、多機能機９０のマイクに入力される音声データと、を含む。例えば、確立済みの通信セッションに対応するメディアタイプが「ｖｉｄｅｏ」の場合、対象データは、各多機能機１０，９０のマイクに入力される音声データのみならず、多機能機１０の撮像部１９で生成される映像データと、多機能機９０の撮像部で生成される映像データと、を含む。また、例えば、確立済みの通信セッションのメディアタイプが「ａｐｐｌｉｃａｔｉｏｎ」の場合、対象データは、各多機能機１０，９０のマイクに入力される音声データと、多機能機１０の撮像部１９で生成される映像データと、多機能機１０、９０の操作部１２に入力されるメッセージデータである。Ｓ７０が終了すると、図４の通信処理が終了する。
【００４５】
上述したように、多機能機１０は、２００ＯＫコマンドを受信せずに、ＮＧコマンドをＳＩＰサーバ７０から受信することがある。この場合、要求実行部５０は、Ｓ６４でＮＯと判断し、次いで、Ｓ６６において、全てのメディアタイプの試行が終了したか否かを判断する。「ａｕｄｉｏ」、「ｖｉｄｅｏ」、及び、「ａｐｐｌｉｃａｔｉｏｎ」の３種類の全てについて、ＩＮＶＩＴＥコマンドの送信の試行が終了している場合に、要求実行部５０はＳ６６でＹＥＳと判断する。Ｓ６６でＹＥＳの場合、図４の通信処理が終了する。この場合、多機能機１０と多機能機９０との間で通信セッションが確立されず、対象データの通信が実行されない。
【００４６】
一方、全てのメディアタイプの試行が終了していない場合（即ちＳ６６でＮＯの場合）、Ｓ６８において、要求実行部５０は、次の順位のメディアタイプを含むＩＮＶＩＴＥコマンドを、多機能機９０のＳＩＰＵＲＩを送信先として送信する。次いで、要求実行部５０は、Ｓ６４に戻って、２００ＯＫコマンドを受信することを監視する。その後の各処理については、上述の通りである。
【００４７】
図３のＳ４６の通信処理が終了すると、メイン処理が終了する。一方、図３のＳ４４の通信処理が終了すると、Ｓ４８において、動作制御部５４は、１位のメディアタイプを含むＩＮＶＩＴＥコマンドを送信することによって、通信セッションが確立されたのか否かを判断する。ここでＹＥＳの場合、Ｓ５０において、動作制御部５４は、多機能機９０のＳＩＰＵＲＩに関連付けられている変更フラグを「０」から「１」に変更する。さらに、Ｓ５０では、動作制御部５４は、多機能機９０のＳＩＰＵＲＩに関連付けられている指定日時を消去する。Ｓ５０が終了すると、図３のメイン処理が終了する。
【００４８】
一方、１位のメディアタイプを含むＩＮＶＩＴＥコマンドを送信することによって、通信セッションが確立されなかった場合（即ちＳ４８でＮＯの場合）、Ｓ５２において、動作制御部５４は、Ｓ４２で一時的に変更した優先順序を元に戻す。次いで、Ｓ５４において、動作制御部５４は、多機能機９０のＳＩＰＵＲＩに関連付けられている指定日時を更新する。具体的に言うと、動作制御部５４は、新たな指定日時として、現在日時の次の月の１日の０時０分を書き込む。Ｓ５４を終えると、図３のメイン処理が終了する。
【００４９】
（多機能機１０が上記の特定の状態でない場合）
多機能機１０が上記の特定の状態でない場合（即ちＳ３０でＮＯの場合）、Ｓ３２に進む。Ｓ３２では、要求実行部５０は、デフォルト通信処理（図５参照）を実行する。
【００５０】
（デフォルト通信処理（図３のＳ３２））
図５に示すように、Ｓ８０では、要求実行部５０は、多機能機９０のＳＩＰＵＲＩを送信先として、「ｍ＝ｖｉｄｅｏ」を含むＩＮＶＩＴＥコマンドをＳＩＰサーバ７０に送信する。この場合のＳＩＰサーバ７０の動作は、上述の通りである。
【００５１】
Ｓ８２において、要求実行部５０は、２００ＯＫコマンドを受信することを監視する。要求実行部５０は、２００ＯＫコマンドを受信した場合（即ちＳ８２でＹＥＳの場合）に、多機能機９０のＳＩＰＵＲＩを送信先として、ＡＣＫコマンドをＳＩＰサーバ７０に送信する。ＳＩＰサーバ７０は、ＡＣＫコマンドを多機能機９０に転送する。これにより、多機能機１０と多機能機９０との間で、ＩＮＶＩＴＥコマンドに含まれるメディアタイプ「ｖｉｄｅｏ」に対応する通信セッションが確立する。
【００５２】
次いで、Ｓ８４において、対象データ通信部５２は、Ｓ８２で確立された通信セッションを用いて、ＳＩＰサーバ７０を介さずに、通信対象の対象データ（即ち音声データ及び映像データ）を多機能機９０と通信する。Ｓ８４が終了すると、図５のデフォルト通信処理が終了する。
【００５３】
一方、多機能機１０が、２００ＯＫコマンドを受信せずに、ＮＧコマンドを受信した場合（即ちＳ８２でＮＯの場合）、図５のデフォルト通信処理が終了する。この場合、多機能機１０と多機能機９０との間で通信セッションが確立されず、対象データの通信が実行されない。図５のデフォルト通信処理（図３のＳ３２）が終了すると、図３のメイン処理が終了する。
【００５４】
上述の通り、多機能機１０が上記の特定の状態である場合（Ｓ３０でＹＥＳの場合）には、多機能機１０のユーザが、enterprise-numberリスト３６に登録されているいずれかのプロバイダと契約している。従って、多機能機１０が上記の特定の状態である場合、ＳＩＰサーバ７０は、ＩＰＴＶ電話機能が実現可能な仕様に変更されない限り、ＩＰＴＶ電話機能を実現不可能であり、ＩＰ音声電話機能を実現可能である。このために、多機能機１０は、図３のＳ３６で、１位の順位として「ａｕｄｉｏ」を記憶して、通信セッションが確立される可能性が高い「ｍ＝ａｕｄｉｏ」のＩＮＶＩＴＥコマンドを優先的に送信する。一方、多機能機１０が上記の特定の状態でない場合（図３のＳ３２でＮＯの場合）には、ＳＩＰサーバ７０がＩＰＴＶ電話機能を実現可能である可能性が高い。従って、多機能機１０が上記の特定の状態でない場合、多機能機１０は、「ｍ＝ｖｉｄｅｏ」のＩＮＶＩＴＥコマンドを送信する（図５のＳ８０参照）。この構成によると、多機能機１０は、多機能機１０が上記の特定の状態であるのか否かに応じて、適切なＩＮＶＩＴＥコマンドを送信することができる。即ち、通信セッションが確立される可能性が低いＩＮＶＩＴＥコマンドが送信されることを抑制し得る。従って、多機能機１０と多機能機９０との間の通信負荷が大きくなるのを抑制し得る。
【００５５】
（具体例：図６のタイムチャート）
上記の図２〜図５のフローチャートに従って実現される多機能機１０の処理の具体例を説明する。図６の例では、多機能機１０は、上記の特定の状態である。そのため、ＳＩＰサーバ７０は、ＩＰＴＶ電話機能を実現可能な仕様に変更されない限り、ＩＰＴＶ電話機能を実現不可能であり、ＩＰ音声電話機能を実現可能である。従って、図３のＳ３６において、動作制御部５４は、優先順序テーブル４０に、各メディアタイプの優先順序として、１位「ａｕｄｉｏ」、２位「ｖｉｄｅｏ」、３位「ａｐｐｌｉｃａｔｉｏｎ」を記憶させる。以下では、この優先順序のことを「デフォルト優先順序」と呼ぶ。また、Ｓ３６では、動作制御部５４は、優先順序テーブル４０に変更フラグ「０」を記憶させる。この状態では、指定日時が経過する前に、通信指示Ｉ１（即ち多機能機９０のＳＩＰＵＲＩの指定操作）が入力されると、要求実行部５０は、デフォルト優先順序に従って、最初に、「ｍ＝ａｕｄｉｏ」を含むＩＮＶＩＴＥコマンドを送信する。これにより、多機能機１０と多機能機９０との間で通信セッションが適切に確立される。対象データ通信部５２は、メディアタイプ「ａｕｄｉｏ」に従って、対象データ（即ち音声データ）を多機能機９０と通信する。なお、以下では、多機能機９０のＳＩＰＵＲＩに関連付けてデフォルト優先順序が優先順序テーブル４０に継続的に記憶される期間のことを「第１期間」と呼ぶ。
【００５６】
上述の通り、ＳＩＰサーバ７０は、将来的に、ＩＰＴＶ電話機能を実現可能な仕様に変更される可能性がある。そのような仕様の変更の有無を確認するために、指定日時が経過した後に通信指示Ｉ２が入力されると、動作制御部５４は、優先順序テーブル４０内のデフォルト優先順序を他の優先順序に一時的に変更する（図３のＳ４２）。上記の他の優先順序は、１位「ｖｉｄｅｏ」、２位「ａｐｐｌｉｃａｔｉｏｎ」、３位「ａｕｄｉｏ」である。以下では、この優先順序のことを「変更後優先順序」と呼ぶ。この状態では、要求実行部５０は、最初に、「ｍ＝ｖｉｄｅｏ」を含むＩＮＶＩＴＥコマンドを送信することを試行する。なお、以下では、多機能機９０のＳＩＰＵＲＩに関連付けて変更後優先順序が優先順序テーブル４０に一時的に記憶される期間のことを「第３期間」と呼ぶ。なお、変更後優先順序は、ＳＩＰサーバ７０の仕様の変更の有無を確認するために一時的に利用される優先順序である。即ち、「ｍ＝ｖｉｄｅｏ」を含むＩＮＶＩＴＥコマンドによって通信セッションが確立されない場合には、変更後優先順序からデフォルト優先順序に再び変更される。従って、デフォルト優先順序が継続的に記憶される第１期間の中に、変更後優先順序が一時的に記憶される第３期間が含まれると考えることができる。
【００５７】
（ＳＩＰサーバ７０がＩＰＴＶ電話機能を実現可能な仕様に変更されない場合）
通信指示Ｉ２が入力される時点で、ＳＩＰサーバ７０が、ＩＰＴＶ電話機能を実現可能な仕様に変更されていない場合について説明する。この場合、図６の上段に示すように、上記の第３期間において、「ｍ＝ｖｉｄｅｏ」を含むＩＮＶＩＴＥコマンドが送信されても、通信セッションが確立されない（多機能機１０はＮＧコマンドを受信する）。従って、動作制御部５４は、変更後優先順序をデフォルト優先順序に戻す（図３のＳ５２）。また、動作制御部５４は、指定日時を更新する（図３のＳ５４）。この例では、第１期間が継続する。
【００５８】
第１期間が継続する場合には、更新済みの指定日時が経過する前に通信指示Ｉ３が入力されると、多機能機１０は、デフォルト優先順位に従って、上記の通信指示Ｉ１が入力された場合と同様の処理を実行する。また、更新済みの指定日時が経過した後に通信指示Ｉ４が入力されると、多機能機１０は、変更後優先順位に従って、上記の通信指示Ｉ２が入力された場合と同様の処理を実行する。
【００５９】
（ＳＩＰサーバ７０がＩＰＴＶ電話機能を実現可能な仕様に変更される場合）
上記の通信指示Ｉ２が入力される時点で、ＳＩＰサーバ７０が、ＩＰＴＶ電話機能を実現可能な仕様に変更されている場合について説明する。この場合、図６の下段に示すように、「ｍ＝ｖｉｄｅｏ」を含むＩＮＶＩＴＥコマンドによって通信セッションが確立される。この場合、対象データ通信部５２は、メディアタイプ「ｖｉｄｅｏ」に従って、対象データ（即ち音声データ及び映像データ）を多機能機９０と通信する。次いで、動作制御部５４は、多機能機９０のＳＩＰＵＲＩに関連付けられている変更フラグを「１」に変更する（図３のＳ４８でＹＥＳ、Ｓ５０）。この例では、デフォルト優先順位に戻ることなく、変更後優先順序が維持される。この場合、変更後優先順序から他の優先順序にさらに変更されることがなく、変更後優先順序が継続的に記憶される。即ち、多機能機９０のＳＩＰＵＲＩに関連付けて変更後優先順序が優先順序テーブル４０に継続的に記憶される期間に移行する。以下では、この期間のことを「第２期間」と呼ぶ。
【００６０】
第２期間に移行した後に通信指示Ｉ５が入力されると、要求実行部５０は、変更後優先順序に従って、最初に、「ｍ＝ｖｉｄｅｏ」を含むＩＮＶＩＴＥコマンドを送信する。これにより、多機能機１０と多機能機９０との間で通信セッションが適切に確立される。この場合、対象データ通信部５２は、メディアタイプ「ｖｉｄｅｏ」に従って、対象データ（音声データ及び映像データ）を多機能機９０との間で通信する。
【００６１】
（本実施例の効果）
本実施例の通信システム２について詳しく説明した。図６に示すように、第１期間では、「ｍ＝ａｕｄｉｏ」を含むＩＮＶＩＴＥコマンドによって通信セッションが確立されなかった場合に、「ｍ＝ｖｉｄｅｏ」を含むＩＮＶＩＴＥコマンドを送信する。そのため、多機能機９０が、受信したＩＮＶＩＴＥコマンドに含まれるメディアタイプが利用不可能なメディアタイプである場合にＮＧコマンドを送信する（上記の特定のタイプ）場合であっても、多機能機１０は、多機能機９０との間で適切にセッションが確立されるように、ＩＮＶＩＴＥに含まれる情報を変えながら、ＩＮＶＩＴＥの送信を繰り返すことができる。
【００６２】
また、本実施例では、図６に示すように、第１期間（例えば「第１動作モード」と言い換えてもよい）では、最初に、「ｍ＝ａｕｄｉｏ」を含むＩＮＶＩＴＥコマンドが送信され、第２期間（例えば「第２動作モード」と言い換えてもよい）では、最初に、「ｍ＝ｖｉｄｅｏ」を含むＩＮＶＩＴＥコマンドが送信される。指定日時が経過した後に、通信指示Ｉ２が入力されると、第１期間内の第３期間（例えば「第３動作モード」と言い換えてもよい）に移行する。ここで、「ｍ＝ｖｉｄｅｏ」を含むＩＮＶＩＴＥコマンドによって通信セッションが確立されなかった場合（図６の上段）には、第１期間が継続する。一方、「ｍ＝ｖｉｄｅｏ」を含むＩＮＶＩＴＥコマンドによって通信セッションが確立された場合（図６の下段）には、第１期間内の第３期間から第２期間に移行する。第２期間に移行した後に通信指示Ｉ５が入力されると、通信セッションが確立される可能性が高い「ｍ＝ｖｉｄｅｏ」を含むＩＮＶＩＴＥコマンドが最初に送信される。そのため、「ｍ＝ａｕｄｉｏ」を含むＩＮＶＩＴＥコマンドが送信される可能性が低くなる。本実施例によると、通信セッションが確立される可能性が低いＩＮＶＩＴＥコマンドが送信されることを抑制し得る。従って、多機能機１０と多機能機９０との間の通信負荷が大きくなるのを抑制し得る。
【００６３】
また、第１期間が継続する場合（図６の上段）には、指定日時が経過する前に通信指示Ｉ３が入力されると、通信セッションが確立される可能性が高い「ｍ＝ａｕｄｉｏ」を含むＩＮＶＩＴＥコマンドが最初に送信される。そのため、「ｍ＝ｖｉｄｅｏ」を含むＩＮＶＩＴＥコマンドが送信される可能性が低くなる。通信セッションが確立される可能性が低いＩＮＶＩＴＥコマンドが送信されることを抑制し得る。従って、多機能機１０と多機能機９０との間の通信負荷が大きくなるのを抑制し得る。
【００６４】
多機能機９０（通信相手となるデバイス）やＳＩＰサーバ７０は、ファームウェア更新や利用者による機器の買い替えなどにより、利用可能なメディアタイプが変更される可能性がある。メディアタイプが変更された場合に、その通知を受けなければ、送信側装置（多機能機１０）はその変更があったことを知ることができない。したがって、今まで利用不可能なメディアタイプが利用可能に変更されたり、今まで利用可能なメディアタイプが利用不可能に変更されたりした場合、多機能機１０では対応できない。本実施例の多機能機１０は、所定のタイミングで、優先順序を変更したＩＮＶＩＴＥコマンドを送信する。そのため、多機能機９０やＳＩＰサーバ７０が利用可能なメディアタイプが変更された場合であっても、多機能機１０と多機能機９０との間の通信負荷を抑制する順序でのＩＮＶＩＴＥコマンドの送信を行うことができる。
【００６５】
多機能機１０が特定の状態である場合において、所定のタイミングで「ｍ＝ｖｉｄｅｏ」を含むＩＮＶＩＴＥコマンドを送信して通信セッションが確立されなかった場合は、多機能機９０やＳＩＰサーバ７０で、ＩＰＴＶ電話機能（「ｍ＝ｖｉｄｅｏ」）を実現可能とするための仕様変更が行われていないことを意味する。その場合、本実施例の多機能機１０は、指定期間を更新する。従って、通信が実行される毎に、「ｍ＝ｖｉｄｅｏ」を含むＩＮＶＩＴＥコマンドの送信が試行される場合と比べて、多機能機１０と多機能機９０との間の通信負荷が大きくなることを抑制し得る。
【００６６】
また、本実施例では、通信先デバイス（ＳＩＰＵＲＩ）毎に、上記の各処理を行うため、通信先デバイス毎に、適切な優先順序でＩＮＶＩＴＥコマンドを送信することができる。
【００６７】
本実施例の各要素と本発明の各要素の対応関係を記載しておく。「ａｕｄｉｏ」、「ｖｉｄｅｏ」、及び、「ａｐｐｌｉｃａｔｉｏｎ」の３種類の情報が「複数種類の情報」の一例である。「ａｕｄｉｏ」、「ｖｉｄｅｏ」が、それぞれ、「第１種の情報」、「第２種の情報」の一例である。なお、「複数種類の情報」の語は、「異なるメディアタイプに対応する複数種類の情報」と言い換えてもよい。「ｍ＝ａｕｄｉｏ」を含むＩＮＶＩＴＥコマンド、「ｍ＝ｖｉｄｅｏ」を含むＩＮＶＩＴＥコマンドが、それぞれ、「第１種の通信要求」、「第２種の通信要求」の一例である。図５のＳ８０で送信される「ｍ＝ｖｉｄｅｏ」を含むＩＮＶＩＴＥコマンドが「第３種の通信要求」の一例である。デフォルト優先順序、変更後優先順序が、それぞれ、「第１種のデータ」、「第２種のデータ」の一例である。
【００６８】
（第２実施例）
図７のタイムチャートを用いて、第１実施例と異なる点を中心に説明する。第１期間において、指定日時が経過する前に、通信指示Ｉ１１が入力された場合の処理は、図６の例で通信指示Ｉ１が入力された場合の処理と同様である。ただし、第２実施例では、指定日時が経過した後に、通信指示Ｉ１２が入力された場合の処理が、図６の例で通信指示Ｉ２が入力された場合の処理と異なる。即ち、動作制御部５４は、優先順序テーブル４０内のデフォルト優先順序を変更後優先順序に一時的に変更しない。ただし、要求実行部５０は、変更後優先順序に従って、最初に、「ｍ＝ｖｉｄｅｏ」を含むＩＮＶＩＴＥコマンドを送信する。
【００６９】
（ＳＩＰサーバ７０がＩＰＴＶ電話機能を実現可能な仕様に変更されない場合）
図７の上段に示すように、「ｍ＝ｖｉｄｅｏ」を含むＩＮＶＩＴＥコマンドによって通信セッションが確立されない。この場合、動作制御部５４は、指定日時を更新する。第１期間が継続する。その後、更新済みの指定日時が経過する前に通信指示Ｉ１３が入力されると、多機能機１０は、上記の通信指示Ｉ１１が入力された場合と同様の処理を実行する。また、更新済みの指定日時が経過した後に通信指示Ｉ１４が入力されると、多機能機１０は、上記の通信指示Ｉ１２が入力された場合と同様の処理を実行する。
【００７０】
（ＳＩＰサーバ７０がＩＰＴＶ電話機能を実現可能な仕様に変更される場合）
図７の下段に示すように、「ｍ＝ｖｉｄｅｏ」を含むＩＮＶＩＴＥコマンドによって通信セッションが確立される。対象データ通信部５２は、メディアタイプ「ｖｉｄｅｏ」に従って、対象データ（即ち音声データ及び映像データ）を多機能機９０と通信する。次いで、動作制御部５４は、優先順序テーブル４０内のデフォルト優先順序を変更後優先順序に変更する。さらに、動作制御部５４は、変更フラグを「１」に変更する。この場合、変更後優先順序から他の優先順序にさらに変更されることがなく、変更後優先順序が継続的に記憶される。即ち、第１期間から第２期間に移行する。第２期間に移行した後に通信指示Ｉ１５が入力されると、要求実行部５０は、変更後優先順序に従って、最初に、「ｍ＝ｖｉｄｅｏ」を含むＩＮＶＩＴＥコマンドを送信する。これにより、多機能機１０と多機能機９０との間で通信セッションが適切に確立される。対象データ通信部５２は、メディアタイプ「ｖｉｄｅｏ」に従って、対象データ（即ち音声データ及び映像データ）を多機能機９０と通信する。
【００７１】
以上、本発明の具体例を詳細に説明したが、これらは例示にすぎず、特許請求の範囲を限定するものではない。特許請求の範囲に記載の技術には、以上に例示した具体例を様々に変形、変更したものが含まれる。例えば、以下の変形例を採用してもよい。
【００７２】
（変形例１）上記の各実施例では、多機能機１０は、インターネット６を介して、多機能機９０及びＳＩＰサーバ７０と通信可能である。これに代えて、多機能機１０は、ＮＧＮ（Next Generation Network：次世代ネットワーク）を介して、多機能機９０及びＳＩＰサーバ７０と通信可能であってもよい。
【００７３】
（変形例２）上記の各実施例では、優先順序テーブル４０内には、ＳＩＰＵＲＩに関連付けて、各メディアタイプの優先順序が記憶される。これに代えて、メモリ３２内には、ＳＩＰＵＲＩに関連付けて、順位フラグ（「１」又は「０」）が記憶されていてもよい。この場合、要求実行部５０は、ユーザによって指定された通信先のＳＩＰＵＲＩに関連付けられている順位フラグが「０」である場合には、第１種の要求処理を実行し、当該順位フラグが「１」である場合には、第２種の要求処理を実行してもよい。本変形例では、順位フラグ「０」、「１」が、それぞれ、「第１種のデータ」、「第２種のデータ」の一例である。
【００７４】
（変形例３）上記の各実施例では、各メディアタイプの優先順序を変更する際に、１位のメディアタイプを最下位（３位）に変更し、２位、３位のメディアタイプをそれぞれ１位、２位に変更する。これに代えて、１位のメディアタイプと２位のメディアタイプとを入れ替え、３位のメディアタイプの順位を維持してもよい。。
【００７５】
（変形例４）上記の各実施例では、動作制御部５４は、第２期間に移行した後に、変更後優先順序をさらに変更しない。即ち、一般的に言うと、動作制御部５４は、第２期間に移行した後に、要求実行部５０に第２種の要求処理のみを実行させる。これに代えて、動作制御部５４は、第２期間に移行した後に、所定のタイミングで第１種の要求処理を要求実行部５０に試行させてもよい。動作制御部５４は、当該試行において、第１種の通信要求によって通信セッションが確立されなかった場合に、第２期間を維持し、当該試行において、第１種の通信要求によって通信セッションが確立された場合に、第１期間に再び移行させてもよい。
【００７６】
（変形例５）上記の各実施例では、動作制御部５４は、対象データが通信されるべき際に、現在日時が指定日時を経過している場合（図３のＳ４０でＹＥＳの場合）に、各メディアタイプの優先順序を一時的に変更する（Ｓ４２）。即ち、一般的に言うと、所定のタイミングは、現在日時が所定日時を経過している状態で、対象データが通信先デバイスと通信されるべきタイミングである。これに代えて、所定のタイミングは、例えば、通信先デバイスの通信識別情報を送信先として通信要求が送信された回数が所定回数を超えた後に、対象データが通信先デバイスと通信されるべきタイミングであってもよい。また、所定のタイミングは、対象データが通信先デバイスと通信されるべきタイミングでなくてもよく、例えば、通信装置のベンダによって予め決められた日時（例えば毎月１日の０時０分）であってもよい。
【００７７】
（変形例６）上記の各実施例では、例えば、図６の上段の例に示されるように、指定日時が経過する毎に、デフォルト優先順序から変更後優先順序に一時的に変更される。即ち、一般的に言うと、第１期間内に所定のタイミングが２回以上設けられ得る。これに代えて、所定のタイミングが１回のみ設けられるようにしてもよい。即ち、第１期間内に第２種の要求処理が試行された後に、第２種の要求処理が再び試行されないようにしてもよい。
【００７８】
本明細書または図面に説明した技術要素は、単独であるいは各種の組合せによって技術的有用性を発揮するものであり、出願時請求項記載の組合せに限定されるものではない。また、本明細書または図面に例示した技術は複数目的を同時に達成するものであり、そのうちの一つの目的を達成すること自体で技術的有用性を持つものである。
【符号の説明】
【００７９】
２：通信システム、４：ＬＡＮ、６：インターネット、１０：多機能機、６０：ＤＨＣＰサーバ、７０：ＳＩＰサーバ、９０：多機能機
【特許請求の範囲】
【請求項１】
通信装置であって、
通信対象の対象データが通信先デバイスと通信されるべき際に、前記通信装置と前記通信先デバイスとの間で通信セッションを確立するために、第１種の要求処理と第２種の要求処理とを含む複数種類の要求処理のうちのいずれかを実行する要求実行部であって、
前記第１種の要求処理は、複数種類の情報のうちの第１種の情報を含む第１種の通信要求を、前記複数種類の情報のうちの第２種の情報を含む第２種の通信要求よりも先に前記通信先デバイスに送信する処理と、前記第１種の通信要求を送信することによって前記通信セッションが確立されなかった場合に、前記第２種の通信要求を前記通信先デバイスに送信する処理と、を含み、
前記第２種の要求処理は、前記第２種の通信要求を、前記第１種の通信要求よりも先に前記通信先デバイスに送信する処理と、前記第２種の通信要求を送信することによって前記通信セッションが確立されなかった場合に、前記第１種の通信要求を前記通信先デバイスに送信する処理と、を含む、
前記要求実行部と、
前記通信装置と前記通信先デバイスとの間で前記通信セッションが確立されている状態で、前記対象データを前記通信先デバイスと通信する対象データ通信部と、
前記要求実行部の動作を制御する動作制御部と、を備え、
前記動作制御部は、
第１期間では、前記対象データが前記通信先デバイスと通信されるべき毎に、前記要求実行部に前記第１種の要求処理を実行させ、
前記第１期間内の所定のタイミングで、前記要求実行部に前記第２種の要求処理を試行させ、
前記試行において、前記第２種の通信要求を送信することによって前記通信セッションが確立されなかった場合に、前記第１期間を継続し、
前記試行において、前記第２種の通信要求を送信することによって前記通信セッションが確立された場合に、前記第１期間から第２期間に移行させ、
前記第２期間では、前記対象データが前記通信先デバイスと通信されるべき毎に、前記要求実行部に前記第２種の要求処理を実行させる、
通信装置。
【請求項２】
前記通信装置が、特定のサーバを介して、前記通信セッションを確立可能な特定の状態であるのか否かを判断する判断部をさらに備え、
前記複数種類の要求処理は、さらに、第３種の要求処理を含み、
前記第３種の要求処理は、前記複数種類の情報のうちの所定の情報を含む第３種の通信要求を前記通信先デバイスに送信する処理を含み、前記第３種の通信要求を送信することによって前記通信セッションが確立されなかった場合に、他の種類の通信要求を前記通信先デバイスに送信する処理を含まず、
前記動作制御部は、
前記通信装置自身が前記特定の状態であると判断される場合には、
前記第１期間では、前記対象データが前記通信先デバイスと通信されるべき毎に、前記要求実行部に前記第１種の要求処理を実行させ、
前記第１期間内の前記所定のタイミングで、前記要求実行部に前記第２種の要求処理を試行させ、
前記通信装置自身が前記特定の状態でないと判断される場合には、
前記第１期間では、前記通信先デバイスと前記対象データが通信されるべき毎に、前記要求実行部に前記第３種の要求処理を実行させる、請求項１に記載の通信装置。
【請求項３】
前記判断部は、前記通信装置の起動時に、前記判断を実行し、
前記動作制御部は、前記対象データが前記通信先デバイスと通信されるべき毎に、前記判断の結果を確認する、請求項２に記載の通信装置。
【請求項４】
第１種のデータと第２種のデータとを含む複数種類のデータのいずれかを記憶するためのメモリをさらに備え、
前記第１期間は、前記メモリに前記第１種のデータが継続的に記憶される期間であり、
前記第２期間は、前記メモリに前記第２種のデータが継続的に記憶される期間であり、
前記動作制御部は、
前記試行において、前記第２種の通信要求を送信することによって前記通信セッションが確立された場合に、前記メモリに前記第１種のデータが継続的に記憶される状態から、前記メモリに前記第２種のデータが継続的に記憶される状態に変更することによって、前記第１期間から前記第２期間に移行させる、請求項１から３のいずれか一項に記載の通信装置。
【請求項５】
前記第１期間は、前記メモリに前記第２種のデータが一時的に記憶される第３期間を含み、
前記動作制御部は、
前記第１期間内の前記所定のタイミングで、前記メモリに、前記第１種のデータに代えて、前記第２種のデータを一時的に記憶させることによって、前記第１期間内の前記第３期間に移行させ、
前記試行において、前記第２種の通信要求を送信することによって前記通信セッションが確立されなかった場合に、前記メモリに、前記第２種のデータに代えて、前記第１種のデータを記憶させることによって、前記第１期間を継続し、
前記試行において、前記第２種の通信要求を送信することによって前記通信セッションが確立された場合に、前記メモリに前記第２種のデータが記憶される状態を維持することによって、前記第１期間内の前記第３期間から前記第２期間に移行させる、請求項４に記載の通信装置。
【請求項６】
前記メモリは、複数個の通信識別情報のそれぞれについて、当該通信識別情報と、前記複数種類のデータのいずれかと、を関連付けて記憶可能であり、
前記第１期間は、前記複数個の通信識別情報のうち、前記通信先デバイスに対応する特定の通信識別情報に関連付けて、前記第１種のデータが継続的に記憶される期間であり、
前記第２期間は、前記特定の通信識別情報に関連付けて、前記第２種のデータが継続的に記憶される期間である、請求項４又は５に記載の通信装置。
【請求項７】
前記動作制御部は、
前記第２期間では、前記要求実行部に前記第１種の要求処理を試行させない、請求項１から６のいずれか一項に記載の通信装置。
【請求項８】
前記第１期間内の前記所定のタイミングは、現在日時が所定日時を経過している状態で、前記対象データが前記通信先デバイスと通信されるべきタイミングである、請求項１から７のいずれか一項に記載の通信装置。
【請求項９】
通信装置のためのコンピュータプログラムであって、
前記通信装置に搭載されるコンピュータに、以下の各処理、即ち、
通信対象の対象データが通信先デバイスと通信されるべき際に、前記通信装置と前記通信先デバイスとの間で通信セッションを確立するために、第１種の要求処理と第２種の要求処理とを含む複数種類の要求処理のうちのいずれかを実行する要求実行処理であって、
前記第１種の要求処理は、複数種類の情報のうちの第１種の情報を含む第１種の通信要求を、前記複数種類の情報のうちの第２種の情報を含む第２種の通信要求よりも先に前記通信先デバイスに送信する処理と、前記第１種の通信要求を送信することによって前記通信セッションが確立されなかった場合に、前記第２種の通信要求を前記通信先デバイスに送信する処理と、を含み、
前記第２種の要求処理は、前記第２種の通信要求を、前記第１種の通信要求よりも先に前記通信先デバイスに送信する処理と、前記第２種の通信要求を送信することによって前記通信セッションが確立されなかった場合に、前記第１種の通信要求を前記通信先デバイスに送信する処理と、を含む、
前記要求実行処理と、
前記通信装置と前記通信先デバイスとの間で前記通信セッションが確立されている状態で、前記対象データを前記通信先デバイスと通信する対象データ通信処理と、
を実行させ、
前記要求実行処理は、
第１期間では、前記対象データが前記通信先デバイスと通信されるべき毎に、前記第１種の要求処理を実行すること、
前記第１期間内の所定のタイミングで、前記第２種の要求処理を試行すること、
前記試行において、前記第２種の通信要求を送信することによって前記通信セッションが確立されなかった場合に、前記第１期間を継続すること、
前記試行において、前記第２種の通信要求を送信することによって前記通信セッションが確立された場合に、前記第１期間から第２期間に移行すること、及び、
前記第２期間では、前記対象データが前記通信先デバイスと通信されるべき毎に、前記第２種の要求処理を実行すること、
を含む、コンピュータプログラム。
【請求項１】
通信装置であって、
通信対象の対象データが通信先デバイスと通信されるべき際に、前記通信装置と前記通信先デバイスとの間で通信セッションを確立するために、第１種の要求処理と第２種の要求処理とを含む複数種類の要求処理のうちのいずれかを実行する要求実行部であって、
前記第１種の要求処理は、複数種類の情報のうちの第１種の情報を含む第１種の通信要求を、前記複数種類の情報のうちの第２種の情報を含む第２種の通信要求よりも先に前記通信先デバイスに送信する処理と、前記第１種の通信要求を送信することによって前記通信セッションが確立されなかった場合に、前記第２種の通信要求を前記通信先デバイスに送信する処理と、を含み、
前記第２種の要求処理は、前記第２種の通信要求を、前記第１種の通信要求よりも先に前記通信先デバイスに送信する処理と、前記第２種の通信要求を送信することによって前記通信セッションが確立されなかった場合に、前記第１種の通信要求を前記通信先デバイスに送信する処理と、を含む、
前記要求実行部と、
前記通信装置と前記通信先デバイスとの間で前記通信セッションが確立されている状態で、前記対象データを前記通信先デバイスと通信する対象データ通信部と、
前記要求実行部の動作を制御する動作制御部と、を備え、
前記動作制御部は、
第１期間では、前記対象データが前記通信先デバイスと通信されるべき毎に、前記要求実行部に前記第１種の要求処理を実行させ、
前記第１期間内の所定のタイミングで、前記要求実行部に前記第２種の要求処理を試行させ、
前記試行において、前記第２種の通信要求を送信することによって前記通信セッションが確立されなかった場合に、前記第１期間を継続し、
前記試行において、前記第２種の通信要求を送信することによって前記通信セッションが確立された場合に、前記第１期間から第２期間に移行させ、
前記第２期間では、前記対象データが前記通信先デバイスと通信されるべき毎に、前記要求実行部に前記第２種の要求処理を実行させる、
通信装置。
【請求項２】
前記通信装置が、特定のサーバを介して、前記通信セッションを確立可能な特定の状態であるのか否かを判断する判断部をさらに備え、
前記複数種類の要求処理は、さらに、第３種の要求処理を含み、
前記第３種の要求処理は、前記複数種類の情報のうちの所定の情報を含む第３種の通信要求を前記通信先デバイスに送信する処理を含み、前記第３種の通信要求を送信することによって前記通信セッションが確立されなかった場合に、他の種類の通信要求を前記通信先デバイスに送信する処理を含まず、
前記動作制御部は、
前記通信装置自身が前記特定の状態であると判断される場合には、
前記第１期間では、前記対象データが前記通信先デバイスと通信されるべき毎に、前記要求実行部に前記第１種の要求処理を実行させ、
前記第１期間内の前記所定のタイミングで、前記要求実行部に前記第２種の要求処理を試行させ、
前記通信装置自身が前記特定の状態でないと判断される場合には、
前記第１期間では、前記通信先デバイスと前記対象データが通信されるべき毎に、前記要求実行部に前記第３種の要求処理を実行させる、請求項１に記載の通信装置。
【請求項３】
前記判断部は、前記通信装置の起動時に、前記判断を実行し、
前記動作制御部は、前記対象データが前記通信先デバイスと通信されるべき毎に、前記判断の結果を確認する、請求項２に記載の通信装置。
【請求項４】
第１種のデータと第２種のデータとを含む複数種類のデータのいずれかを記憶するためのメモリをさらに備え、
前記第１期間は、前記メモリに前記第１種のデータが継続的に記憶される期間であり、
前記第２期間は、前記メモリに前記第２種のデータが継続的に記憶される期間であり、
前記動作制御部は、
前記試行において、前記第２種の通信要求を送信することによって前記通信セッションが確立された場合に、前記メモリに前記第１種のデータが継続的に記憶される状態から、前記メモリに前記第２種のデータが継続的に記憶される状態に変更することによって、前記第１期間から前記第２期間に移行させる、請求項１から３のいずれか一項に記載の通信装置。
【請求項５】
前記第１期間は、前記メモリに前記第２種のデータが一時的に記憶される第３期間を含み、
前記動作制御部は、
前記第１期間内の前記所定のタイミングで、前記メモリに、前記第１種のデータに代えて、前記第２種のデータを一時的に記憶させることによって、前記第１期間内の前記第３期間に移行させ、
前記試行において、前記第２種の通信要求を送信することによって前記通信セッションが確立されなかった場合に、前記メモリに、前記第２種のデータに代えて、前記第１種のデータを記憶させることによって、前記第１期間を継続し、
前記試行において、前記第２種の通信要求を送信することによって前記通信セッションが確立された場合に、前記メモリに前記第２種のデータが記憶される状態を維持することによって、前記第１期間内の前記第３期間から前記第２期間に移行させる、請求項４に記載の通信装置。
【請求項６】
前記メモリは、複数個の通信識別情報のそれぞれについて、当該通信識別情報と、前記複数種類のデータのいずれかと、を関連付けて記憶可能であり、
前記第１期間は、前記複数個の通信識別情報のうち、前記通信先デバイスに対応する特定の通信識別情報に関連付けて、前記第１種のデータが継続的に記憶される期間であり、
前記第２期間は、前記特定の通信識別情報に関連付けて、前記第２種のデータが継続的に記憶される期間である、請求項４又は５に記載の通信装置。
【請求項７】
前記動作制御部は、
前記第２期間では、前記要求実行部に前記第１種の要求処理を試行させない、請求項１から６のいずれか一項に記載の通信装置。
【請求項８】
前記第１期間内の前記所定のタイミングは、現在日時が所定日時を経過している状態で、前記対象データが前記通信先デバイスと通信されるべきタイミングである、請求項１から７のいずれか一項に記載の通信装置。
【請求項９】
通信装置のためのコンピュータプログラムであって、
前記通信装置に搭載されるコンピュータに、以下の各処理、即ち、
通信対象の対象データが通信先デバイスと通信されるべき際に、前記通信装置と前記通信先デバイスとの間で通信セッションを確立するために、第１種の要求処理と第２種の要求処理とを含む複数種類の要求処理のうちのいずれかを実行する要求実行処理であって、
前記第１種の要求処理は、複数種類の情報のうちの第１種の情報を含む第１種の通信要求を、前記複数種類の情報のうちの第２種の情報を含む第２種の通信要求よりも先に前記通信先デバイスに送信する処理と、前記第１種の通信要求を送信することによって前記通信セッションが確立されなかった場合に、前記第２種の通信要求を前記通信先デバイスに送信する処理と、を含み、
前記第２種の要求処理は、前記第２種の通信要求を、前記第１種の通信要求よりも先に前記通信先デバイスに送信する処理と、前記第２種の通信要求を送信することによって前記通信セッションが確立されなかった場合に、前記第１種の通信要求を前記通信先デバイスに送信する処理と、を含む、
前記要求実行処理と、
前記通信装置と前記通信先デバイスとの間で前記通信セッションが確立されている状態で、前記対象データを前記通信先デバイスと通信する対象データ通信処理と、
を実行させ、
前記要求実行処理は、
第１期間では、前記対象データが前記通信先デバイスと通信されるべき毎に、前記第１種の要求処理を実行すること、
前記第１期間内の所定のタイミングで、前記第２種の要求処理を試行すること、
前記試行において、前記第２種の通信要求を送信することによって前記通信セッションが確立されなかった場合に、前記第１期間を継続すること、
前記試行において、前記第２種の通信要求を送信することによって前記通信セッションが確立された場合に、前記第１期間から第２期間に移行すること、及び、
前記第２期間では、前記対象データが前記通信先デバイスと通信されるべき毎に、前記第２種の要求処理を実行すること、
を含む、コンピュータプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【公開番号】特開２０１２−９０２１３（Ｐ２０１２−９０２１３Ａ）
【公開日】平成２４年５月１０日（２０１２．５．１０）
【国際特許分類】
【出願番号】特願２０１０−２３７２４７（Ｐ２０１０−２３７２４７）
【出願日】平成２２年１０月２２日（２０１０．１０．２２）
【出願人】（０００００５２６７）ブラザー工業株式会社 (13,856)
【Ｆターム（参考）】
【公開日】平成２４年５月１０日（２０１２．５．１０）
【国際特許分類】
【出願日】平成２２年１０月２２日（２０１０．１０．２２）
【出願人】（０００００５２６７）ブラザー工業株式会社 (13,856)
【Ｆターム（参考）】
[ Back to top ]