JP4220471B2 - 家庭ネットワークにおける装置同士のサービス呼出方法 - Google Patents

Description

本発明はネットワークにおけるサービス呼出技術に関し、特に、家庭ネットワークにおける装置同士のサービス呼出方法に関する。

人間の物質生活レベルの向上に従って、家庭範囲内の情報装置、通信装置、娯楽装置、家庭用電気機器、自動化装置、安全監視装置などの装置は次第に増加するとともに、パソコンとインターネットの家庭内での急速な普及、電気通信技術の盛んな発展及び知的装置の長足の進歩によって、家庭ネットワークは益々広く注目されている。簡単、柔軟的且つ信頼的な家庭ネットワークに対するニーズも益々強く要求されている。現在、例えば、知的ホーム（Smart Home）、電子家庭（Electronic Home, e-Home）、デジタルファミリー（Digital Family）、ネットワークホーム（Network Home）、知的化家庭（Intelligent Home）等の家庭ネットワークの概念が提案されている。具体的に、家庭ネットワーク（Home network）は、
（１）家庭における情報装置、通信装置、娯楽装置、家庭用電気機器、自動化装置、安全監視装置などが互いに接続・通信することができ、資源を共用し（リソース・シェアリング）、家庭知的化ネットワークシステムの構築が可能になること；
（２）家庭ネットワークは、ゲートウェイを介して、地域、インターネットと接続し、家庭の外部環境との情報交換を実現すること；
（３）家庭の装置及びその接続するネットワークは、人間の安全、便利、安楽、健康と環境保護の基本需要を満足して、人間に身心を楽しませること；
（４）人を基となす理念を具現して、使用が容易で、安全性と信頼性が高く、メンテナンスが便利で、値段が適切で、ホーム生活に満足する特点を具現すること；
という四つの意味を備えるべきである。

それに鑑み、本願出願人の他の特許出願文献には、デジタル家庭ネットワークシステムを提案している。図１に示すように、このシステムは主にゲートウェイ１１と、1つ以上のメインネット装置１２と、複数の制御サブネット装置１３とから構成され、このゲートウェイ１１は、さらに玄関ゲートウェイ１１０と制御ゲートウェイ１１１との2つの部分を備え、玄関ゲートウェイ１１０と制御ゲートウェイ１１１とは、ブロードバンドインタフェースを介して接続されている。このシステム構成に基づいて、当該デジタル家庭ネットワークはメインネットと制御サブネットの二つのサブネットとからなり、そのうち、玄関ゲートウェイ１１０とそれに接続されている家庭用装置とから構成されたネットワーク部分はメインネットと呼ばれ、主に情報装置、通信装置、娯楽装置などの接続・通信を実現する。制御ゲートウェイ１１１とそれに接続されている家庭用装置とから構成されたネットワーク部分は制御サブネットと呼ばれ、主に家庭電気機器、自動化装置、安全監視装置などの装置の接続・通信を実現する。当該デジタル家庭ネットワークの根本思想は、家庭ネットワークにおける家庭用装置を互いに接続・通信し、資源を共用することである。ここで、家庭ネットワークシステムにおいて、玄関ゲートウェイと、制御ゲートウェイと、サーバとは資源管理装置と総称され、ネットワークの資源を管理するために用いられる。

前記のネットワーク構成に基づいて、ネットワーク装置同士の接続・通信と資源共用は以下のように実現される。

ある装置Aが家庭ネットワークにアクセスすることを請求する時、この装置Aは、まず家庭ネットワークに資源管理装置を検索し、検索された資源管理装置にログイン・リクエスト（ログ・イン要求）を送信し、資源管理装置から許可を得てから、この装置Aと資源管理装置との間に、安全認証をした上で、接続関係を確立する。当該装置Aは、接続が成功した後、ネットワーク中の資源管理装置に装置のログ・インを行い、すなわち、自分の装置情報を資源管理装置に送信し、また、自分の提供できるサービスを資源管理装置にログ・インする。検索するために、資源管理装置はすべての装置ログ・イン情報とサービスログ・イン情報とを記憶している。

二つの家庭ネットワークに接続された装置が通信しようとする時、通信要求を起こさせた装置Aは、まず、資源管理装置に装置検索要求を送信し、資源管理装置は、自分の記憶された装置ログ・イン情報に適当な装置が存在するか否かを調べ、もし適当な装置が存在すれば、該当する情報を装置Aに送信する。また、装置Aは、装置Bに要求を送信して、許可を得てから、装置Bにサービス呼出を行う。現在の動作が完了すれば、二つの装置の間では自動的に接続が切れる（OFF）。

装置がネットワークから離れる時、この装置は、削除動作を行い、資源管理装置から装置情報とサービス情報とを含む自分に関する情報を削除する。

前記の動作プロセスでは、資源管理装置が存在する場合かまたは存在しない場合が可能であり、存在しなければ、装置同士は互い検索するプロセスを介して、自らで協議して対等接続を形成し、通信を行う。一方、資源管理装置が存在する場合には、資源管理装置は、定期的に装置宣言を行い、即ち、他の装置に自分の装置情報を宣言し、他の非資源管理装置も異なる状態では装置宣言を行う。

前記の動作案によれば、家庭ネットワークに基づく様々な適用は、最終的にサービス呼出によって完了する、つまり、家庭ネットワークの接続・通信と資源共用を実現するために、サービス呼出はその中のキーとなるステップである。

本発明は、家庭ネットワークの各装置同士を資源共用を実現させ、且サービス呼出の信頼性を保証する家庭ネットワークにおける装置同士のサービス呼出方法を提供することを目的とする。

前記の目的を達成するために、本発明の家庭ネットワークにおける装置同士のサービス呼出方法は、少なくとも以下のステップ、即ち、サービス呼出側が、サービスの特徴情報によって被呼出サービスのサービスハンドルを取得し、取得されたサービスハンドルで被呼出側にサービス呼出要求メッセージを送信するステップaと、被呼出側プロトコルスタックが、要求メッセージを受信してから、要求メッセージの被呼出サービスハンドルに基づきこの被呼出サービスがあるか否か、及び当該被呼出サービスが、サービス呼出側とのレンタル（rental）関係（専用関係）が確立されているか否かを判断し、そうであれば、被呼出側は、サービス呼出側にサービス呼出結果を含むサービス呼出応答メッセージをリターン（return）し、ステップｃに移行し、そうでなければ本過程を終了するステップbと、サービス呼出側プロトコルスタックが、サービス呼出応答メッセージを受信してから、応答メッセージの呼出サービスハンドルに基づき、本側にこのサービスがあるか否か、及び当該呼出サービスが被呼出側とレンタル関係が確立されているか否かを判断し、そうであれば、サービス呼出側は、被呼出側と実際的なサービス呼出交信過程を開始し、そうでなければ本過程を終了するステップcと、を備える。

サービス呼出側プロトコルスタック及び被呼出側プロトコルスタックは、サービス呼出側と被呼出側とがレンタル関係を確立した後、この方法は、当該被呼出サービスの現在呼び出す数が、当該被呼出サービスの並行制御閾値を超えているか否かを判断し、超えていれば、被呼出側はサービス呼出結果を呼出拒否とし、そうでなければ、被呼出側は、サービス呼出結果を呼出許可とするステップをさらに備える。

この方法は、各サービスがサービスログ・インの成功後、このサービスを識別するためのサービスハンドルを取得することをさらに備える。

前記の技術案において、ステップaにおける前記サービスハンドルの取得は、さらに、サービス呼出側はまず被呼出サービスに対する特徴記載により、ローカルプロトコルスタックに当該被呼出サービスがあるか否かを検索し、該当するサービスがあれば、当該被呼出サービスのサービスハンドルをリターンして、当該被呼出サービス所属側が被呼出側に設定され、そうでなければ検索過程を終了するステップa1と、サービス呼出側は被呼出サービスに対する特徴記載により、ほかの家庭ネットワーク装置に当該被呼出サービスがあるか否かを検索し、該当するサービスがあれば、当該被呼出サービスのサービスハンドルをリターンして、当該被呼出サービス所属側が被呼出側に設定され、そうでなければ検索過程を終了するステップa2とを備える。

前記ステップcにおける実際的なサービス呼出交信過程は、少なくとも一つの基本サービス呼出過程を備え、各基本サービス呼出過程は以下のステップ、すなわちサービス呼出側が、サービス呼出側プロトコルスタック及び被呼出側プロトコルスタックを介して、被呼出側にサービス呼出要求メッセージを送信するステップc1と、被呼出側は、この要求を受信してから、さらに被呼出側プロトコルスタック及び呼出側プロトコルスタックを介してサービス呼出応答メッセージをリターンするステップc2とを備え、この応答メッセージは呼出側が要する情報を含む。

ここで、サービス呼出側プロトコルスタック及び被呼出側プロトコルスタックは、それぞれ自分に提供されるサービス呼出要求コールバック関数及びサービス呼出応答コールバック関数によって、サービス呼出要求及びサービス呼出応答メッセージを処理する。前記サービス呼出要求コールバック関数及びサービス呼出応答コールバック関数は、サービスをログ・インする際、現在のログ・インサービスに応じたアプリケーションにより、本側のプロトコルスタックに転送されるものである。

前記のように、本発明により提供される家庭ネットワークにおける装置同士のサービス呼出方法は、サービスログ・イン、サービス検索及びサービスレンタルに結合し、各サービスが正式に呼出される前に、予めこのサービスが現在使用できるか否か、をチェックし、ログ・インするか否か、レンタル関係を確立するか否か、並行制御に合わせるか否かなどを含むので、サービス呼出動作の安全性、信頼性及び調和性を十分に保証することができる。

以下、図面によって本発明について詳細に説明する。
図２に示すように、最も簡単なサービス呼出過程は、サービス呼出側が被呼出側にサービス呼出要求メッセージを送信し、この要求が呼出側プロトコルスタック及び被呼出側プロトコルスタックを介して被呼出側に転送し、被呼出側がこの要求を受信してから、さらに被呼出側プロトコルスタック及び呼出側プロトコルスタックを介して、サービス呼出応答メッセージをリターンし、また、この応答メッセージには、呼出側が要する情報を含む。実際的な応用では、図２に示すような過程は、呼出側と被呼出側とのサービス呼出動作における１回の交信過程だけで、１回基本サービス呼出過程と呼ばれ、通常、呼出側及び被呼出側から複数回の基本サービス呼出過程を介して、１回の完璧なサービス呼出を完了する。

また、家庭ネットワークにおいて、サービスの動的な変化に適応し、安全性などの要求を満足するために、サービス呼出は、サービスログ・イン、サービス検索、サービス授権、サービスレンタルなどの動作と結合しなければならない。なお、サービスログ・インとサービス検索とが結合すると、サービスの動的な変化に適応でき、サービス授権とサービスレンタルとが結合すると、安全性要求を満足できる。したがって、家庭ネットワークにおけるサービス呼出は、以下の条件を満足する必要がある。

１）各アプリケーション・プログラムが、一つのサービスとして動作するためには、まずサービスログ・インをしなければならない。サービスログ・インにより、サービスの名称、タイプなどの情報を本側のプロトコルスタックに報知することで、サービスの集中管理及びサービス検索が可能となり、また、サービスログ・インの成功後、本側のプロトコルスタックもこのアプリケーション・プログラムに一つのサービスハンドルをリターン（リターンreturn）し、このサービスハンドルは一意に当該サービスを識別でき、その後のサービス検索、サービス授権、サービスレンタル及びサービス呼出において、すべてこのサービスハンドルに関わる。

サービスログ・インをする時、アプリケーション・プログラムは本側のプロトコルスタックに他の情報を伝送し、ただしサービス呼出に関するものは、
a）サービス呼出要求コールバック関数。呼出側プロトコルスタックは、被呼出サービスに送信したサービス呼出要求を受信してから、この関数を呼び出して実際のサービス呼出動作を実行すること。
b）サービス呼出応答コールバック関数。被呼出側プロトコルスタックは呼出側プロトコルスタックにサービス呼出の結果をフィードバックし、呼出側プロトコルスタックはこのフィードバック情報を受信してから、この関数を呼び出して実行結果をサービス呼出側に報知すること。
という２つの内容を含む。

２）サービス呼出の対象を確定するために、サービス呼出側は検索要求に検索したいサービスの名称やタイプなどの情報を指し示し、サービス検索する。呼出側プロトコルスタックは所定の情報に基づき、ログ・インされたサービスを検索し、該当するサービスがあれば、検索されたサービスのサービスハンドルをサービス呼出側に送信し、サービス呼出側は、サービス呼出中に被呼出サービスのサービスハンドルを指し示していれば、具体的なメッセージの送信プロセスはプロトコルスタックにて完成される。

３）安全伝送の側面から見ると、各サービスは、それぞれの安全属性を有し、また、安全属性に従いサービスを開放サービスと私有サービスとに分けられる。ただし、開放サービスとは、何人も呼出できるサービスであり、私有サービスとはサービス所有者の授権（承認authorization）を受けた限り呼出できるサービスである。

４）呼出されるサービスの品質を保証するために、同一項に対して、サービスするとともに、被呼出数を制御するので、家庭ネットワークにおいて、並行制御がある、すなわち、同一項のサービスが、同時に呼出される回数を制御し、この制御動作は、呼出レンタル（レンタル）により完成される。したがって、サービス呼出側は、サービス呼出の前にサービスレンタルが必要となり、サービスレンタルが成功する限り、サービス呼出ができる。具体的なプロセスは、サービス呼出側が、被呼出サービスにサービスレンタル（レンタル）要求を送信し、被呼出サービスは、この要求を受信してから、自体の最大並行支持数及びこのサービスの現在使用様子に基づき、サービスをレンタルするか否かを決める。現在使用数が最大並行支持数に達していれば、サービスをレンタルすることを拒否し、そうでなければ、サービスをレンタルすることを許可して、家庭ネットワークにおける並行制御の実現を保証する。

前記の各条件に基づき、サービス呼出の具体的な実現プロセスは、図４に示すように、以下のステップを含む。

ステップ４０１：あるサービスを呼出する時に、サービス呼出側は、まず被呼出サービスに対応するサービスハンドルを検索し、サービスハンドルを検索した後、サービス呼出側は、サービス呼出要求を被呼出側に送信する。

サービス呼出要求を送信するとともに、サービス呼出側は、具体的呼出情報を含むバッファエリアアドレス及びデータ長さを本側のプロトコルスタックに伝送し、サービス呼出側プロトコルスタックは、被呼出側のサービスハンドルに基づいて、呼出情報を被呼出側のプロトコルスタックに伝送する。

図３に示すように、各サービスは、所属装置が家庭ネットワークに接続された時に、所属装置と家庭ネットワークの資源管理装置にサービスログ・インする。ログ・インが成功した後、各サービスは自分のサービスハンドルを有し、サービスログ・イン応答には、現在ログ・インサービスのサービスハンドルを含む。したがって、サービス呼出プロセスにおいて、呼出サービスのサービスハンドルと被呼出サービスのサービスハンドルを指し示すべきであり、サービスハンドルにてメッセージの交信を完成する。

例を挙げると、呼出サービスと被呼出サービスのサービスハンドルの検索は、以下のようにAサービスがBサービスを呼び出し、またAサービスはサービス呼出側に属し、Bサービスは被呼出側に属する。AサービスはBサービスの存在を知っておらず、自分が検索したいサービスの特徴のみを知っているので、サービス呼出側は、サービス特徴の記述により、サービス呼出側プロトコルスタックに、Bサービスが存在しているか否かを検索し、存在していれば、Bサービスのサービスハンドルをリターンし、その後AサービスハンドルとBサービスハンドルとで通信を続けて、そうでなければ、サービス特徴の記述により、他の家庭ネットワーク装置にBサービスが存在しているか否かを検索し、存在していれば、Bサービスのサービスハンドルをリターンして、Bサービスの所属方を被呼出側と決め、家庭ネットワークのすべての装置にBサービスがなければ、本検索過程を終了する。

ステップ４０２〜４０４：被呼出側はサービス呼出要求を受信した後、サービス呼出要求における被呼出サービスハンドルに基づき、ログ・インされたサービスに該当サービスがあるか否かを検索し、なければ、サービス呼出側にサービスがないエラー・コードB_E_SERVICE_NOT_EXISTをリターンし、サービス呼出側はこのエラー・コードを受信してから本呼出過程を終了し、そうでなければ、ステップ４０５に進む。

ステップ４０５〜４０６：被呼出側プロトコルスタックは、現在被呼出サービスがサービス呼出側の呼出サービスとレンタル関係を確立したかどうかを判断し、確立していなければ、被呼出側はサービス呼出側にサービスレンタルが誤った旨を示すエラー・コードB_E_SERVICE_RENT_DENIEDをリターンし、サービス呼出側は、このエラー・コードを受信してから本呼出過程を終了し、そうでなければ、ステップ４０７に進む。

ステップ４０７：被呼出側は、サービス呼出結果をサービス呼出応答の形式でサービス呼出側に送信し、つまりサービス呼出側がこのサービスを呼出することを許可する指示をリターンし、被呼出側プロトコルスタックは、サービス呼出応答を取得してから、それをサービス呼出側プロトコルスタックにリターンする。

ステップ４０８〜４１２：サービス呼出側プロトコルスタックが、サービス呼出応答を受信した後、サービスハンドルに基づきサービス検索とレンタル関係のチェックを行うことも必要であり、両者の何れかがマルファンクション（malfunction）である場合、すなわち、現在呼出サービスが見つけられない場合、または被呼出サービスと呼出サービスとの間のレンタル関係が確立されていない場合には、この応答メッセージが捨てられ、いずれかの処理を行わないことになり、そうでなければ、ステップ４１３に進む。

ステップ４１３：サービス呼出側のサービス検索及びレンタル関係のチェックもパスーすると、サービス呼出側と被呼出側とは、実のサービス呼出過程を開始する。続くサービス呼出過程には、サービス呼出側と被呼出側とが、それぞれ自分に提供されたサービス呼出コールバック関数により、呼出要求及び応答情報を処理する。このサービス呼出コールバック関数は、サービス呼出要求コールバック関数及びサービス呼出応答コールバック関数を含み、このサービス呼出コールバック関数は、サービスログ・インする時、ログ・インされたサービスに対応するアプリケーション・プログラムから、各側のプロトコルスタックに伝送する。

１回で完了されたサービス呼出が終了されるまで、サービス呼出側と被呼出側との間には、少なくとも１回の基本サービス呼出プロセスの交信を行う。

前記のステップにおいて、この方法は、サービス呼出側や被呼出側がサービス呼出側と被呼出サービスとの間に、レンタル関係が確立されてから、並行制御を行うステップをさらに備えてもよく、すなわち、この被呼出サービスの現在呼出数は、この被呼出サービスの並行制御閾値を超えているか否かを判断し、超えていれば、被呼出側は、サービス呼出結果を呼出拒否にし、そうでなければ、被呼出側は、サービス呼出結果を呼出許可にする。

基本サービス呼出プロセスに対する記載から、サービス呼出プロセスにおいて、レンタル関係をチェックする必要があるので、未承認者（ユーザ）のサービスに対する使用を回避でき、サービス呼出の安全性を保証できることが分かる。

前記のステップにおいて、サービス呼出要求とサービス呼出応答のメッセージフォーマットを、それぞれ表１と表２に示す。そのうち、表１にはサービス呼出要求メッセージの具体的なフォーマットの記述で、フィールド名称、フィールド内容、フィールドタイプ及びこのフィールドの数値の範囲を含む。表２にはサービス呼出応答メッセージの具体的なフォーマットの記述で、フィールド名称、フィールド内容、フィールドタイプ及びこのフィールドの数値の範囲も含む。

表１、表２から、各メッセージの前の６個フィールドは同じであり、即ち、第１番目のフィールドはメッセージ・タイプで、第２番目のフィールドはメッセージのシーケンスナンバで、このシーケンスナンバがメッセージ再伝送及び応答メッセージと要求メッセージの対応に用いられ、第３番目から第６番目までの４個のフィールドは、サービスの呼出側とサービスの被呼出側を指すために用いられる。

実際の応用では、サービス呼出要求メッセージとサービス呼出応答メッセージがXML言語を採用して実現できる。本発明は、アプリケーションプログラムが発信する実際の呼出データ、例えば、呼出したいサービスの内容や性能の記述などに対して、ハイパーテキストトランスファプロトコル（HTTP ,Hypertext Transfer Protocol）にシンプルオブジェクト・アクセスプロトコル（SOAP,simple object access protocol）をプラス（plus）する方式で伝送する。単一なフォーマットのデータ、すなわち、何れかのサービスを呼出する時記入する必要となる汎用データ、例えば被呼出サービスの基本情報について、呼出された動作名称、動作に対応するパラメータ名称及びパラメータ値を指すことで呼出情報を伝送する。他のフォーマットのデータについては、一般的な２値化データとして伝送し、データの具体的意味は、サービス呼出側及び被呼出側により解析され、プロトコルは伝送することしか担任しない。

また、以上に述べたのは本発明の好ましい実施形態にすぎず、本発明の保護範囲を限定するためではないことは言うまでもない。

本発明に適用した家庭ネットワークシステムの構成の模式図である。 サービス呼出の簡単な実現過程の模式図である。 本発明に係るサービス呼出過程を実現する発信タイミングチャートである。 本発明に係るサービス呼出過程を実現するフローチャートである。

符号の説明

１１ ゲートウェイ
１２ メインネット装置
１３ 制御サブネット装置
１１０ 玄関ゲートウェイ
１１１ 制御ゲートウェイ

Claims (6)

1. サービス呼出側はサービスの特徴情報に基づき、各デバイスに登録されたサービスから前記特徴情報に合わせる被呼出サービスを検索し、この被呼出サービスに対する、この被呼出サービスを一意的に識別するためのサービスハンドルが取得され、被呼出側に、取得された被呼出サービスのサービスハンドル及び前記サービス呼出側に登録された呼出サービスの、この呼出サービスに対する、この呼出サービスを一意的に識別するためのサービスハンドルを含んでいるサービス呼出要求メッセージを送信するステップａと、
   被呼出側が、サービス呼出要求メッセージを受信してから、サービス呼出要求メッセージに含まれている被呼出サービスのサービスハンドルに基づき、この被呼出サービスがこの被呼出側にあるか否か、及び当該被呼出サービスが、サービス呼出側の呼出サービスとのレンタル関係が確立されているか否かを判断し、そうであれば、被呼出側は、サービス呼出側にサービス呼出結果及びこの呼出サービスのサービスハンドルを含むサービス呼出応答メッセージをリターンし、ステップｃに移行し、そうでなければ本過程を終了するステップｂと、
   サービス呼出側が、サービス呼出応答メッセージを受信してから、先ず応答メッセージに含まれている、前記呼出サービスのサービスハンドルに基づき、このサービス呼出側にこの呼出サービスがあるか否か、及び当該呼出サービスと被呼出サービスとのレンタル関係が確立されているか否かを判断し、そうであれば、サービス呼出側は、被呼出側と実際的なサービス呼出交信過程を開始し、そうでなければ、本過程を終了するステップｃと、
   を少なくとも備えることを特徴とする家庭ネットワークにおける装置同士のサービス呼出方法。
2. ステップａにおける前記のサービスハンドルの取得は、
   サービス呼出側が、まず被呼出サービスに対する特徴記載によって、ローカルプロトコルスタックに当該被呼出サービスがあるか否かを検索し、該当するサービスがあれば、当該被呼出サービスのサービスハンドルをリターンして検索過程を終了し、そうでなければステップａ２に進むステップａ１と、
   サービス呼出側が、被呼出サービスに対する特徴記載によって、ほかの家庭ネットワーク装置に当該被呼出サービスがあるか否かを検索し、該当するサービスがあれば、当該被呼出サービスのサービスハンドルをリターンして、当該被呼出サービスが所属するデバイスが被呼出側に設定され、そうでなければ検索過程を終了するステップａ２と、
   をさらに備えることを特徴とする請求項１に記載の家庭ネットワークにおける装置同士のサービス呼出方法。
3. ステップｃにおける前記実際的なサービス呼出交信過程は、少なくとも一つの基本サービス呼出過程を備え、各基本サービス呼出過程は、
   サービス呼出側が、呼出サービスモジュールによって、サービス呼出側プロトコルスタック及び被呼出側プロトコルスタックを介して、被呼出側にサービス呼出要求メッセージを送信するステップｃ１と、
   被呼出側がこの要求を受信してから、さらに被呼出側プロトコルスタック及び呼出側プロトコルスタックを介して、サービス呼出側が要する情報を含むサービス呼出応答メッセージをリターンするステップｃ２と、
   を備えることを特徴とする請求項１に記載の家庭ネットワークにおける装置同士のサービス呼出方法。
4. サービス呼出側プロトコルスタック及び被呼出側プロトコルスタックは、それぞれ自分に提供されるサービス呼出要求コールバック関数及びサービス呼出応答コールバック関数によって、サービス呼出要求メッセージ及びサービス呼出応答メッセージを処理することを特徴とする請求項３に記載の家庭ネットワークにおける装置同士のサービス呼出方法。
5. 前記サービス呼出要求コールバック関数及びサービス呼出応答コールバック関数は、サービスをログ・インする際に、現在のログ・インサービスに応じたアプリケーション・プログラムによって、それぞれ所属するサービス呼出側及び被呼出側プロトコルスタックに転送するステップをさらに備えることを特徴とする請求項４に記載の家庭ネットワークにおける装置同士のサービス呼出方法。
6. サービス呼出側や被呼出側が、呼出サービスと被呼出サービスとの間にレンタル関係が確立されてから、この被呼出サービスの現在呼出数がこの被呼出サービスの並行制御閾値を超えているか否かを判断し、超えていれば、被呼出側は、サービス呼出結果を呼出拒否にし、そうでなければ、被呼出側は、サービス呼出結果を呼出許可にするステップをさらに備えることを特徴とする請求項１に記載の家庭ネットワークにおける装置同士のサービス呼出方法。

Images