(57)【特許請求の範囲】
【請求項１】
ネットワークを介してSCP（サービス制御点）へ接続した複数個のIP（知能周辺装置）を含む、IN（知能ネットワーク）電気通信システムで通信する方法において、前記複数個のIPはさらに異なる電気通信幹線を通して互いに接続され、第１媒体で形成した受信形式メッセージを第２媒体で形成した変換形式メッセージに変換する方法の改良であって、前記方法は、
第１媒体で形成した受信形式メッセージを受取人IPが受信する段階と、
SCPによる制御に従い、受取人IPから受信形式メッセージを変換IPへ転送する段階と、
SCPによる制御に従い、変換IPで受信形式メッセージを第２媒体で形成した変換済み形式メッセージに変換する段階と、
SCPによる制御に従い、変換IPから変換済み形式メッセージを配達IPへ転送する段階と、
SCPによる制御に従い、配達IPから第２媒体で形成した変換済み形式メッセージを前記メッセージの意図した受取人へ配達する段階と、
を含む、第１媒体で形成した受信形式メッセージを第２媒体で形成した変換形式メッセージに変換する方法の改良。
【請求項２】
請求項第１項記載の方法において、受信形式メッセージが与えられる少なくとも２つの受取人IPと、受信形式メッセージが転送される変換IPと、変換済みメッセージが転送される配達IPと、が並置される方法。
【請求項３】
請求項第１項記載の方法において、電気通信幹線を通して接続された前記IPはTCP/IP通信プロトコルを使用して互いに通信する方法。
【請求項４】
請求項第１項記載の方法において、電気通信幹線を通して接続された前記IPはX.25通信プロトコルを使用して互いに通信する方法。
【請求項５】
請求項第１項記載の方法において、受信形式メッセージは非呼関連メッセージを含む方法。
【請求項６】
請求項第１項記載の方法において、受信形式メッセージは蓄積転送サービスと適合する方法。
【請求項７】
請求項第１項記載の方法において、前記第１媒体と前記第２媒体は、音声メール・メッセージ、e-mailメッセージ、ファックス・メール・メッセージ、SMS（ショート・メッセージ・サービス）形式のメッセージから構成されるグループから選択される方法。
【請求項８】
請求項第１項記載の方法において、ユーザのメールボックスの状態の変化の受取人IPによるSCPへ通知する中間段階を更に含み、通知の前記段階時にSCPの通知に応答して、受取人IPから変換IPへ受信形式メッセージを転送する前記段階が実行される方法。
【請求項９】
請求項第１項記載の方法において、ユーザのメールボックスの状態に関して受取人IPへ問合せする段階をさらに含み、前記受取人IPから前記変換IPへの受信形式メッセージを転送する前記段階は、前記問合せ段階時のSCPからの問合せに応答して実行される方法。
【請求項１０】
請求項第１項記載の方法において、前記受取人IPから前記変換IPへの前記受信第１メッセージを転送する前記段階は、フェッチ（FETCH）指令を使用して実行される方法。
【請求項１１】
請求項第１項記載の方法において、受信形式メッセージを前記変換済み形式メッセージへ変換する前記段階は、加入者の変換及び配達選択に従って実行される方法。
【請求項１２】
請求項第１項記載の方法において、受信形式メッセージを前記変換済み形式メッセージに変換する前記段階は、変換（CONVERT）指令を使用して実行される方法。
【請求項１３】
請求項第１項記載の方法において、第２媒体で形成した変換済み形式第２メッセージを前記メッセージの意図した受取人に配達する前記段階は、メッセージ送信（SEND MESSAGE）指令（図１９）を使用して実行される方法。
【請求項１４】
ネットワークを介してSCP（サービス制御点）へ接続した複数個のIP（知能周辺装置）を含む、IN（知能ネットワーク）電気通信システムにおいて、前記複数個のIPはさらに異なる電気通信幹線を通して互いに接続され、第１媒体で受信した第１メッセージを第２媒体の第２メッセージに変換するシステムであって、前記システムは、
前記第１媒体の前記第１メッセージを受取人IPに受信する装置と、
SCPによる制御に従い、前記受取人IPからの前記受信第１メッセージを変換IPへ転送する装置と、
SCPによる制御に従い、前記変換IPの前記受信第１メッセージを前記第２媒体の前記第２メッセージに変換する装置と、
SCPによる制御に従い、変換IPから前記変換済み第２メッセージを配達IPへ転送する装置と、
SCPによる制御に従い、配達IPから前記第２媒体の前記変換済み第２メッセージを前記メッセージの意図した受取人へ配達する装置と、
を含む、第１媒体で受信した第１メッセージを第２媒体の第２メッセージに変換するシステム。
【請求項１５】
請求項第１４項記載の媒体変換システムにおいて、前記受取人IP、前記変換IP、及び前記配達IPを含む２つ以上のグループは物理的に並置されている、媒体変換システム。
【請求項１６】
請求項第１４項記載の媒体変換システムにおいて、電気通信幹線を通して接続された前記IPはTCP/IP通信プロトコルを使用して互いに通信する、媒体変換システム。
【請求項１７】
請求項第１４項記載の媒体変換システムにおいて、電気通信幹線を通して接続された前記IPはX.25通信プロトコルを使用して互いに通信する、媒体変換システム。
【請求項１８】
請求項第１４項記載の媒体変換システムにおいて、前記第１メッセージは非呼関連メッセージである媒体変換システム。
【請求項１９】
請求項第１４項記載の媒体変換システムにおいて、前記第１メッセージは蓄積転送サービスと適合する媒体変換システム。
【請求項２０】
請求項第１４項記載の媒体変換システムにおいて、前記第１媒体と前記第２媒体は、音声メール・メッセージ、e-mailメッセージ、SMS（ショート・メッセージ・サービス）形式から構成されるグループから選択される、媒体変換システム。
【請求項２１】
請求項第１４項記載の媒体変換システムにおいて、受取人IPから前記受信第１メッセージを変換IPへ転送する前記装置は、ユーザのメールボックスの状態の変化の前記受取人IPによるSCPへの通知に応答する、媒体変換システム。
【請求項２２】
請求項第１４項記載の媒体変換システムにおいて、受取人IPから前記受信第１メッセージを変換IPへ転送する前記装置は、ユーザのメールボックスの状態に関するSCPから受取人IPへの問合せに応答する、媒体変換システム。
【請求項２３】
請求項第１４項記載の媒体変換システムにおいて、受取人IPから前記受信第１メッセージを変換IPへ転送する前記装置は、フェッチ（FETCH）指令（図１６）を含む媒体変換システム。
【請求項２４】
請求項第１４項記載の媒体変換システムにおいて、前記受信第１メッセージを前記変換済み第２メッセージに変換する前記装置は、加入者の変換と配達選択により変換を適合させる装置を更に含む媒体変換システム。
【請求項２５】
請求項第１４項記載の媒体変換システムにおいて、前記受信第１メッセージを前記変換済み第２メッセージに変換する前記装置は、変換（CONVERT）指令（図１７）を含む媒体変換システム。
【請求項２６】
請求項第１４項記載の媒体変換システムにおいて、前記第２媒体の前記変換済み第２メッセージを前記メッセージの意図した受取人に配達する前記装置は、メッセージ送信（SEND MESSAGE）指令（図１９）を含む媒体変換システム。
【請求項２７】
IN（知能ネットワーク）で、第１媒体で形成し発呼者から発呼された受信形式メッセージを、加入者へ配達すべき、第２媒体で形成した変換済み形式メッセージに変換する装置において、
発呼者により発呼された受信形式メッセージを受信する受取人IP（知能周辺装置）と、
前記受取人IPへ結合された変換IP（知能周辺装置）であって、前記受取人IPにより受信された受信形式メッセージを変換済み形式メッセージへ変換する前記変換IPと、
前記受取人IPに結合された配達IP（知能周辺装置）であって、変換済み形式メッセージを加入者に配達する前記配達IPと、
前記受取人IPと、前記変換IPと、前記配達IPとに結合されたSCP（サービス制御点）であって、前記受取人、変換、及び配達IPの各々の間で受信形式及び変換済み形式メッセージの各々の転送を制御し、前記変換IPにより実行される変換を制御する前記SCPと、
を含む、第１媒体で形成し発呼者から発呼された受信形式メッセージを、加入者へ配達すべき、第２媒体で形成した変換済み形式メッセージに変換する装置。
【請求項２８】
請求項第２７項記載の装置において、前記SCPはフェッチ指令を発行し、前記受取人IPから前記変換IPへ受信形式メッセージの転送を開始する、装置。
【請求項２９】
請求項第２７項記載の装置において、前記SCPは変換指令を発行し、受信形式メッセージの前記変換IPによる変換済み形式メッセージへの変換を開始する、装置。
【請求項３０】
請求項第２７項記載の装置において、前記SCPはフェッチ指令を発行し、前記変換IPから前記配達IPへ変換済み形式メッセージの転送を開始する、装置。
【請求項３１】
請求項第２７項記載の装置において、前記SCPはメッセージ送信指令を発行し、変換済み形式メッセージの前記配達IPによる加入者への配達を開始する、装置。
【請求項３２】
請求項第２７項記載の装置において、第１媒体で形成した受信形式メッセージは、音声メッセージ、e-mailメッセージ、ファックス・メール・メッセージ、SMS（ショート・メッセージ・サービス）メッセージの内の第１に選択したものを含み、前記変換IPは、第１に選択されたものから形成された受信形式メッセージを、音声メッセージ、e-mailメッセージ、SMSメッセージの内の第２に選択したものに変換する、装置。
【請求項３３】
請求項第２７項記載の装置において、前記SCPによりアクセス可能な加入者選択記憶装置をさらに含み、前記加入者選択記憶装置は、加入者が選択した配達すべき変換済み形式メッセージの望ましい媒体の指示を記憶し、前記SCPは前記加入者選択記憶装置をさらにアクセスしてそこに記憶した指示をアクセスし、かつ前記変換IPに、受信形式メッセージを変換済み形式メッセージに変換するよう指令し、変換済み形式メッセージは望ましい媒体に形成される、装置。
【発明の詳細な説明】
関連出願との相互引用
本米国特許出願は、以下の共願米国特願と関係する：（１）加入者活動の監視のシステムと方法、一連番号第08/723,620号（代理人資料番号第27946-00157号）、ボー・アーネ・バルデマー・オストローム、ロバート・ヨハン・ベルナルダス・シュマーセル、グラマバス・スマー、ビョルン・アーネ・スベンソンの名前で1996年10月3日提出；（２）蓄積転送サービスの入出質問のシステムと方法、一連番号第08/724,769号（代理人資料番号第27946-00158号）、ボー・アーネ・バルデマー・オストローム、ロバート・ヨハン・ベルナルダス・シュマーセル、グラマバス・スマー、ビョルン・アーネ・スベンソンの名前で1996年10月3日提出；（３）IP作動の呼設定のシステムと方法、一連番号第08/725,431号（代理人資料番号第27946-00159号）、ボー・アーネ・バルデマー・オストローム、ロバート・ヨハン・ベルナルダス・シュマーセル、グラマバス・スマー、ビョルン・アーネ・スベンソンの名前で1996年10月3日提出。これらの共願の特願及びこれらから得られるその他の国内又は国外特願とこれらに含まれる開示は本明細書に引用により全て含まれる。
本特願と上記全ての関連共願特願はテレフォナクチボラゲットLMエリクソン（公社）に譲渡される。
説明
１．発明の技術分野
本発明は補助的な電気通信サービスの提供に関係し、特に、ある媒体で受信したメッセージの他の媒体への変換を容易にするシステムと方法に関係する。
２．関連技術の説明
カスタマイズされた電気通信サービスに対する顧客の需要はさらに急速に成長している。通話中着信サービス、転送サービス、短縮ダイアル、等のような特別の加入者機能は、個々の加入者にとって更なる利便性を与えると共に、電気通信事業者にとっても追加の収入源としてさらに重要になってきている。このようなサービスは、特定の加入者にサービスする中央局交換機のソフトウェアの特別なプログラミングにより一般的に提供される。すなわち、局内交換機ソフトウェアが個別にプログラムされて特別なサービス機能をそこに接続した加入者に提供している。特殊な加入者機能の提供を可能とするため交換機のハードウェアとソフトウェアと両方をしばしば改良しなければならない。
ある呼が異なる交換機に接続した２加入者間の相互接続を含む時、個々の中央局交換機と互いに相互接続するネットワークの一部を形成するいわゆる通過又はタンデム交換機を介してそれは完了される。このような場合、通過交換機は呼の２加入者には完全に透明であり、２つの端局間の音声路を単に提供する。どちらかの加入者により起動された特殊なサービス機能は、２加入者間のネットワーク接続とは独立に、その加入者が接続されている端局により伝統的に提供されてきた。
単純な旧式の電話サービス（POTS）を提供する電気通信システムでは、発呼側（甲加入者）と被呼側（乙加入者）間の通信リンクは甲加入者の制御下にある。従って、甲加入者と乙加入者との間の通信リンクは、甲加入者の電話機器が「オンフック（終話）」となるまでそのまま留まり、このオンフックの場合に、システムは通信リンクと、両加入者の端局、及び端局を互いにリンクするのに使用した通過交換機を切断する。乙加入者が電話機器をオンフックに戻した場合でも、タイマが呼加入者と被呼加入者間の回線の切断をトリガする数分のオーダーの時間後までは何の効果もない。統合サービス・ディジタル・ネットワーク（ISDN）のような新しい型式の電気通信サービスでは、乙加入者切断が使用されているが、これを実装する機構はこれらの従来のPOTSネットワークとは著しく異なる。
従来の電気通信交換機内で特別な加入者サービスを提供することは、このような特別なサービスを顧客に提供する全ての及び各々の交換機のソフトウェアのアップグレードを必要とする。交換機のこのような更新はしばしば非常に高価であり、余分な加入者サービスにより与えられる付加収入に関する経費・有効性の観点からは実質的に法外なものである。特別な加入者サービスの需要が相対的に低く、かつ既存の交換機が相当期間の間配置されていてその区域の加入者の大多数の基本的電気通信需要を適切にサービスし続けているような小さな町又は田園地帯では、この意見はさらに正しいものになる。
電気通信事業は増大する競争圧力に直面している。電気通信事業者の分当りの収入は多数の要因によりどんどん減少している。電気通信サービスの規制緩和は業界の競争者数を増大している。さらに、コールバック・サービスや電話カードのような革新は、国の間の両側の電話代の鞘取り差をユーザに可能としている。また、有線テレビ会社はそのケーブル・ネットワークを通した電話サービスを提供開始している。最後に、革新的なソフトウェアがインターネット上での高品質全2重呼を可能にしている。
技術の進歩も基本電話サービスを提供するコストを減少している。電気通信会社は、基本電話サービスの提供に課した相対的に高い料金表をもはや正当化できない。技術の進歩は電話呼の配達の実際のコストを実質的にないところまで引き下げた。経済用語では、基本電話サービスは、ゼロ限界費用ビジネスとして見ることが出来る。何年かに渡ってデスクトップコンピュータに能力対価格性能比を増大させた進歩も、現代の電話交換機の信頼性と効率を押し上げた。
同様の状況が相互交換接続にも得られる。光学ファイバの使用により、相当量の容量が電話ネットワークに追加された。帯域はもはや数年前にそうであったような不足リソースであるものとは見なされず、事実、しばしば大量に売買される商品となった。
技術の進歩は又、電話呼を提供するコストの重要な因子として発呼加入者と被呼加入者との間の地理的距離の効果も減少させた又は除去した。ストックホルムからダラス（約8,000キロメータの距離）へ発呼するためのネットワーク・リソースに関してダラスからオースティン（約300キロメータの距離）へ発呼するよりコストがかからないと言われている。
インターネットの爆発的な成長は、その基本のTCP/IPプロトコルが送信すべき電子メールとファイル転送を、関係する転送距離とは無関係に実行できるように開発したことに大きく依存している。
長距離サービスの提供が局内基本電話サービスの提供よりそれ程経費がかかっていないにも係らず、電気通信事業者は局内呼より長距離電話呼により多くを課金し続けている。電気通信業界の競争の増大はこの状況をますます持続できないものにしようとしている。長距離呼は伝統的に電気通信会社の運営利益の相当な部分であったため、電気通信会社が新たな収入源を見出す必要のあることはますます明白である。
電気通信事業者が収入を増大する1つの方法は、加入者が喜んで割増金を支払う進化したサービスを加入者に提供することによる。前述したように、過去のネットワーク・アーキテクチャでは、ネットワークへの新たな機能の追加はコアの交換機ソフトウェアを書き換える必要があった――新たなバグをシステムに持ち込む余分な危険性を担時する高価で時間のかかるプロセスである。さらに、ネットワークの各交換機を新たなソフトウェアで更新しなければならず、これは新たなサービスを導入するコストをさらに増大させる。電気通信事業者はもはやこのような事態の状態を大目に見るわけにはいかない。製品を最初に市場に出せる電気通信機器製造業者にとっては巨大なビジネス機会がある。
電気通信業者はその電気通信ネットワークへの新たなサービスの導入に対する迅速で高価ではない技術の必要性を表明していた。さらに、また新たな機能の影響が1つ又はいくつかの交換機のみに限定されることも必要としていた。また、サービスの設置又は変更、顧客固有のデータの追加、等のようなサービス管理業務が中央管理施設から処理可能であることも望ましい。
新たなサービスの設計と実装が機器製造業者ではなく電気通信事業者により実施されることも望ましい。これにより、電気通信事業者が理解した市場の必要性に迅速に反応し、その顧客に有効にかつ効率的にサービスできる。加入者と相互作用できる各種のサービスを可能とするよう交換機ソフトウェアにより大きな知能を含ませることも望ましい。このようにして、電話機器は電気通信ネットワークへの進化したインターフェースとなりうる。
知能ネットワーク（Intelligent Network, IN）は以上の必要性を解決する解法として提案された。IN技術は、電気通信事業者が自身のユニークなサービスの組を設計し、または既存のサービスを特定の顧客の必要性に適合させることを可能とするよう設計されている。さらに、INアーキテクチャは新たなサービスの設置の影響をいくつかの制御ノードに限定可能である。
INアーキテクチャのその他の設計の特徴は、そのサービスの中央化管理である。これは応答時間を改良し、かつネットワークを動作させるのに必要な人間のリソースのオーバーヘッドを減少させる。さらに、INアーキテクチャはある種の顧客固有データの顧客制御を可能とする。
例えば、電気通信事業者は「個人番号」サービスを提供する。個人番号サービスは、各加入者に特定の電話番号、通常500の「地域コード」を前に付けたもの、を与えることを含む。個人番号サービスの背後にある設計思想は、各加入者の多くの交信番号を1つの電話番号で補うことである。従って、だれかが加入者の個人番号をダイアルした時、交換機は中央のデータベースに問合せし、加入者が多分居るであろう全ての電話番号のリストを得る。交換機は次いで呼が応答を得るまで、これらの番号を所定の順序で呼び出す。
このサービスの1つの変形では、加入者には任意の電話機器から接触番号データベースを動的に交信する能力を提供される。このような顧客制御は、加入者が自分が一時的に居住しているホテル又は他の場所の番号を追加可能とする。
INアーキテクチャの背後にある設計思想は、新たなサービスの提供を市場に出す時間を減少すること、開発及び管理コストを低減すること、割増サービスの提供から得られる利益を強化することである。INサービスの古典的な例は、複数の局サービス・センターの内のひとつにふり向け直される大きな地理的区域にわたる顧客による単一のダイアル番号（B番号）の使用である。従って、ピザのフランチャイズ本店はピザの注文に単一の電話番号を宣伝可能である。顧客が宣伝の番号をダイアルすると、INサービスは多数のダイアル加入者の番号（A番号）を基に最も近いフランチャイズ支店へ呼をふり向けることが出来る。
INの簡単な歴史
知能ネットワークの概念は米国で発生した。最初の意図は、単一のダイアルした番号を異なる終端番号に翻訳する中央データベースを提供することであった。INサービスの最も初期の応用例の一つは、料金無料電話（「フリーフォーン」）を提供することであった。
料金無料番号は直接的に物理電話線に対応してはおらず、実際の終端番号に翻訳する必要がある。翻訳は発呼者の位置と時間に依存する。
呼設定の前及びその間に電話交換機間の高速通信を可能とするため、第7信号方式（SS7）と呼ばれる新たな信号方式が開発された。SS７プロトコルが料金無料発呼の実装に必要な高速データベース検索を最初に可能とした。SS7技術の開発後、電話ネットワーク上で実質的に瞬間的にデータが交換可能となった。これが知能ネットワークの創世記である。
INの革命の次の段階は、顧客固有データの顧客制御を可能とする、静的データベースから動的なものへの移行であった。加入者が加入者の機器からキーパッド相互作用により呼の進行を制御できた時、さらなる相互性が可能となった。このような相互INは米国では進化した知能ネットワーク（AIN）と呼ばれている。
INアーキテクチャの現在の開発と興味はいくつかの大規模アプリケーションにより駆り立てられている。2つのこのようなアプリケーションは、汎用個人番号（UPN）サービスと仮想私用ネットワーク（VPN）サービスである。UPNサービスでは、ユニークな番号が電話機器ではなく各個人に割当てられる。UPN番号を使用してその加入者の位置又はネットワークの型式（固定又は移動）に係らず加入者に着信可能である。
VPNサービスにより、公衆ネットワーク・リソースを使用して私用ネットワークを構築することが可能となる。従って、物理的な私用ネットワークを与えるのに必要なハードウェア又はソフトウェアに投資することなく、ある会社がその従業員の全てが互いに通信可能な会社電話ネットワークを有することが出来る。公衆ネットワークを私用したVPNサービスを実装することにより、会社顧客も物理ネットワークを保持するコストを避けることが出来る。
現在のINシステムの不適当な点
知能ネットワーク（IN）アーキテクチャの使用は、新たなネットワーク能力とネットワーク・サービスの包含と敷衍を加速するための解決法として擁護されてきた。しかしながら、IN概念を実装するための現在はっきりした標準は多数の欠点をこうむっている。
例えば、加入者は電子メール（e-mail）、ポケットベル・メッセージ、ショート・メッセージ・サービス（SMS）形式、等のような非呼関連入メッセージを受取る。伝統的には、これらのメッセージ型式の各々は別々に処理され、メッセージ型式に固有のメールボックスを介して意図した受取人に配達される。従って、加入者はファクシミリ・メッセージ・メールボックスを調べて、ファクシミリ・メッセージが届いていて注意を待っているかどうかを決定しなければならず、かつこれとは別に電子メール・メッセージ・メールボックスを調べてe-mailメッセージが未読のままであるかどうかを決定しなければならない、等々である。
加入者は、各種の可能な入力形式で受信した入メッセージを加入者に渡す前に、ある媒体から他へ翻訳又は変換したいと思っていることに、サービス提供業者は気付いた。各加入者は自分の入メッセージを配達する形式に関して異なる好みを有している。従って、例えば、加入者Aはファクシミリ伝送を受取るたびにe-mail通知を受取りたいが、以後の検索と再吟味用にはファクシミリ伝送の内容を読み上げるか又は音声メールボックスに記憶したいかもしれない。
電気通信サービス提供者が各加入者の通知と配達の選択を記憶できる場合、そして多分加入者による望ましい受信形式の相互選択を可能とする場合、サービス提供者は加入者に強化した価値を提供でき、余分な収入を受取ることが出来る。
従って、知能ネットワーク内で何らかの手段を設けて、記憶した顧客の選択に基づいて又は加入者との相互ダイアログによりある媒体で受信したメッセージを他の媒体へ変換できることが非常に望ましい。このことは、非呼関連メッセージをある媒体から他へ受信、記憶、変換、転送、するシステムと方法を必要とする。
発明の要旨
それ故、本発明の主要な目的は、ある媒体で受信したメッセージの第２媒体への容易な変換を可能とすることである。本発明の1実施例は、ネットワークを介してSCP（サービス制御点）へ接続された複数個のIP（知能周辺装置）を含むIN（知能ネットワーク）電気通信装置で実装される。複数個のIPはさらに互いに接続される。
本発明の実施例では、第1媒体の第1メッセージが受取人IPで受信される。受信した第1メッセージは次いで受取人IPから変換IPへ転送される。転送された第1メッセージは次いで変換IPで第2媒体の第2メッセージに変換される。変換された第2メッセージは次いで電気通信幹線を通して集配IPへ転送される。最後に、変換された第2メッセージが第2媒体でメッセージの意図した受取人へ渡される。
【図面の簡単な説明】
本発明の方法と装置のより完全な理解は、添付の図面と関連して行なわれる、以下の望ましい実施例の詳細な説明を参照して得られる：
図１は標準の知能ネットワーク（IN）概念モデルを図示する図解用線図である。
図２は例示の簡単な知能ネットワークの部品を図示する。
図３はサービス独立な構成ブロック（SIB）の構造を図示する。
図４は各種のIN機能エンテティの物理装置へのマッピングを図示する。
図５は通過レベルでのサービス・ノードによるIN実装の例を図示する。
図６はIN概念モデルで各種のサービスを実装するための望ましい方法論を図示する。
図７はAPIの実装に向けた2つの方式を図示する。
図８はサービス論理プログラム（SLP）を使用した個人エージェントを定義する1つの技術を図示する。
図９はネットワーク化IP（NIP）システムの1実施例と本発明の方法を図示する。
図１０は本発明の各種論理エンテティ間のメッセージの流れを図示する全体シーケンス図である。
図１１は「メールボックス状態報告」指令の動作を図示するシーケンス図である。
図１２はSCPがメールボックス状態に関する簡略情報を要求した時の「メールボックス状態問い合わせ」指令の動作を図示するシーケンス図である。
図１３はSCPがメールボックス状態に関する詳細情報を要求した時の「メールボックス状態問い合わせ」指令の動作を図示するシーケンス図である。
図１４は加入者がメールボックス状態に関する簡略情報を要求した時の「メールボックス状態問い合わせ」指令の動作を図示するシーケンス図である。
図１５は加入者がメールボックス状態に関する詳細情報を要求した時の「メールボックス状態問い合わせ」指令の動作を図示するシーケンス図である。
図１６はSCPがIPに変換用のメッセージを持って来るよう命令した時のシーケンス図を図示する。
図１７はSCPが変換IPにメッセージを変換するよう命令した時のシーケンス図を図示する。
図１８はSCPが配達IPに変換IPから変換したメッセージを持って来るよう命令した時のシーケンス図を図示する。
図１９はSCPがIPに変換メッセージを加入者に配達するよう命令した時のシーケンス図である。
図２０は本発明の動作時のSCPの有限ステートマシンを図示する。
図２１は本発明の動作時のIPの有限ステートマシンを図示する。
詳細な説明
本発明は、電子メール（e-mail）メッセージ形式、ファクシミリ形式又はSMS（ショート・メッセージ・サービス）形式のようなある媒体で受信したメッセージの、異なる形式でメッセージを受信したい加入者への変換と配達に関する一連の問題への解決方法を提供する。本願で開示し説明したIN概念への拡張は又他の電気通信方法にも使用可能であり、関連補助加入者サービスの提供も容易にする。
知能ネットワーク（IN）アーキテクチャ
知能ネットワークは、公衆回線電気通信ネットワーク（PSTN）又は公衆地上移動ネットワーク（PLMN）のようなネットワークへの新たな能力とサービスの導入を容易にする柔軟性を提供する電気通信ネットワーク・アーキテクチャである。このような新たな能力とサービスの例は、料金無料通話（「フリーフォーン」）、クレジットカード・サービスおよび仮想私用ネットワーク（VPN）を含む。
INは、アクセス、交換機技術およびネットワーク提供者とは独立に、ネットワーク・サービスを個人化する自由をサービス提供者とユーザに与える、未来のバンドルされていない（unbundled）ネットワークの夢を実現する。INの国際コンセンサスはITU-TS勧告Q.1200に記載されている。
INアーキテクチャの詳細は、図1に示したIN概念モデル（INCM）の逐語的説明も含む国際電気通信連合（ITU）勧告I.312/Q.1201に指定されている。ITUのIN概念モデルは呼の処理とサービスの提供に関係する各種のタスクとプロセスを４プレーン：サービス・プレーン１０１、グローバル機能プレーン１０２、分散機能プレーン１０３、及び物理プレーン１０４、で解析し体系化している。
これまで、INは、例えば料金無料発信（「フリーフォーン」）、クレジットカード発信、個人番号サービス、電話投票、等の以後番号サービスと呼ぶ1群のサービスに集中してきた。これら全てのサービスの鍵となる特徴は、これがアクセス・ノードのアクセス・ポートからバンドルされていない番号へのサービスを提供する点である。電気通信ネットワークの任意のノードは、サービス独立なプロトコル・インターフェースを介してサービス制御機能（SCF）からの制御下にある、サービス交換機能（SSF）及び／又は特殊リソース機能（SRF）の追加によりサービス・ノードとなり得る。SCFはサービス・データ機能（SDF）によりサポートされ、これはノードから物理的にバンドルされていない。
INの主要構成ブロックはSSF、SCF、SDF、SRFである。SRFは又以後論理知能周辺装置（論理IP）とも呼ばれる。これらの構成ブロックの各々は、必ずしもこうである必要はないが、論理的又はそれ以外に、電話ネットワークの他のエンテティと物理的に統合された、別の論理エンテティである。以下の望ましい実施例の説明では物理及び論理エンテティは互換的に参照されている。
INアーキテクチャは、電気通信サービス提供者と加入者に呼プロセスを処理できる能力を与える別々の、厳格に定めた段階に、基本呼プロセスを分割する。簡単な知能ネットワーク２００の成分は図2に示してある。知能ネットワークの標準アーキテクチャはINの各成分と共に個々の成分間のインターフェースを定義する。
INサービスに呼が行われると、呼は最初にサービス交換点（SSP）と呼ばれるネットワークの特殊ノードにルートされる。SSPが入呼をIN呼と認識した場合、呼の全てのこれ以上の処理は中断され、その間SSPはINシステムの他のノードであるサービス制御点（SCP）に、IN呼を受信したことを報告する。
SCPは「知能ネットワーク」に「知能」を与える。SCPはIN呼に発生する全てを制御し、全ての呼処理決定を行う。SCPが呼に対して実行すべき適切な動作を決定すると、SCPはSSPに必要な動作を実施するよう教示する。
サービス制御機能（SCF）はINサービスの論理を含み、そのサービスを起動した呼に関する決定を行なう完全な責任を負う。このサービス論理は任意の電気通信プラットフォーム（例えば、エリクソンのAXEプラットフォーム又はUNIX）で実行される。SCFを含むノード（すなわち、物理ハードウェア及びソフトウェア）はサービス制御点（SCP）２０１と呼ばれる。
各サービスに必要なデータ（例えば、加入者電話番号のリスト）はサービス・データ機能（SDF）により提供される。INアーキテクチャの１実装例では、サービスに必要なデータはSCF自体に記憶される。公式には、サービス関連データを記憶する機能は、必要に応じてSCFへデータを与えるSDFに割当てられる。標準のIN実装では、SDFはサイベースのような市販のデータベース・プログラムを実行するUNIXマシンでよい。SDFを含む物理ノードはサービス・データ点（SDP）２０２と呼ばれる。
交換機の通常の呼処理と監視機能は呼制御機能（CCF）により実施される。CCFは公式には標準INアーキテクチャの一部ではないが、CCFはINに呼に関する情報を提供し、またSSFにより受信した命令を実行する。
サービス交換機能（SSF）はSCFにより送信された命令を解釈し、実行すべき指令をCCFへ渡す。SSFもCCFから呼事象データ（例えば、加入者のオンフック／オフフック状態又は加入者線路のビジィであること）を受信し、データをSCFへ渡す。SSPを含む物理ノード（すなわち、交換機ハードウェアとソフトウェア）はサービス交換点（SSP）２０４と２０５と呼ばれる。
特殊リソース機能（SRF）はINサービスで使用するある種のリソース、例えば、DTMF（２重トーン複数周波数）数字受信、告知及び音声認識を提供する。ITUIN勧告では、SRFはSCFと直接通信する。INのその他の実装では、SRF機能はSSFと共存してもよい。この場合、SRFはSCFとは直接通信せず、SSFを介して通信する。SRFは図２には図示されていない。
サービス管理機能（SMF）２０７はINサービスの保守、例えばデータの追加又は削除又はサービスの設置又は改訂を管理する。サービス作成環境機能（SCEF）２０７はINサービスを開発し、試験し、SMFへ入力を可能とする。INの１実装例では、SMFとSCEFは１つに組合されてサービス管理アプリケーション・システム（SMAS）と名付けられる。SMASアプリケーションはTMOSファミリの一部であり、UNIXオペレーティング・システム下で実行する。これにより、グラフィカルなインターフェースを使用してサービスを設計でき、サービス・データの入力用に便利なフォームを提供する。
図２はSDP２０２とSSP２０４と２０５に接続された例示SCP201を図示する。SCPもSMF/SCEF２０７に接続される。SCP２０１へ至る又はそこからの全てのリンクは、図2では破線として図示され、音声リンクではないことを指示する。SDP２０２もSMF/SCEF２０７への非音声リンクにより接続される。SSP２０４は２つの局内交換機（LE）２２３と２２４と共に通過交換機（TE）２１１に接続される。通過交換機２１１は又２つの他の局内交換機２２１と２２２に接続される。SSP２０５は局内交換機２２５に接続される。局内交換機２２３と２２４は、図２で例示発呼加入者T-A２３１と共に例示終端加入者T-B２３２に接続されているのが図示されている。
上述した表記で、INの論理構成ブロックの各々も物理エンテティである場合、対応する物理ノードはサービス交換点（SSP）、サービス制御点（SCP）、サービス・データ点（SDP）、及び物理知能周辺装置（IP）と呼ばれる。上述したように、以下の説明では、IPという用語を使用して一般的に論理IPと共に物理IPの両方を指す。
ユーザ・エージェントは発呼又は被呼加入者番号によりSCFで識別され、サービス・ノードの装備トリガ点が叩かれた時に起動される。信号データと呼状態データはユーザ・エージェントにより処理可能である。現在の信号方式の制限に打ち勝つためSRFはユーザ又は互いに帯域内通信が可能である。
現在のIN標準は、加入者の訪問点とホーム位置は並置されるが、アクセス・ノードとサービス・ノードからは多分バンドルされていない。アクセス・ノードとサービス・ノード機能の分離はサービス導入コストを低減するが、これはアクセスポート・サービスと番号を基にしたサービスとの間で望ましくない相互作用を起こす可能性がある。サービス・ノードへのアクセス・ノードの強化は従ってサービス設計の柔軟性を与えるために必要である。
別の方式は、アクセス・ノードに2つの遠隔で交換可能な個人電気通信分類――呼を発生するためのサービス・ノードへの無条件ホットライン接続を与えるものと、呼を終了するためサービス・ノードへ無条件呼転送を与えるもの、を与えることである。コストが減少して容量が改良した場合、長期的には携帯電話ネットワークのように訪問及びホーム位置機能を分離することが必要であると考えられる。
INのユニークな特性の一つは、サービスがネットワーク・ノードに直接ではなく、そのサービス独立な構成ブロック（SIB）を基にしたINサービス・プラットフォーム上に実装される点である。SIBはSCPの一部である。図3はSIBの構造を図示する。各SIB３０１はプログラマから実装を隠蔽するサービス論理の基本論理要素である。既存のSIBが新たな要求を満足できない時、新たなSIBが定義される。図示するように、SIB３０１は論理入力３１１を受取り、論理出力３１２を発生し、SIBサポート・データ３２１を受取り、呼インスタンス・データ３２２を受取って発生する。
IN製品では、SIB３０１は信号情報の解析、接続トポロジの制御、ユーザとの相互作用、データの読取り書込み、呼データの収集と出力、等のような機能を実行する。その他のSIBはジャンプ、サブルーチンへの移動、ループ、移譲、等のような純粋な言語要素である。各SIB３０１はサービス・プラットフォームで利用可能である。サービス論理プログラム（SLP）はSIB３０１により構成され、その名前で参照する。サービス論理はサービス作成環境機能（SCEF）を使用して設計可能である。SIB３０１はシステム独立なアプリケーション・プログラム・インターフェース（API）を介してSCEFに利用可能となる。
各種のIN機能エンテティの物理装置又はエンテティへのマッピングは図4に図示され、添え字「F」は各種の機能エンテティを意味し、添え字「P」は物理エンテティを意味する。図4で、略語SMFはサービス管理機能を指し、略語CCFは呼制御機能を指す。
通過レベルでのサービス・ノードによるIN実装の例を図5に図示する。図5に図示したサービス・ノードは、PSTN又はISDNの局交換機又は公衆陸上移動ネットワーク（PLMN）システムのMSCのような任意のアクセス・ノードから到達可能である。サービス・ノードは個人電話と共にその他の番号を基にしたサービスの両方をサービス可能である。ユーザ識別認証情報はSRFへの帯域内で転送されるか又は信号方式の発呼及び被呼加入者番号に埋め込まれる。
個人エージェントは呼制御機能、CCF（すなわち、トリガ点データ）、サービス制御機能、SCF（すなわち、サービス論理）、及びサービス・データ機能（すなわち、サービス・データ）中に部品を有する。図5に図示したINプラットフォーム部品はアクセス・ノードに統合されるか、又は別のサービス・ノードに実装可能である。
サービス交換機能（SSF）の役割は、INサービスで呼が起動されたことを認識し、次いでSCFと通信して呼をどのように処理するかに関する命令を受け取ることである。SCFはINの知能が存在するところであり、何故ならこれは各種のサービスを実行するのに必要な論理を含んでいるからである。SDFは、データに特化した補助サービスに必要なデータ記憶容量を提供するデータベース・システムである。IPは、音声告知やダイアログ、2重音複数周波数受信（DTMF）や音声認識のようなユーザーとの相互作用するためのリソースを提供するネットワーク要素である。
INアプリケーション・プログラム・インターフェース（API）
図1に示したITUのIN概念モデルはまた各種のサービスを実装するための方法論も定義する。これは図6に示される。サービス又は機能６０１を実装するためには、サービス要求は最初に６０２のSIB要求に翻訳される。生成したSIB６０３は６０４で各種の機能エンテティ６０５にマップされる。機能エンテティ６０５は又６０６で1つ以上の物理エンテテイ６０７にマップされる。
全ての非IN標準での習慣とは異なり、INのサービス要求はネットワーク機能には直接に変換されないことに注意すべきである。代わりに、サービス要求はサービス・プラットフォーム要素（すなわち、SIB）に変換され、このサービス・プラットフォーム要素は又INの３段階モデルに従って実装されて、電気通信ネットワークの再使用可能な機能とプロトコル要素となる。
図1に示したITUのIN概念モデルに適合するアプリケーション・プログラム・インターフェース（API）の実装に向けられた少なくとも2つの可能な方式がある。1つの方式は、サービス論理を2つの部分：固定論理部分と柔軟論理部分とに分割する。次いで、SIBがリンクされて、固定論理によりサブルーチンと呼ばれる決定図を形成する。固定論理はCまたC++、等のような標準的なプログラム言語で表記可能で、コンパイルされて標準の実行環境にロードされる。対照的に、柔軟論理部分は交換可能なデータのみから構成される。
第2の方式は、所要の機能を達成するためSIBを互いに組合せることにより論理の全ての側面に対して完全な制御を与えるサービスAPIを定義することである。各SIBはこの方式ではその他のSIBとリンク可能である。あるSIBは電気通信機能を実行するが、他は論理中の要素をリンクするのみである。全ての論理は、どのSIBを使用するか、どのようにそれをリンクするか、機能を実行するため各SIBがどのデータを使用するか、を記述するデータとして表現される。全ての実装の詳細は従ってサービス・プログラマからは隠蔽される。これがエリクソンのIN製品で取り入れられた主要方式である。
APIの実装に向けた2つの方式は図7に図示される。SIBプラットフォーム方式は図7Aに示され、サービス論理実行環境（SLEE）方式は図7Bに示される。図7AのSIB方式は、柔軟なサービス・プロファイル（FSP）を形成するためサービス・プラットフォームで利用可能な基本SIB機能の組合せとして全てのサービス論理を表している。図７Bに示したSLEE方式は、C、C++、サービス論理プログラム（SLP）、等のようなプログラム言語で表現した固定論理へのサブルーチンとしてSIBを考えている。コンパイルしたコードはINAP（知能ネットワーク・アプリケーション部分）操作のような電気通信プラットフォーム・プリミティブやデータベース・プリミティブを使用する。
同じデータ表現が全ての論理とデータに使用される時、図8に示すように個人エージェントは柔軟サービス・プロファイル（FSP）により定義される。この方式は多数の利点、例えばサービスを混乱させることなく異なる論理要素をロードし作動させることを可能とする、そして個人エージェントの事故の場合、影響地域を事故機能を作動させた呼のみに限定する、を与える。
機能相互作用がINシステムの開発の主要な障害であった。この問題は、各機能が通常他の機能に依存していることから生じる。このような相互作用を解消する必要性があるが、未だ解決策は一致していない。実際には、新たな機能を導入する時、既存の機能実装はしばしば影響を受け、多数を再設計したり又は完全にブロック化しなければならない。この問題は2つの観点：ネットワーク中心の見方とINシステムのユーザ中心の見方、から取りかかることが出来る。
伝統的なネットワーク中心の見方は、既存のレパートリーに補助サービスを追加する際の他の技術の補足物としてINを見なす。機能相互作用は、現実的な別案からこの見方を阻止する障害であったし、かつあり続ける。新たな各補助サービスは固定サービス論理部分、及び多分柔軟論理部分から構成される。従って、個人化は、多数の予め定義された補助サービス又は機能を互いに組合せることにより達成可能なものに限定される。新たなサービスの追加は長くコストのかかる開発を必要とし、PSTN、PLMN、及びISDNでの前IN経験と異ならない。この見方の主要な問題は新たな機能の設計ではなく、新たな機能を他の予め存在する機能と統合化するタスクにある。
対照的に、INのユーザ中心の見方は、機能ではなくユーザに焦点を当てている。原理的には、個々のユーザのニーズはユニークであるものと仮定し、サービス提供者が全てのサービス論理を完全に制御している。FSP方式を適用し、結果として、機能を再使用するのではなくSIBを再使用することによりある範囲のユニークなサービス・プロファイルが作成可能である。このことは、機能相互作用は問題であることを停止することを意味する、なぜなら個々の機能は実装されていないからである。SIB間の相互作用がこの方式のサービス論理を構成する。
この方式のサービス・プロファイルの間の相互作用は、半呼モデルによる開放信号インターフェースを介して解決される。経済的に可能な方法で段階的開発INプラットフォームから完全な制御を提供可能とする前に、既存の補助サービスのいくつかを使用することが必要であると分かった。これは、未来のINプラットフォームの強化を必要とする相互作用問題を生じる近道であることを心にとめておくべきである。
ユーザ中心見方の主要な目的は、サービス独立とシステム独立と技術独立を全て達成するようにSIBを標準化することである。これが達成された時、SIBを基にしたサービス・プロファイルは、それが交換プロセッサであれ、独立のパーソナル・コンピュータであれ、又はワークステーションであれ任意の適合プラットフォーム上で実行可能である。全ての加入者に同じ機能を与える過去のパラダイムは、アクセスに係らず各個人加入者に対する機能透明性に置きかえられる。
IN信号
知能ネットワーク・アプリケーション部分（INAP）プロトコルがINシステムの信号に使用される。INAP信号プロトコルはヨーロッパ電気通信標準協会（ETSI）と国際電気通信ユニオン（ITU）の両方で標準化され、INAPをサポートするために使用される唯一のものではないが、一つのネットワーク・プロトコルであるCCITT信号システム第7号（CCS7）を含む。
現在指定されているような（すなわち、INCS-1標準）コアINAPの欠点一つは、SCFとIP間の通信可能性が音声のみに制限されていることである。E-mail、ファクシミリ、データ、等のような他の媒体はCS-1標準によってはサポートされない。従って、非呼関連及び非実時間呼関連サービスは現在のCS-1標準には含まれていない。
本発明の一部である、ネットワーク化IP（NIP）はINAPに対する拡張として特徴付けが出来、非音声媒体の処理とSCFとIPとの間の非呼関連通信の提供を含む。NIPによりSCFは音声メール、e-mail、SMSメッセージ、等のような全ての蓄積転送（すなわち、メッセージング）サービスの全体制御を可能とする。NIP実装に使用したプロトコルは以後NIP-INAPと呼ぶ。NIP-INAPはIN CS-１標準に対するエリクソン固有の拡張である。
ネットワーク化IP
図9は本発明のネットワーク化IP（NIP）の1実施例を示す。ネットワーク化IPシステムは、複数個の知能周辺装置（IP）９１１−９１４と通信可能なSCP９０１を含む。これらの論理IPの各々は、前述したようにIN用語でのSRFである。図解の簡便さのため、図4には4個のIP：受信IP、IPr、９１１；変換IP、IPc９１２；配達IP、IPd９１３、及び例示用の別のIP、IPo９１４、のみを図示してある。IP９１１−９１４は任意のプロトコル、例えばTCP/IP、X.25、等を使用して通信幹線９１０上で互いに通信する。
図9は又本発明の実施例の動作の概観を提供する。発生エンテティ９２０がオプションのインターフェース９２１を通して受信IPr９１１にメッセージを送信する時、IPr９１１は受信したメッセージを記憶し、矢印９３１で示すようにSCP９０１に通知する。SCPはまた９３２で通知を確認する。
本発明の別の実施例では、SCP９０１は９３３に示すように加入者のメールボックスの状態についてIPr９１１に問合せし、矢印９３４で指示するようにIPr９１１から回答を受信する。SCP９０１が加入者９２２の配達選択の前知識を有している場合、それは変換IPc９１２に指示して９４１に示すように受信IPr９１１からメッセージを持って来させる。変換IPc９１２は次いで幹線９１０を通して受取人IPr９１１と通信して記憶メッセージを検索する。変換IPcは９４２のフェッチ指令の実行をSCP９０１へ確認する。
SCP９０１は次いで変換IPcに９４３で変換命令を発生する。変換IP９１２は、加入者の選択を基に、受信したモードから加入者９２２がメッセージを配達されたいモードへメッセージを変換する。変換が完了した時、変換IPc９１２は９４２に示すようにSCP９０１へ通知する。
メッセージの媒体が変換されたことを通知されると、SCPは次いで配達IPd９１３に９５１に示すように変換IPc９１２から変換済みメッセージを持って来るよう命令する。配達IP９１３は幹線９１０を通して変換IPc９１２からメッセージを検索し、９５２に示すようにSCP９０１へプロセスの完了を知らせる。
次いでSCP９０１は配達IPd９１３に、９５３に示すように加入者９２２にメッセージを配達するよう命令する。加入者が活動していてアクセス可能な場合、配達IP、IPd９１３は９２６に示すようにメッセージを配達する。メッセージの配達も９５２に示すようにSCP９０１に確認する。
図１０は本発明の各種の論理エンテティ間のメッセージの流れを図示する全体シーケンス図である。図１０に示すように、変換プロセスは３つのフェーズを含む。第１フェーズでは、受取人IP、IPr９１１はSCPにメッセージの受取を報告する。第２フェーズでは、SCPは変換IP、IPc９１２に命令して、受取人IP、IPr９１１からメッセージを検索し、ある媒体から他へメッセージを変換させる。第３フェーズでは、SCPは配達IP、IPd９１３に命令して、変換IP、IPc９１２から変換済みメッセージを検索し、これを加入者に配達させる。
SCPと各種のIP９１１−９１３との間の通信は図１０でトランザクション機能アプリケーション部分（Transaction Capabilities Application Part, TCAP）記法を用いて示され、メッセージ型式は矢印の下に、TCAPメッセージの部品とパラメータは各名印の上に示されている。従って、第１フェーズでは、メッセージを受信すると、IPr９１１は１００１の「メールボックス状態報告」指令を使用してSCP９０１に通知する。これは１００２でIPr９１１へSCPにより確認される。
第２フェーズ、メッセージ変換フェーズでは、SCP９０１は１００３で変換IP、IPc９１２へ「フェッチ」指令を発行する。変換IP、IPc９１２は、各種IPを接続するネットワーク上で許されている任意のプロトコル、例えばTCP/IP、X.25、等を使用することにより１００４と１００５に示すようにIPr９１１からメッセージを検索する。IPc９１２は１００６でメッセージ検索プロセスの完了をSCP９０１に信号する。次いでSCPは１００７でIPc９１２に「変換」指令を発行する。IPcは１００８でSCPへの変換プロセスの完了を確認し、この時SCP９０１は１００９に示すようにIPc９１２とのダイアログを閉じる。
第３フェーズでは、SCPは１０１０で配達IP、IPd９１３に「フェッチ」指令を発行し、この時１０１１と１０１２に示すようにIPネットワーク上で正当と考えられる任意のプロトコルを使用して配達IPはIPc９１２から変換済みメッセージを検索する。１０１３に示すように変換済メッセージがIPcから取って来られると、IPdはSCPに知らせる。加入者との通信を設定する時又はその前に、SCPは１０１４に示すように配達IP、IPdに「メッセージ送信」指令を発行する。IPdは加入者にメッセージを配達し、１０１５でSCPにこの事を確認し、この時SCPは１０１６に示すようにIPdとのダイアログを閉じる。
IN加入者はe-mail、ファクシミリ・メール、SMS、音声メール、等のようないくつかの蓄積転送サービスに加入し、これらの各種のメッセージ型式の配達を調整させてもよい。加入した異なるサービスに関連する各種のメッセージは、INネットワークの異なる物理又は論理IPに通常記憶されている。現在、加入者指定の変換及び配達選択を基にして、異なるノードに記憶された異なる型式のメッセージを分散的に検索し、変換し、配達することが出来るような変換解決方法は一般的には利用可能ではない。
本発明は、ある蓄積転送媒体から他のものへメッセージを変換し、従って変換及び未変換メッセージを異なるIP間で移動する解決方法を提供し、従って、加入者は自分のメッセージの一部又は全てを１つ以上の望ましい媒体で配達するよう選択可能とする。
本発明の１実施例では、いくつかの新たなプロシデュアがINAPに導入されて、ある蓄積転送媒体から他のものへのメッセージの変換の実施を助ける。このような新たなプロシデュアは：同じネットワーク上の他のIPからメッセージを取って来るようSCFにIPに命令させる「フェッチ」指令；ある媒体から他のものへ変換させるようSCFにIPに命令させる「変換」指令；識別メッセージ（本明細書では、変換済みメッセージ）を指定の目的地へ配達させるようSCFにIPに命令させる「メッセージ送信」；を含む。
メールボックスはいくつかの異なる媒体、例えば、音声メール、ファクシミリ・メール、e-mail、SMS、等に存在可能である。本開示では、各媒体とその関連メールボックスは、論理IPとして引用される。加入者がメールボックスで受信したメッセージを制御するため、かつ加入者のメールボックスの状態が変化した時にSCP又は加入者への通知を容易にするため、加入者のメールボックスの状態に関して知らされるのが通常SCPには有用である。
現在、異なる物理ノードに実装された統合メッセージ・サービスは容易に提供できない。本発明の実施例は、統合化したメール解決法を実装するプロトコルを定義する事によりINアーキテクチャを基にしたネットワーク解決法を提供する。
本発明の他の機能がSCPに加入者のメールボックスの状態に関して更新される。NIP-INAPにはこの目的のため新たなプロシデュア：特定のメールボックスの状態が変化した時にIPがSCFに知らせることを可能とする「メールボックス状態報告」指令；特定の媒体の特定の加入者メールボックスの状態に関してSCPにIPに問合せさせる「メールボックス状態問合せ」指令；が導入された。
INAPプロシデュアへの拡張
次に、本発明の望ましい実施例の実装のためNIP-INAPに導入された各種の新たなプロシデュアの詳細な動作を考える。SCPがIPに命令してある形式から他のものへメッセージを変換する前に、IPによりメッセージを受信した時にSCPの通知を容易にし、かつ加入者のメールボックスの状態を肯定的に決定可能とするプロシデュアが必要である。
「メールボックス状態報告」メッセージ
加入者のメールボックス状態の変化のIPによる自動報告は、「メールボックス状態報告」指令を使用することにより実装される。図１１に示すように、状態の変化がSCPにより開始されたものではない又は制御されていない限り、メールボックス状態の何らかの変化時に受取IP、IPr９１１からSCP９０１へメールボックス状態報告が送信される。しかしながら、メッセージがメールボックスに預けられた時（すなわち、ある媒体でメッセージを受取るよう指定されたIPにより受信された）、SCPが制御している場合でも受信IPは「メールボックス状態報告」メッセージを発生する。
受信IP、IPr９１１によるこの通知の発生時に、SCP９０１とIPr９１１との間に進行中の進行中のダイアログがあるかもしれないし、ないかもしれないことに注意すべきである。IPr９１１がこのメッセージをSCPへ発行するためには、加入者のメールボックスの状態が変化しなければならない。SCP９０１によるこの指令の受信後、さらなる動作はSCPの自由裁量下にある。必要に応じて、以下に説明する「メールボックス状態問合せ」を使用して各種のメッセージの状態に関する詳細な情報をSCPは得る事が出来る。
「メールボックス状態問合せ」メッセージ
メールボックス状態の変化時にIPにより自発的に発生される、「メールボックス状態報告」メッセージと対照的に、「メールボックス状態問合せ」メッセージは、SCPによる肯定動作によってのみ又は自分のメールボックスの状態に関する肯定的な加入者問合せ時にトリガされる。図１２及び図１３は、SCPが加入者のメールボックスの状態に関してIPに問合せした時のシーケンス図を図示する。前述した「メールボックス状態報告」メッセージを使用してIPr９１１がメールボックス状態の変化をSCP９０１に報告した場合、及びSCP９０１が加入者のメールボックスに関するより詳細な情報を得たい場合、図１２及び図１３に示すように２つの可能な結果がある。
SCP９０１による加入者のメールボックスの状態の問合せは、本明細書で簡略情報の要請又は詳細情報の要請と呼ぶ２つの形式の内のどちらかである。加入者のメールボックス状態に関する簡略情報の例示要請は、メールボックス中の新たなメッセージの全数に関する情報の要請である。加入者のメールボックス状態に関する詳細情報の例示要請は、メールボックス中の各メッセージの日付、時間及び長さの要請である。
１２０１に示すように、SCP９０１がメールボックス状態に関する簡略情報をIPr９１１に要求した場合、IPr９１１は結果の分割なしに１２０２に示すようにSCP９０１へ所要の結果を回答できる。同様に、SCP９０１がメールボックス状態に関する詳細情報をIPr９１１に要求した場合、詳細情報が利用不能な場合又は分割が不要又は望ましくない場合、（前と同じく）１２０２に示すようにIPr９１１はSCP９０１へ単一の（すなわち、分割しない）メッセージで結果を返す。
反対に、SCP９０１がメールボックス状態に関する詳細情報をIPr９１１に要求した場合でかつ分割が必要な場合、かつそのような情報が利用可能な場合、図１３に示すようにIPr９１１はSCP９０１へ複数分割で情報を送信する。このプロセスは１３０１でSCPがIPr９１１の詳細問合せを行なうことから開始する。これに応答して、IPr９１１は１３０２でSCPへ結果の一部を送信し、（オプションとして）さらに情報が利用不能のまま残っていることを指示する。これを受けてSCPは１３０３で残りの情報を要求する。IPrは１３０４で他の標準戻り結果分割を与え、（オプションとして）さらに情報が利用可能に残っていることを指示する。
このプロセスは、IPrが１３０６で示すようにSCPへ戻り結果成分を返し、メールボックス状態に関してこれ以上の情報が利用可能ではないことを示すまで、１３０５に示すようにIPrから更なる情報を要求するSCPにより連続的に繰返される。SCFがIPrにより返された結果の各種の分割を得て、組立て、解析した時、この部分に関するこれ以上の活動は自由裁量である。
本発明の他の実施例では、SCPは特定の受取人にメッセージを送信してもよいし、又はメールボックスに関する「メールボックス状態問合せ」指令の結果をメールボックス所有者に通知してもよい。
「メールボックス状態問合せ」指令は、自分のメールボックスの状態に関して問合せした加入者にサービスするためにも使用可能である。これは、戻り結果が分割されていない時は図１４に、戻り結果が分割される時は図１５に図示されている。
図１４に図示するように、ユーザが自分のメールボックスの状態を知りたい時、SCPは１４０１に示すようにIPr９１１に「メールボックス状態問合せ」指令を発行し、適当に簡略又は詳細情報を要求する。１４０１で簡略情報のみを要求した場合、詳細情報を要求したが利用できない場合又は詳細情報を要求したが分割が必要ない場合、IPr９１１は結果の分割なしに１４０２に示すようにSCPへ問合せの結果を返す。以後、これ以上の活動はSCP９０１の自由裁量である。
図１５はユーザが自分のメールボックスの状態に関して詳細な問合せをした時のシーケンス図を図示する。問合せを受取ると、SCP９０１は１５０１に示すように「メールボックス状態問合せ」指令をIPr９１１へ発行し、特定のメールボックスに関する詳細情報を要求する。IPr９１１は返すべき結果を分割し、１５０２に示すように第１区分をSCPへ返信し、更なる情報が利用可能で残っていることを指示する。これに応答して、SCPは「メールボックス状態問合せ」指令を１５０３で２回目に起動し、残りの情報のいくつか又は一部を要求する。IPr９１１は、１５０４に示すようにSCPへ第２戻り結果成分を返すことにより応答し、さらに情報が利用可能であることを指示する。
図１３に示したシーケンス図の説明と関連して前述したように、IPr９１１が１５０６で示すように戻り結果成分を送信し、これ以上の情報が利用可能ではないことを指示するまで、１５０５に示すようにSCP９０１はIPr９１１へ「メールボックス状態問合せ」指令を繰返し発行する。次いでSCPは分割された戻り成分を組立て、解析し、自由裁量でさらなる活動を実行する。
「メールボックス状態報告」と「メールボックス状態問合せ」指令は、論理的に異なるIPに位置しているにも係らず、自分のメールボックスの状態が変化した時に加入者に警告を開始し、かつ加入者の各種の型式のメールボックスの全てを中央集権的に制御することを可能とする。
次にIN制御媒体変換サービスを更に詳細に考える。異なるIPに位置する異なる媒体に記憶されたメッセージの相互変換は、加入者と電気通信サービス提供者から長く望まれていた。上述したように、異なるIPに位置し、異なる媒体に記憶されたメッセージの相互変換を可能とするプロシデュアは現在定義されたINアーキテクチャには存在しない。
本発明の実施例の動作は、新たなプロシデュア：SCPがIPに命令して他のIPからメッセージを持って来ることを可能とする「フェッチ」指令：SCPがIPに命令してある媒体から他のものへメッセージを変換可能とする「変換」指令；SCPがIPに命令して特定の変換済みメッセージを識別した目的地へ送信可能とする「メッセージ送信」指令；を導入することにより、メッセージと異なるIPに記憶された異なる媒体の相互変換を可能とする。
以下で説明するシーケンス図では、変換IP、IPcと呼ばれる特定のIPを使用して異なる媒体」に記憶したメッセージの相互変換を行なう。しかしながら、実際の変換（又はその他の類似SRF機能）は変換IP.所要の媒体をサポートする任意のIPで、又は必要な処理パワーとシステム・リソースを含むその他のIPのどちらかで実行可能であることを強調しておかなければならない。さらに、前述したように、SRF（論理IP）のようなINの構成ブロックの各々は、必ずしもその必要はないが、論理的又はそれ以外で、電話ネットワークのその他のエンテティと物理的に統合された別個の論理エンテティである。
「フェッチ」指令
図１６は、SCPがIPに命令して、変換用のメッセージを取って来させた時のシーケンス図を示す。SCP９０１は次いで変換IP、IPc９１２に命令して、幹線ネットワークを使用して他のIPr９１１から変換用のメッセージを取って来させる。メッセージが加入者のメールボックスに預けられ、受信IPr９１１からの「メールボックス状態報告」メッセージによりSCPがそのように知らされた時、SCPは１６０１に示すように変換IPcへ「フェッチ」命令を発行する。「フェッチ」指令を受信すると、変換IPは１６０２と１６０３に示すようにNIP幹線を通して受取人IP、IPrからメッセージを取って来る。メッセージの検索が成功裏に完了すると、IPcは１６０４に示すようにこれをSCPに信号する。
「変換」指令
図１７は、SCPが変換IPc９１２に命令してメッセージを変換する時のシーケンス図を示す。IPc９１２へ「変換」指令を発行するSCPにより１７０１に示すようにプロセスが開始する。SCPに記憶した選択を基に、又はSCPにより処理される加入者作動の変換モード・ダイアログを基に、IPc９１２は受信媒体から所要の媒体へメッセージを変換する。変換が完了した後、IPcは１７０２に示すようにSCPに通知し、この時SCPは１７０３で指示するように変換IPとのダイアログを閉じる。
変換が完了した後、SCP９０１は次いで配達IPd９１３に命令して変換IPc９１２から変換済みメッセージを持って来させる。図１８に示すように、１８０１でIPdへ「フェッチ」指令を発行するSCFからプロセスは開始し、これでIPdは１８０２と１８０３に指示するように幹線を介してIPcから変換済みメッセージを持って来る。メッセージが完全に検索されるとIPdは１８０４に示すようにSCPに通知する。
「メッセージ送信」指令
最後に、図１９に示すように、SCP９０１はIPdに命令して、変換済みメッセージを加入者に配達する。このフェーズは１９０１に示すようにIPdに「メッセージ送信」指令を発行するSCPから開始し、これでIPdは変換済みメッセージを加入者に配達し、１９０２に示すようにSCP９０１にこれを確認する。このプロセスは、１９０３に示すようにIPdとのダイアログを閉じるSCPで終了する。
上述のシステムと方法により、SCPはある媒体で受信したメッセージの他の媒体への変換を制御し、変換済みメッセージの配達を管理可能となる。これは、メッセージを配達すべき媒体に関する各加入者の選択を中央位置で記憶することを可能とする。本発明の実施例の動作の別な利点は、加入者が各メッセージの配達媒体を相互的に記述可能とできる点、又は以前の媒体変換順序の結果を修正できる点である。
SCP及びIPの有限ステートマシン
図２０と図２１は本発明の実施例のSCP９０１と各種のIP９１１−９１４の有限ステートマシンを図示する。図２０と図２１では、マシンの状態は楕円で記号化され、状態転移を生じさせる事象は連続矢印で描かれている。機能は破線四角形内に記述され、機能により命令された活動は破線矢印で指示される。
図２０はSCPの有限ステートマシンを図示する。図から分かるように、SCPは３つの状態：アイドル状態２００１、活動状態２００２、変換時フェッチ状態２００３、を有する。２０１０に示すように、IPへの「フェッチ」指令の発行時にSCPはアイドル状態２００１から変換時フェッチ状態２００３に移行する。IPによりダイアログがアボートされた場合、又は動作が時間切れとなった場合２０１１に示すように逆の状態転移が発生する。
２０１２に示すようにフェッチの結果をIPから受信した時にSCPは変換時フェッチ状態２００３から活動状態２００２に移行する。IPcへの「変換」メッセージの送信、IPcから変換結果の受信、IPdへの「メッセージ送信」配達指令の送信、及びその完了の通知時には、２０１４に示すように何らの状態転移なしにSCPは活動状態２００２をループする（すなわち、留まる）。不適当な成分の存在のためダイアログが拒否された場合、どちら側からかダイアログがアボートされた場合又は操作が時間切れとなった場合、SCPとIPとの間のダイアログの正常終了時に２０１３に示すようにSCPは活動状態２００２からアイドル状態２００１へ移行する。
図２１はIP側からの有限ステートマシンを図示する。IPは３つの主要状態：アイドル状態２１０１、活動状態２１０２、変換時フェッチ状態２１０３、を有する。更に２つの擬似状態：２１２１に示すデータ通信幹線を通したメッセージの検索、メッセージ変換状態２１２２、もある。
図２１に示すように、２１１０に示すようにSCP９０１からの「フェッチ」指令を受信時にIPはアイドル状態２１０１から変換時フェッチ状態２１０３へ移行する。２１１１に示すように、IPがダイアログをアボートした場合に反対の状態転移が発生する。
２１１２に示すように、SCP９０１へ送信された「フェッチ」指令の結果でIPは変換時フェッチ状態２１０３から活動状態２１０２へ移行する。IPが「フェッチ」指令を受信した場合、アイドル状態２１０１から変換時フェッチ状態２１０３への転移には、２１１５に示すようなデータ通信幹線を通したメッセージの検索と２１１６に示すようなタスクの完了の確認がさらに伴う。
SCP９０１から又はSCPへの「メッセージ送信」指令の受信又は確認時にIPは活動状態２１０２でループする（すなわち、留まる）。SCPからの「変換」指令の受信時とSCPへの変換結果の回答時もIPは活動状態２１０２に留まる。
活動状態に留まることに加えて、IPがSCPから「変換」指令を受信する時は、２１１７に示すようにメッセージ変換状態２１２２への擬似状態転移も行なう。メッセージ変換が完了すると、擬似状態転移は終了し、IPはメッセージ変換状態２１２２から活動状態２１０２へ復帰する。
SCPによるダイアログの正常終了時、又はSCPによる提示結果の拒否時、又はSCPとIPとの間のどちら側からのダイアログのアボート時に、IPは活動状態２１０２からアイドル状態２１０１へ転移する。
本発明の方法と装置の望ましい実施例を添付図面に図示し、以上の詳細な説明で説明してきたが、本発明は開示した実施例に限定される事なく、以下の請求の範囲に記述し限定される本発明の要旨から逸脱することなく多数の再配置、修正や置換えが可能であることを理解すべきである。
【図１】
0004138010.tif 000002
【図２】
0004138010.tif 000003
【図３】
0004138010.tif 000004
【図４】
0004138010.tif 000005
【図５】
0004138010.tif 000006
【図６】
0004138010.tif 000007
【図７Ａ】
0004138010.tif 000008
【図７Ｂ】
0004138010.tif 000009
【図８】
0004138010.tif 000010
【図９】
0004138010.tif 000011
【図１０】
0004138010.tif 000012
【図１１】
0004138010.tif 000013
【図１２】
0004138010.tif 000014
【図１３】
0004138010.tif 000015
【図１４】
0004138010.tif 000016
【図１５】
0004138010.tif 000017
【図１６】
0004138010.tif 000018
【図１７】
0004138010.tif 000019
【図１８】
0004138010.tif 000020
【図１９】
0004138010.tif 000021
【図２０】
0004138010.tif 000022
【図２１】
0004138010.tif 000023