(57)【要約】      （修正有）【課題】ユーザに納入後の、装置の改善をフレキシブルに供給する方法。【解決手段】分散型システム１は、記録装置１１０などが、装置中心サービス１４０に加入しそのサービスを動作させることを可能にする。装置モデル・エージェント１２０は、装置１１０が、サービス提供者のサービス・ホスト３１０と対話して、供給品保守、ユーザ・ヘルプ、およびサービス加入を自動化することを可能にする。装置モデル・エージェント１２０は、装置１１０に組み込むあるいは装置１１０に接続されたアドオン構成要素に配置、個別の装置によってプロキシ２２０として実行されてもよい。装置モデル・エージェント１２０は、装置１１０が利用可能なサービス１４０の実行時環境を、共通インタフェースを介して共通構造と共に提供する。【選択図】図５
2004220556.tif 000002
【特許請求の範囲】
【請求項１】
サービス・ホストから少なくとも１つの使用可能なサービスを提供することができ、少なくとも１つの装置固有の提供者アプリケーション・プログラム・インタフェースを含み、かつ、装置固有のステータス情報を有する少なくとも１つの装置と、
少なくとも１つのサービス層と、
少なくとも１つのサービスが実際に動作する少なくとも１つのサービス環境と、少なくとも１つの共通情報管理アプリケーション・プログラム・インタフェースと、少なくとも１つの装置モデル・エージェントと、少なくとも１つの共通提供者・アプリケーション・プログラム・インタフェースとを含む装置独立ランタイム環境と、
を含む分散システム・アーキテクチャ。
【請求項２】
請求項１記載の分散システム・アーキテクチャであって、
少なくとも１つのサービス層が、少なくとも１つの装置に利用可能にされた少なくとも１つのサービスを含む分散システム・アーキテクチャ。
【請求項３】
請求項１記載の分散システム・アーキテクチャであって、
少なくとも１つの装置独立ランタイム環境が、記録装置内に配置されており、記録装置が、少なくとも１つの装置のうちの１つである分散システム・アーキテクチャ。
【請求項４】
請求項１記載の分散システム・アーキテクチャであって、
少なくとも１つの装置独立ランタイム環境が、記録装置に接続されたサーバ内に配置され、記録装置が、少なくとも１つの装置のうちの１つである分散システム・アーキテクチャ。
【請求項５】
請求項４記載の分散システム・アーキテクチャであって、
サーバが、主な機能が装置独立ランタイム環境と関連付けられていないが、装置独立ランタイム環境をホストするアプリケーションをホストする分散システム・アーキテクチャ。
【請求項６】
請求項１記載の分散システム・アーキテクチャであって、
少なくとも１つのサービス環境とサービス層が、記録装置に接続されたサーバ上にあり、記録装置が、少なくとも１つの装置のうちの１つであり、サーバが、主な機能がサービス層および環境と関連付けられていないがそのサービス層および環境をホストするアプリケーションをホストする分散システム・アーキテクチャ。
【請求項７】
請求項１記載の分散システム・アーキテクチャであって、
装置モデル・エージェント、少なくとも１つのサービス環境、およびサービス層が、記録装置に接続されたサーバ上にあり、記録装置が、少なくとも１つの装置のうちの１つであり、サーバが、主な機能が装置モデル・エージェント、サービス層およびサービス環境と関連付けられていないが、その装置モデル・エージェント、サービス層およびサービス環境をホストするアプリケーションをホストする分散システム・アーキテクチャ。
【請求項８】
装置独立サービスを提供する方法が、
共通の装置インタフェースを提供する段階と、
共通の情報モデルを提供する段階と、
共通の装置インタフェースおよび情報モデルを使用して、装置内のサービスを統合する段階と、
装置固有の違いを共通の装置インタフェースの後ろに隠す段階と、
を含む方法。
【請求項９】
請求項８記載の方法であって、
共通の装置インタフェースを提供する段階が、それぞれのサービスの所定の拡張機能を備えた分散モデル・タスクフォース共通情報モデルを使用する段階を含む方法。
【請求項１０】
請求項９記載の方法であって、
共通情報モデルを提供する段階が、装置とそれぞれのサービス間の互換性を高める所定の拡張機能を備えた分散モデル・タスクフォース共通情報モデルに基づく段階を含む方法。
【請求項１１】
プラットフォームを提供する方法であって、
アクセス・モジュールを提供する段階と、
サービスが、アクセス・モジュールによって装置の組み込まれた計算能力、データ、および機能を使用できるようにする段階と、
アクセス・モジュールを共通の方式で配置する段階と、
を含む方法。
【請求項１２】
請求項１１に記載の方法であって
新しく配置されたサービスを、ホスティング・プラットフォーム用のソフトウェア・リリースと非同期して受け入れる段階をさらに含む方法。
【請求項１３】
請求項１１に記載の方法であって、
サービス・プラットフォームをホスト・プラットフォームに組み込む段階をさらに含む方法。
【請求項１４】
請求項１１に記載の方法であって、
アドオン構成要素内のサービス・プラットフォームをホスト装置に配置する段階をさらに含む方法。
【請求項１５】
請求項１４に記載の方法であって、
少なくとも２つのインタフェースを介してアドオン構成要素をホスト装置に接続する段階をさらに含む方法。
【請求項１６】
請求項１４に記載の方法であって、
アドオン構成要素をネットワークに接続し、それによりホスト装置に装置サービスに関与する機能を提供する段階をさらに含む方法。
【請求項１７】
請求項１４に記載の方法であって、
アドオン構成要素を介してホスト装置のすべてのネットワーク接続を提供する段階をさらに含む方法。
【請求項１８】
請求項１１に記載の方法であって、
ユーザ環境に配置された少なくとも１つのアプリケーションを、少なくとも１つの装置とサービス・ホストの間のサービス・プロキシとして使用する段階をさらに含む方法。
【請求項１９】
請求項１８に記載の方法であって、
使用する段階が、少なくとも装置からサービス・プロキシにデータを第１のプロトコルで送り、サービス・プロキシからサービス・ホストにデータを第２のプロトコルで送る段階を含む方法。
【請求項２０】
請求項１９に記載の方法であって、
第１のプロトコルが、ＳＮＭＰである方法。
【請求項２１】
請求項１９に記載の方法であって、
第１のプロトコルが、無線通信プロトコルである方法。
【請求項２２】
請求項１９に記載の方法であって、
装置ベースのサービスの対応システムを使用して、サービス・ホストにおける装置変動を管理する段階をさらに含む方法。
【請求項２３】
請求項１９に記載の方法であって、
ユーザ環境にあるサーバにサービス管理を統合する段階をさらに含む方法。
【請求項２４】
請求項１９に記載の方法であって、
ユーザがサービスを管理することができるＵＩを提供する段階をさらに含む方法。
【請求項２５】
サービスが、装置にアクセスしている間に機能を提供するように意図された装置と実質的に独立にサービスが動作できる環境を提供する装置モデル・エージェントであって、少なくとも１つのサービス・ホストと通信して、自動化された供給物の保守とサービスの加入および配置を可能にする装置モデル・エージェント。
【発明の詳細な説明】
【技術分野】
【０００１】
実施形態は、電子式複写記録装置（marking device）、ファクシミリ装置、走査装置、多機能装置などに関する。詳細には、実施形態は、係る装置がユーザに提供することができるサービスの実施および配布に関する。
【背景技術】
【０００２】
本出願は、２００２年１０月１６日に出願された米国暫定特許出願番号６０／３１９，６２２、ならびに２００２年１０月１７日に出願された６０／３１９，６２３、６０／３１９，６２４、６０／３１９，６２４、６０／３１９，６２５に対して優先権を主張する。
【０００３】
記録装置や他の業務装置の設置は、その装置のライフサイクルの大部分において第１歩に過ぎない。ほとんどの装置は、製品所有者（ユーザ）、製品の製造業者、および／またはサードパーティ供給業者の間の継続的な業務プロセスに関わらされる。記録装置を製造する会社は、一般に、ユーザの文書をサポートする製品とサービスを有し、ユーザが、ずっとその提供物を使用しその提供物に満足し続けることを望む。この販売後の期間は、製造業者とユーザの間に互いに利益となる長期間に渡る強い関係を築く機会を提供する。この販売後の関係は、装置がユーザのために何をするかというだけでなく、装置がそれをどのように行い、製造業者が装置をどのようにサポートし、製造業者がユーザをどのように扱い、装置を所有し使用することが全体としていかに容易かということにより定義することができる。これを理解することにより、実施形態は、ユーザが使用している装置をサポートするサービスを受けるためにユーザの補足的なニーズに応え、すなわち、様々な実施形態において、販売後のライフサイクル、破損／修復のニーズ、および統合的な業務プロセスが対処される。そのようなプロセスは、破損／修復サービス（修理）から、消耗品および供給品の継続的な供給、製品アップグレード、拡張、ならびにソリューションや他の提供物への統合まである。従来、このような販売後のプロセスは、本質的に手作業であり、装置の所有者／ユーザに、必要なときに製造業者とサプライヤに限られた情報を中継する際に積極的な役割を演じることを要求していた。
【０００４】
多くの電子式複写記録装置、ファクシミリ装置、走査装置、多機能装置などは、ユーザが使い方または回避の仕方を覚えなければならないプロセスを支援するサービスを提供する。また、装置によっては、ユーザをいらいらさせるメータ読取りや他の種類の保守を必要とするものがある。メータ読み取りの場合、ユーザは、メータを毎月読み取り、その結果を、例えばファックスや電話で供給業者に伝えなければならない場合がある。さらに、ユーザは、用紙、トナー、他の材料の供給品を手作業で確認し、新しい材料を注文しなければならない。装置によって提供されるサービスの数は、ユーザを当惑させ、それにより、ユーザは、装置が複雑すぎて覚えることができないと考えることがある。さらに、ダウンタイムやその他の不都合を回避するために、ユーザは、修理の電話をし、サービスの到着を待って自分の装置を修理するよりも自分自身で小さな修理を行いたいことがある。
【０００５】
モデムの出現によって、ユーザまたはユーザ・サイトにあるハイエンド製品が、この対話モデルを変更する電話線によって製造業者に接続された。広く普及したインターネット接続の到来とネットワーク接続製品の急増により、装置を販売後の業務プロセスと統合するフレキシブルでかつ強力な手法を提供する新しい機会が現れた。ネットワーク接続は、電話線接続の欠点のうちのいくつかを解決しているが、今まで示されたシステムには、そのような初期のシステムのために開発された対話モデルと関連した多数の制限がまだある。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
現行のシステムの欠点は、通信方法とシステム・アーキテクチャのと結びつきが厳格であること、配置と統合戦略が画一的であること、また既に配置済みの装置に一般にサポートがないことがある。既に配置された装置のサポートを提供するシステムは、一般に、既に配置済みの装置と新しい装置との扱い方の間に一貫性がない。さらに、このシステムは、一般に、機能、プロセスおよびワークフローの迅速なアップグレード、拡張、カスタマイズおよび進化の機能を含んでおらず、基本的な業務プロセスに制限されることが多く、外部サービスとソリューションＡＰＩを安定的に提供することができない。一般に、またほとんど全体的に、システムは、装置を、使用可能にされたサービスへの積極的な関与物ではなく単純な情報レポジトリレポジトリとして扱う。装置は、競争力を維持するためにその主要な機能セットを強化させ続けなければならない。例えば、ドキュメント・システムでは、装置の競争力を高めるために強化される特性は、一般に、速度、供給速度、画像品質、および文書ワークフローである。しかしながら、装置とユーザと供給業者間の販売後の対話が増えており、製品をソリューションとサービスに組み込みまたその逆方向に組み込む能力が、市場において装置を差別化するポイントになってきている。近い将来、装置の成功と価値は、販売後ライフサイクルに積極的に関与する装置の能力、ソリューション提供物とシームレスに一体化する能力、およびユーザのニーズと要件に基づいてカスタマイズし拡張する能力で計られるようになる可能性が高い。そのような装置の能力の成果は改善され、ユーザに使い易くなり、製造業者によるサポートの有効性が高まり、ユーザの全体的な満足度が高まる。
【０００７】
ここ数年間の業界の一般的傾向は、リモート・サービスを提供してユーザの満足度を高めかつ操作費用を削減することによって、記録装置に組み込まれた高い計算性能と高い接続性を利用することであった。接続されたインテリジェント製品のこの傾向は、サーバやその他のミッション・クリティカルな情報技術（ＩＴ）関連のハードウェア上のリモート・サービスの実現から始まり、記録装置を含む様々な他の業界に広まってきた。そのようなリモート・サービスは、製造業者とユーザの両方にとって価値ある企画を提供する。適切に実現されたとき、そのようなサービスは、製造業者にとって大きなコスト削減を可能にし、さらにユーザにとって販売後のより良い経験を可能にする。
【０００８】
この移行は、同時に起こるいくつかの要因およびニーズによって促進される。競争圧力と改善された内部業務プロセスのニーズによって、現地にある製品との新しい対話方法が必要になり、またサービスとサポートの責任を持つ場所の移動が必要になる。同様に、製造業者とユーザは、新しい機能／サービスを構成し追加して、目前にある問題を迅速に解決し新しい機能を迅速に配置できることを好む。このプロセスの単純化と高速化によって、寿命が延び、配置された装置の価値が高まり、ユーザの満足と生産性が維持される。製造業者は、そのような機能を新しい装置と既に配置済みの装置に提供できなければならないが、製造業者は、全ての種類において最高になることはできず、装置は、サードパーティの部品または競合する部品を容易に組み込むことができなければならない。１つのサイズがすべてに適合するとは限らず、個々のユーザ・ニーズに適したソリューションを構成する能力を製造業者に提供する複数の配置構成が必要である。また、製造業者は、ソリューションの挙動を、管理とサポートが可能なように複数の構成にわたって一貫させることができなければならず、それにより、ユーザは主導権を維持する。
【０００９】
そのようなタイプのサービスに関するユーザの好みとニーズの決定に焦点を合わせた研究は、最終的に、ユーザが、記録装置、請求書作成システムおよび供給チェーンに満足し続ける方法を強化する提供物の新しい機能のニーズを指摘している。また、この研究は、ユーザが、そのようなサービスを強く望み、セキュリティのハードルを越えてその機能を実現するために製造業者と一緒に作業する意志があることを示している。詳細には、研究から、ユーザのほぼ３分の１は、そのようなリモート・サービスが、次の購入時にユーザを所定の装置ブランドに忠実にさせる可能性が高いことが分かった。ほとんどのユーザは、自分の装置のリモート・サービス機能を得るためにお金を支払う意志があり、またユーザが共有データによって何らかのレベルの制御を有し、指導された自己修復、ソフトウェアの自動ダウンロード、およびリモート供給品／サービス解析または予測に特定の関心を示している限り、インターネットを介してサービス提供者にデータを送ることによりきわめてまたはある程度満足する。
【００１０】
さらに、リモート・ソリューションの最新技術の解析により、記録装置の製造およびリモート・ソリューションの市場にいる主な当事者はすべて、ある程度のリモート・サービス機能を提供し、その機能の拡張を重要視してきていることが分かった。オフセット印刷市場では、印刷機と周辺装置にリモート・サービスを組み込むことは、事業コストと見なされている。
【００１１】
現在のシステムより前にユーザに提供されたサービスは、特定の製品系列の範囲内で端末同士（end-to-end：エンド・ツー・エンド）で組み立てられ管理されていた。これには、製品自体だけでなく、ジョブをやり終えるために必要なインフラストラクチャ、サービス、およびバックオフィス接続の開発に投資する製品チームが必要であった。この作業は、長期間維持するのがきわめて難しく、また製品系列のなかで重複することが多かった。
【００１２】
例えば記録装置などの装置とユーザの関係を単純化することによって、ユーザの経験を大幅に強化することができる。実施形態は、現在手作業で行われかつ／または不均一な業務プロセスを自動化し、またユーザの要求に対応するための新しいワークフローを提供することができる。これは、例えば、装置が、ユーザの主導権を維持しながら、その装置のライフサイクルと付加価値サービスに積極的に関与できるようにする実施形態を使用することによって達成される。実施形態は、これを、分散管理タスクフォース（Distributed Management Task Force）や共通情報モデル（Common Information Model）（ＣＩＭ）に基づく規格といった規格アーキテクチャを使って行い、実施形態を使用しかつ／または実施形態と互換性のあるすべての装置に関してサービスを１度書き込むことを可能にし、製品ごとに新しいサービスをモジュール式に容易に追加できるようにする。
【課題を解決するための手段】
【００１３】
これらの目的を達成するために、実施形態は、共通サービス・モデル、複数の異種装置により動作するサービス、ならびに物理的構成、論理的構成および動作的構成におけるフレキシビリティを提供する。装置は、ユーザに強化された販売後の経験を提供する際に積極的な役割を持つ。実施形態は、ユーザと製造業者の両方のバックオフィス・プロセスへのシームレスな統合を得ることができる。
【００１４】
より詳細には、実施形態は、装置をソリューション提供物に接続するためのフレキシブルなエンド・ツー・エンド・システムを含む。装置の変更をバックオフィスの変更から分離しながら、様々な物理的位置および構成における多数の配置の選択肢が、現地の装置と新しい製品の両方に関して最も広い装置有効範囲と迅速な機能配置を可能にすることができる。
【００１５】
実施形態のシステムは、互換性のあるすべてのプラットフォームに再使用することができ、個々のプラットフォームが、すべてのバックオフィス・システムを再構成する必要がなくなる。各プラットフォーム・チームは、例えば実施形態のＤＭＡを組み込みかつ／または特定のサービス・トランザクション・プロトコルに従うことによって、前に述べ実施形態によって意図されている方法のうちの１つによって製品を使用可能にするだけでよい。
【００１６】
装置、アドオン・モジュール、および装置プロキシに組み込まれたエージェント・ソフトウェア構成要素は、共通装置モデル、共通情報管理（ＣＩＭ）アプリケーション・プログラミング・インタフェース（ＡＰＩ）、および装置サービスが動作させることができる環境を提供する。通信機構の共通の抽象化より、システムを物理トランスポート結合ノードから独立させることができる。サービス・モデルは、装置の近くで動作するサービスとそのライフサイクルをサポートし、サービスとソリューションを有効に管理しカスタマイズする方法およびプロセスを含む。その結果、エージェントに一旦作成されたサービスは、エージェントを含む任意の装置、アドオン・モジュールまたはプロキシ上で動作することができる。これにより、装置および装置プロキシを配置し、サービスの観点から共にシームレスに動作できるようにするシステムと、ユーザと供給業者の両方から入力がある装置に基づいたサービスのポリシ（policy）に基づいた予備との対応が得られる。組み込みサービス・エージェントは、ソリューション提供物において積極的な役割を持ち、必要な機能を提供するために分散ソリューションおよび／またはネットワーク・アクセス可能なサーバと共に動作する。サーバは、システムを横断しなければならないメッセージのクリアリング・ハウスを提供し、分散サービスを複数の細分レベルで接続しカスタマイズするのに必要な管理機能を提供する。
【００１７】
実施形態は、高いユーザの満足と忠誠の他に、経済的な利益を生み出すことができる。実施形態は、高いユーザ自助機能、リモート診断機能および予測機能によるサービス技術者の使用量を少なくすることにより、コスト削減を実現することができる。自動メータ読取りを含む実施形態において、少ない収集プロセス・インフラストラクチャ、より適切な契約の実施、および誤りに対する少ない備えによって、さらなるコストの削減を実現することができる。さらに、自動化供給物の注文に関与する実施形態によって、ある程度は、よりタイムリーで正確かつ妥当な測定によるユーザ・サイトにおける消耗品を追跡する高い精度によって、在庫を減少させることができる。電話注文や、やり取りの数が少なくなり電話時間が少なくなるという観点から、さらなるコスト削減を実現される。最後に、きわめて多くのユーザが、実施形態によって提供されるサービスの料金を喜んで支払うことになるため、実施形態は、新しいサービスからの収益の増加に役立つ。
【００１８】
実施形態は、例えば、新しい種類のリモート・サービスを含めることによって、ユーザのニーズと関心に応える。そのようなサービスは、ユーザ環境における装置の高い接続性を利用し、装置自体に組み込まれた計算機能を利用して、装置がユーザ作業プロセスの単純化に関与するようにする。プラットフォームは、共通バックオフィスの統合および作業プロセスをすべて使用するリモート・サービス提供物をモジュールでクロスプラットフォーム式に実現するために使用することができる規格ベースのソリューションを使用可能にする。実施形態において提供することができるサービスのタイプの特定の例には、自動メータ読取り、自動供給品注文、生産性報告、ソフトウェア・ダウンロード、ユーザ支援自助機能、リモート診断、および予測がある。
【００１９】
実施形態は、装置（プリンタ、スキャナ、レポジトリ、さらに他のサービスおよびソリューション）と、それらの装置を所有し、使用し、サポートし、購入し、アップグレードし易くするライフサイクルのサポートに存在するサービス・クラスを含む。市場調査により、このようなサービスが、ユーザに対する装置の価値を高め、また製品の寿命の間ずっとユーザの満足度と高める可能性があることが分かった。その結果として、このサービスは、新しく購入するときに、ユーザからのユーザの忠実性と配慮を大きくするはずである。
【００２０】
そのようなサービスは、実施形態において、組み込まれた装置インテリジェンスを含む新しい装置機能を利用し、多数のネットワーク接続された個体群を利用し、情報技術の進歩を調査して、装置が、販売後のライフサイクルでより積極的な役割を演じることができるようにして、自動化され拡張された１組の機能を使用可能にする。
【００２１】
実施形態は、供給業者がユーザにそのようなタイプの販売後サービスを有効かつ効率的に提供できるようにする基本的な１組の構成要素とその相互接続を提供する。プラットフォームのために定義された高い目標は、初期の構成要素およびサービスのアーキテクチャおよび開発を促進するために使用されてきた。それぞれの詳しい属性が、プラットフォームの大きな４つの目標をサポートする。このシステムの主な構成要素はすべて、提供されるサービスをユーザにとってシームレスに挙動させるために裏側で一緒に動作する。
【００２２】
実施形態は、電話、ファックスまたはコンピュータ・ネットワークを介してメータ読取りの自動報告機能を提供する。さらに、実施形態は、自動的に供給品を監視し供給品が少なくなったときにユーザに警告し、次およびその後の類似の状況での供給品の自動注文を可能にする。さらに、装置が提供するサービスは、ユーザの特定のニーズに合わせることができるが、実施形態によって提供される自動化されたサービス加入、ダウンロード、およびインストールによって、後でユーザの必要に応じて増減することができる。さらに、実施形態は、ユーザに、小さな修理とユーザが交換可能なユニットの交換を含むユーザが実行したい任意の作業を順番にさせることができる。実施形態のさらに他の利点は、中央アプリケーションからの多数の装置の長所を管理する能力である。
【発明を実施するための最良の形態】
【００２３】
本発明を概略的に理解するために、図面を参照する。図面において、類似の参照数字は、全体にわたって、同一の要素を示すために使用している。
【００２４】
実施形態は、構成要素の物理的および論理的なシステム設計の柔軟性と責任を保証するいくつかのタイプの分散されたソフトウェア構成要素とハードウェア構成要素からなるシステム１を提供する。実施形態は、例えば、ユーザ／ユーザ環境１００にある装置１１０、ユーザのネットワークまたは環境１００内にあることができる資産管理システム２００、および装置が申し込むことができるサービス３２０を提供するサービス・ホスト３１０を含むアーキテクチャを使用する。システム管理およびサービスがシステムに提供され、そこで、装置は、その装置自体のサービスとライフサイクルの両方のニーズならびにそのようなサービスとライフサイクルの一部分だけに積極的に関与する。
【００２５】
基礎として装置モデル・タスクフォース（Device Model Task Force）（ＤＭＴＦ）共通情報モデル（Common Information Model）（ＣＩＭ）を使用して、サービス管理が、共通装置モデル・エージェント（Common Device Model Agent）（ＣＤＭＡ）１２０の積極的な挙動（active behavior）に追加される。詳細は、例えば図１と図１０を参照されたい。各装置１１０は、例えばＤＭＴＦ ＣＩＭなどの共通中間言語を使用して、装置１１０のステータスおよび構成（１１１の部分）、提供されるサービス１４０、および他の情報（例えば、１１１の追加部分）をサービス・ホスト３１０に伝えるＣＤＭＡ１２０によって、サービス・ホスト３１０に提示されることが好ましい。ＤＭＡは、また、サービス１４０が常駐する装置上に、サービス１４０の実行時環境であるサービス環境１２４を提供し、サービス・ホスト３１０から提供されるサービスの装置独立性を提供する。したがって、特定のサービス１４０を、様々な装置１１０上で１度書き込み実行することができる。これにより、必要に応じて、１対多数構成を使用可能にし、要求し、利用することができる。例えば、実施形態は、後でさらに詳しく述べるように、挙動だけを含む単純なプロキシを含む装置プロキシと、代理の装置モデルとを含むことができる。また、実施形態は、サービス・ホストと直接通信する装置を含むことができる。
【００２６】
ＣＤＭＡ１２０は、サービス環境１２４、ＣＩＭ ＡＰＩ１２３、コアＤＭＡ１２２内のＣＩＭＯＭ１２５とサービス・マネージャ１２６、および共通提供者（common provider）ＡＰＩ１２１を含む。共通提供者ＡＰＩ１２１は、装置１１０の装置固有の提供者ＡＰＩ１１２と通信し、例えばその構成、ステータスおよび供給品レベルを含む装置に関する情報１１１を取り出す。次に、共通提供者ＡＰＩ１２１は、そのような情報を、コアＤＭＡ１２２内のＣＩＭＯＭ１２５とサービス・マネージャ１２６と、サービス環境１２４内で実行しているサービス１４０に利用可能にする。したがって、実施形態において、ＤＭＡ１２０は、サービス層１４１（サービス１４０を実行する集合体）と装置固有ＡＰＩ１１２の間に存在することができ、サービス・ホスト３１０と直接通信することができる。そのような場合は、サービス・ホスト３１０と通信できるようにするために、ＤＭＡ１２０を、電話線やコンピュータ・ネットワークなどの通信媒体に接続しなければならない。
【００２７】
部分的にはＤＭＡ１２０を使用する結果により、実施形態のシステム１は、実質的な通信媒体独立性を達成する。装置１１０は、ネットワーク、地上電話線、セルラ通信、パケット・ラジオ、ページャ方式、Ｂｌｕｅｔｏｏｔｈ（商標）、ＩＥＥＥ８０２．１１、または他の適切な通信方式により、サービス・ホスト３１０および／またはサービス・プロキシと通信することができる。そのような通信は、装置から行われてもホストから行われてもよく、監視されかつ／または監査されてもよく、ユーザの好み、サービス提供物（service offerings）、および全体的なサービス品質を使用して、特定のシナリオにどの選択が適切かを決定することができる。サービス１４０は、装置構成から独立することができ、バックオフィスまたは供給業者３００が、サービス内容の詳細を提供することができ、サービスの申し込みは、バックオフィス業務プロセスによって発行され有効にされ、新しいサービスの迅速な導入が可能になる。
【００２８】
従って、実施形態は、モジュール性、分散計算、サービス・モデルおよびトランザクションの独特な組み合わせを使用して多くの構成要素から組み立てられたエンド・ツー・エンド・システム１を含む。実施形態は、迅速かつフレキシブルなサービス配置をサポートするシステム・アーキテクチャ全体をモジュール式に使用する。このアーキテクチャは、システム要素、共通インタフェース、およびそれらの間の通信のためのメッセージング・モデルの機能と識別の抽象化を使用するため好都合である。装置サービスには、一貫しかつフレキシブルな形で一緒に動作する主たる４つのエンティティがあり、それらのエンティティは、装置自体、ユーザの環境における管理およびサービス・アプリケーション、サービス管理およびサービス構成に特化するバックオフィス・サーバ、およびそのようなサービスを囲む業務プロセス統合サーバおよび業務プロセスである。
【００２９】
図１０は、実施形態によって提示されたプラットフォームを構成することができる主な構成要素の概略図である。小フットプリント組み込みプラットフォーム１４０ならびにＤＭＡ１２０に結合されたインテリジェント・エージェント１２２を配置し、装置１１０と一体化することができる。装置１１０のインテリジェント・プロキシは、グループ管理とサービスへの関与を可能にし、独立したアプリケーションまたは他のアプリケーションの一部分としてプラットフォームに含まれてもよい。さらに、そのようなインテリジェント・プロキシは、実施形態の態様と結びつけるためにまだ使用可能にされていないレガシ装置を使用可能にすることができる。インターネットや供給業者イントラネットなど、現地の装置および製品を供給業者とその内部システムに確実かつ頑強に接続することができるコンピュータ・ネットワークや他の通信ネットワークに接続された媒体に依存しない通信およびアプリケーション・インフラストラクチャが使用される。さらに、実施形態は、そのようなサービスを可能にするために付加価値のある拡張機能と一体化された１組の業界標準のウェブ・サービス技術を含む。したがって、実施形態は、装置をサポートするエンド・ツー・エンド・システムで実行する１組のサービスを提供する。
【００３０】
装置１１０は、一般に、ユーザ・サイト１００に物理的に配置されるが、実施形態は、他のサイトにある装置１１０にも対応することができ、世界中に分散させてもよい。ローエンド製品からハイエンド・システムにわたる様々な装置１１０を含むことができる。実施形態は、このシステムでは、例えば３つの主な成功因子（enabler）を提供する装置１１０を使用する。装置１１０は、装置固有の違いをインタフェースの後ろに隠すことによって、サービスとのより容易な統合を可能にするために、共通装置インタフェース（Common Device Interface）（ＣＤＩ）と共通情報モデル（Common Information Model）（ＣＩＭ）１２３を提供する。ＣＤＩは、ＣＤＭＡ１２０内で、共通提供者ＡＰＩ１２１として実現することができる。これにより、サービスの再使用が可能になり、システム１の複雑さが大幅に減少する。ＣＤＩは、サービスおよびサービス管理のために、サービス提供者および／または製造業者に固有の拡張機能により、分散管理タスクフォース（ＤＭＴＦ）ＣＩＭによって指定される。また、ＣＩＭ１２３は、診断拡張機能を含む、サービス提供者および／または製造業者が提供することができるサービスを備えた装置に適した特定の拡張機能によってＤＭＴＦ ＣＩＭに準拠することができる。
【００３１】
創意に富むシステム１の実施形態における装置１１０は、例えば、サービス１４０を装置１１０に送って装置１１０の近くで実行することができる組み込みプラットフォーム１２４を提供する。また、組み込みサービス・プラットフォーム１４０は、サービス・マネージャ１２６を介したローカルなサービス管理と、新たに配置されたサービス１４０をホスティング・プラットフォームのソフトウェア・リリースと同期せずに受け入れる能力とを提供する。これにより、システムの複雑さが減少し、新しいサービスまたは精巧なサービスの現地への配置が高速化される。実施形態において、ＤＭＡ１２０が、組み込みプラットフォーム１２４を提供するが、他のシステムがプラットフォームを提供することもできることが好ましい。ＤＭＡは、共通に配置されたサービスにおいて、装置の組み込み計算能力、データ、および機能にアクセスし使用できるようにするソフトウェア・モジュールであることが好ましい。
【００３２】
これらの構成要素は、一般に、供給業者３００だけでなくユーザの環境１００全体にわたって分散される。同時に、これらの構成要素は、製品（装置１１０やサービス１４０など）を販売後ソリューション提供物（付加サービス１４０）に接続するためのフレキシブルなエンド・ツー・エンド・システム１を提供する。システム１は、実施形態において、物理的な様々な位置および構成で一連の配置オプションをサポートするアーキテクチャを提供するように設計されている。実施形態は、装置１１０での変化をバックオフィス３００での変化から分離するように、現地の装置と新しい製品に最も広い装置有効範囲と機能の最も迅速な配置を提供することが好ましい。実施形態は、さらに、装置１１０に組み込まれた独特な付加価値のあるエージェント・ソフトウェア構成要素ＤＭＡ１２０、アドオン・モジュール１１５、および／または共通装置モデル１２２とＤＭＴＦ ＣＩＭ ＡＰＩ１２３と新しい装置サービス環境１２４を提供する装置プロキシ２１０を提供する。さらに、実施形態は、ノードを結ぶ任意の物理トランスポート（デバイスと供給業者システムの間）からシステムを独立させることができる通信機構の共通の抽象化を実現することができ、これにより、ユーザ要件に基づいてより高いフレキシビリティと配置カスタマイズ性が実現される。実施形態のサービス・モデルは、サービスとソリューションを効果的に管理しカスタマイズする方法とプロセスを含む、「装置の近くで」実行するサービスとその装置のライフサイクルをサポートする。ＤＭＡ１２０に関して前に述べた実施形態におけるサービスは、そのような任意の使用可能にされた装置１１０またはプロキシ２２０の上で動作することができ、サービスの観点から装置および装置プロキシを相互にシームレスに配置し動作させることができる。実施形態での対応は、ユーザと供給業者の両方が提供した情報に基づいて、装置ベースのサービスのポリシで達成することができ、サービスを迅速に可能にすることができる。
【００３３】
実施形態のＤＭＡ１２０は、ソリューション提供物において積極的な役割をもち、分散ソリューションと共同で動作する。そのような分散装置エージェント１２０は、インターネットや電話システムなどのネットワークを介してアクセス可能な供給業者３００にあるサーバ３１０と共に作動する。サーバの役割は、ソリューションを横断しなければならないメッセージのクリアリング・ハウスを提供し、分散サービスを複数の細分レベルで接続しカスタマイズするのに必要な管理機能を提供することである。
【００３４】
この機能を備えていない既に配置済みの装置１１０の場合、物理システム構成要素１１５を装置１１０に内部的または外部的に追加するオプションが、この機能を使用可能にし、実施形態によって提供される。創意に富むシステム１に対して、この方式で使用可能にされた装置１１０は、アドオン構成要素１１５が装置１１０に対して優れたインタフェースを有する限り、機能が組み込まれた装置１１０と違いがないように見える。例えば、そのようなアドオン構成要素１１５を含む実施形態は、記録装置の入出力端子（ＩＯＴ）に取り付けられ、ＥＰＳＶ、ＰＷＳ、場合によってはＣＡＮバス・インタフェースを介してＩＯＴに接続され、ネットワークに接続された構成要素を備えることができる。この構成は、ＩＯＴに、装置サービス１４０に関与する機能を与える。次に、ＤＭＡとサービス・プラットフォームに全域にわたる装置機能を提供するために、非標準またはネットワーク・アクセス不可能なＡＰＩにアクセスしなければならないので、このアドオン構成要素１１５は、装置との１対１の写像において見つけることができる。
【００３５】
入力出力端子（ＩＯＴ）が別の製造業者によるものである可能性があり、ユーザが多数のデジタル・フロント・エンド（ＤＦＥ）から選択できるという事実に対応するために、実施形態は、アドオン・システム構成要素を特徴としている。このアドオン構成要素は、例えば、ＬｉｎｕｘやＤａｒｗｉｎなどのオペレーティング・システムや、例えばＤＭＡサービス・プラットフォームを実行するInsigniaのJeode（登録商標）Embedded Virtual MachineなどのＪａｖａ（登録商標）仮想マシンを実行する低コストの組み込みパーソナル・コンピュータ・プラットフォームである。このアドオン構成要素は、ＥＰＳＶやＰＷＳなどのインタフェースを介してＩＯＴに直接接続することができる。次に、装置は、ユーザの内部ネットワークに接続される。
【００３６】
ユーザ環境のバックオフィス・サーバにおける装置管理およびサービス・アプリケーション２２０は、サービス管理およびサービス構成業務プロセス統合サーバならびにそのようなサービスの周辺の業務プロセスに特化する。そのようなシステム・レベルの構成要素とその相互接続の概略図を、図１に示す。
【００３７】
実施形態は、具体的には、エンド・ツー・エンド・システム管理および販売後アプリケーション・アーキテクチャにおいてユーザにサービスを提供する際の装置の役割に関する。本発明は主に、装置中心サービス（Device Centric Service）（ＤＣＳ）プラットフォームにおける装置側テクノロジ・モジュールである装置モデル・エージェント（Device Model Agent）（ＤＭＡ）１２０に焦点を当てている。ＤＭＡは、シン（thin）で効率的なアプリケーション／サービス実行環境である。ＤＭＡは、そのプラットフォーム自体を修正することなくオンライン・サービス（e-services）をシステム内で設計し、追加し、管理することができるフレキシブルで、拡張可能で、動的なサービス管理システムを提供する。本発明は、特に、ＤＭＡからドキュメント・システム装置への利点の統合について示しているが、この概念は、他の分野にも等しく適用可能である。ＤＭＡ実行時環境は、Ｊａｖａ実行時環境と組み込みウェブ・サーバ間のドキュメント・システム装置上にあるシン・ソフトウェア・インタフェース層である。
【００３８】
本明細書で述べている装置モデル・エージェントは、ドキュメント・システム装置に以下のような機能を追加する。これらの機能の独特な組み合わせによって、システム管理アプリケーションの開発、配置および維持と関連したいくつかの利点が可能になる。
【００３９】
ＤＭＡ１２０は、例えば販売後サービス、システム管理サービス、その他のサービスなどのアプリケーションおよびサービス提供物における積極的な関与を可能にする。ＤＭＡ１２０を組み込んだ装置１１０は、システム管理アプリケーションおよびサービスで必要とされるいくつかの計算タスクを実行することができる。このアーキテクチャにおいて、例えばユーザ環境１００に設置されたアプリケーション・サーバ２００または供給業者３００のバックオフィス・サーバ３１０と、ターゲット装置１１０とが協力して、システム管理提供物を完成させる。例えば図１０、図１３および図１４に示したように、ＤＭＡ１２０は、サービス実行環境１２４を提供し、そこで、サービス１４０は、サービス供給業者３００のアプリケーション・サーバまたはホスト・システム３１０上で実行するシステム管理アプリケーションまたはホスト・システム３２０の全体または一部分として動作することができる。
【００４０】
ＤＭＡサービスは、装置のイベントを監視し、規定のアクションをとることができることが好ましい。ＤＭＡ１２０は、関心のあるイベントが発生したときに加入者／ユーザにデータを発行できることが好ましく、また内部または外部クライアントあるいはユーザから指示されたときに装置１１０上に診断ルーチンなどのメソッドを呼び出すことができることが好ましい。これにより、装置固有の処理が、中央アプリケーション・サーバ３２０から装置１１０の近くに移される。アプリケーション・サーバ３２０の役割は、アプリケーション／サービス１４０の実行用の計算プラットフォームから、アプリケーション／サービス１４０の管理および構成に変換することである。したがって、装置１１０は、厳密なクライアント／サーバ・アーキテクチャにおける受動的データ・レポジトリと対称的にプロセスに積極的に関与する。
【００４１】
また、実施形態によるＤＭＡ１２０は、サービス１４０の動的な更新を実行し、エンド・ツー・エンドＤＣＳプラットフォーム１内で動作する構成要素をサポートすることができる。ＤＭＡ１２０を使用する装置１１０は、新しいサービス構成要素１４０を動的に追加することができる。これにより、ユーザあるいは装置１１０上に既にあるアプリケーション構成要素は、サービス１４０をサポートするためにそのような追加を要求することができる。また、これにより、必要に応じて、システムまたはＤＭＡの再コンパイルまたは再起動なしに、構成要素の追加と削除を行うことができる。実施形態において、ターゲット装置１１０自体は、新しいサービスまたはアップグレードされたサービスの全体の追加あるいは既存のサービスの構成要素のサポートを開始する。これにより、本明細書に示したシステム１において、装置１１０は、装置１１０自体ならびにその上で動作するシステム管理サービスを維持する活動の開始を担当できるようになる。
【００４２】
実施形態は、さらに、開発者が一貫しかつ標準ベースのツール・セットで作業できるようにするアプリケーション／サービス実行環境１２４の必要を認識している。ＤＭＡ１２０は、装置に依存しない販売後のアプリケーション１４０の開発を可能にする。ＤＭＡ１２０インタフェースを使用して作成されたアプリケーション１４０は、新しいＤＭＡ対応装置またはアップグレードされたＤＭＡ対応装置に対応するように変更する必要がない。ＤＭＡ１２０は、アプリケーション／サービスの装置独立性を達成するためにＤＭＴＦによって採用されたモデル・ベースの手法を実施するが、この実施態様に、サービス・マネージャ１２６と呼ばれる新しい構成要素を追加する。サービス・マネージャ１２６は、主に、装置のために活動化された各サービス１４０のサービス１４０ライフサイクルを制御する役割を持つ。さらに、サービス１４０の制御と管理のために、サービス・マネージャ１２６は、サービス１４０を管理し、ローカルまたはリモートのシステム管理クライアントにプログラマチック・インタフェース（ＡＰＩ）を提供することが好ましい。
【００４３】
エンド・ツー・エンドＤＣＳプラットフォーム１内の動作において、ＤＭＡ対応装置とＤＣＳアプリケーション・サーバは、供給業者３００のサービス・ホスト３１０上のアプリケーション・サーバまたはホスト・システム３２０によって、あるいはサードパーティ・サービス提供者によって、サービスの対応および管理を可能にする。ＤＭＡ対応装置１１０とアプリケーション・サーバ３２０は協力して、動的対応を実現する。このシステムを使用すると、ユーザは、１組のアプリケーションを調査し、ユーザのニーズを満たすように１つまたは複数のアプリケーションを選択またはカスタマイズし、選択した１組のアプリケーションを注文することができる。続いて、アプリケーションを、インストールし、使用可能にし、起動し、監視し、かつ／または管理することができる。
【００４４】
新規および既存の装置の基準をカバーするために、実施形態におけるＤＭＡ１２０のアーキテクチャは、いくつかの形で配置を可能にする。例えば図４、図９および図１１に示したような実施形態によれば、例えば、ＤＭＡ１２０は、プリンタや多機能装置などのネットワーク接続装置１１０に組み込まれる。この実施形態において、ＤＭＡ１２０は、ウェブ・サーバ側の構成要素になる。ＤＭＡ１２０は、例えば、サービス構成要素をウェブ・サーバの後ろにホストするために、Ｊａｖａサーブレットなどの標準的な方法を使用することができる。
【００４５】
代替として、ＤＭＡ１２０は、複写機などの独立型の装置１１０またはＤＭＡ１２０を実行することができない現場の既存の装置の専用ハードウェア装置またはアドオン構成要素１１５に組み込むことができる。そのようなアドオン構成要素１１５を、図１２、図１６および図１７に概略的に示し、後でより詳しく考察する。
【００４６】
もう１つの代替構成は、ネットワーク・アプリケーション２２０に、ＤＭＡ１２０を、単一の装置プロキシ構成または複数の装置プロキシ構成として組み込むものである。そのようなプロキシ構成を、例えば、図７、図８および図１１に例示する。
【００４７】
任意の装置製造業者にとって、販売後アプリケーションは、ユーザの忠実性を継続するために重要なことがある。記録装置および／または多機能装置の供給業者の場合、ドキュメント・システム装置の販売は、ユーザとの関係の始まりに過ぎない。継続的なサービス、サポート、供給品補給および持続的保守が、ユーザの定着率を決定する主な検討要素になる。しかしながら、前に述べたように、販売後アプリケーションのコスト効率の高い開発、配置および管理自体に、いくつかの課題がある。複雑さは、開発者、装置製造業者、サービス所有者および顧客／ユーザを含む多数の利害関係者の存在によって高くなる。プラットフォームとして、ＤＭＡ１２０は、実施形態に従って、すべての主な利害関係者をとりまとめ、すべての利害関係者の要件に対応するように設計されることが好ましい。
【００４８】
ＤＭＡ１２０は、装置固有のインタフェース１１１とシステム管理アプリケーションの間に抽象化層を構成することが好ましい。例えば、図１０、図１３および図１４を参照されたい。抽象化は、システム管理アプリケーションに対して、装置データ、イベントおよび操作の共通の見方を提供する。ＤＭＡ１２０は、モデル・ベースの手法を使用して装置の抽象化を行う。このために使用される装置モデルは、ＤＭＴＦ（分散管理タスクフォース）コンソーシアムにおける業界標準活動に基づく。基礎として、強化したＤＭＴＦ共通情報モデル（ＣＩＭ）が使用される。しかしながら、装置インタフェースによる共通モデルの実施は独特である。販売後アプリケーション・クライアントとＤＭＡの間の対話は、DMTF CIM Operations Over HTTPの仕様に基づく。
【００４９】
ＤＭＡ１２０は、サービス・マネージャ構成要素１２６を追加することによってＤＭＴＦ／ＣＩＭの実施を強化する。サービス・マネージャ１２６は、サービス１４０をロードし、ＤＭＡ１２０に現在インストールされているサービス１４０のリストを維持し、サービス１４０の管理およびライフサイクルの制御を維持する役割を持つ。サービス・マネージャ１２６は、自動化されたプロセスとして動作することが好ましく、サービス１４０を、プログラムであるいはＤＭＴＦＣＩＭ ＡＰＩ１２３でアクセスすることができる独立した構成要素として自動的に参照し開始することができる。サービス・マネージャ１２６は、装置１１０上のアクティブ・サービス１４０へのアクセスならびに１つまたは複数のアクティブ・サービス１４０の管理データを提供することができる。
【００５０】
ＤＭＡサービス・マネージャ１２６は、サービス・マネージャ１２６がロードするとき自動的に開始されるコア・サービスをサポートすることが好ましい。そのようなコア・サービスは、対応サポートを必要としないことが好ましい。また、サービス・マネージャ１２６は、ＤＭＡ１２０の動的対応機能による実施を必要とする規定のサービス１４０をサポートすることが好ましい。
【００５１】
図１５は、サービス・マネージャ１２６の起動と通常の実行を例示する概略的なフローチャートである。ＤＭＡ１２０は、起動すると、サービス・マネージャを開始する（ブロック５１０）。次に、サービス・マネージャ１２６は、コア・サービスをロードし（ブロック５１１）、動的サービス対応ホストに問い合わせる（ブロック５１２）。サービス・マネージャ１２６は、さらに、サービス構成パラメータを解釈し処理し（ブロック５１３）、規定のサービス１４０をロードし開始する（ブロック５１４）。次に、サービス・マネージャ１２６は、管理のためにサービス１４０を監視し（ブロック５１５）、必要に応じてシステム管理クライアントと対話する（ブロック５１６）。
【００５２】
ＤＭＡ１２０は、例えばＳｕｎのＪａｖａ２マイクロ・エディション（Ｊ２ＭＥ）などの実質的にプラットフォームに依存しない言語を使用して作成されることが好ましい。したがって、ＤＭＡは、きわめて移植性が高く、Ｊａｖａが使用可能な任意のシステム構成においてシステム構成要素として使用することができる。
【００５３】
実施形態による管理およびサービス・アプリケーション２００は、ユーザの環境に配置することができる。いくつかのアプリケーション２２０は、例えば図７に概略的に示しているように、ネットワーク接続されているが装置サービスに自ら積極的に関与するように完全には使用可能にされていない装置１１０のサービス・プロキシとして部分的に挙動することによって、装置サービスの提供を可能にすることができる。換言すると、アプリケーション２２０は、ＤＭＡ１２０あるいはサービス提供物１４０を直接サポートするソフトウェアを備えていないネットワーク接続された装置のプロキシとして働くことができる。例えば、Ｘｅｒｏｘ（登録商標）社のCentreWare Web（ＣＷＷ）などのいくつかのアプリケーションは、シンプル・ネットワーク管理プロトコル（Simple Network Management Protocol）（ＳＮＭＰ）対応の装置の装置プロキシとして働くことができる。装置内のＳＮＭＰエージェントが、提示されているサービスをサポートするために必要なデータと機能を提供するという点で、これは、装置をサービスの層にするための優れた方法のことがある。そのような場合、ＣＷＷなどのアプリケーションは、装置１１０の近くで動作するサービス１４０をホストする役割を負う。
【００５４】
サービス・ホスト３１０などのエンド・ツー・エンド・システム１のバックオフィスまたはホスト部分３００にとって、装置１１０は、アプリケーション２２０によって代理されたときに、装置がサービス・ホスト３１０と直接通信した場合とほとんど同じように見える。代理の装置と直接の装置との違いは、様々なレベルのファームウェアを有する直接装置と関連した違いほど実質的な差がない。装置の機能の違いは、装置ベース・サービスの対応システムによってバックエンド／サービス・ホスト３１０上で管理することができる。そのような違いの影響は、所定の装置のきわめて特殊な機能を利用する高度なサービスが、ほとんど移植性をなくすことであり、すなわち、ＣＩＭ拡張機能の製品固有の部分のために作成されたサービスは、まったく移植性がなくなり、他の装置と互換でなくなることがある。しかしながら、コアおよび共通モデルに作成されたサービスは、移植性を維持し、配置の問題は、対応システムによって管理される。
【００５５】
アプリケーション２２０は、また、直接ネットワーク接続されていないがアドオン接続オプションを有する装置のサービス・プロキシとして挙動することができる。そのような接続オプションは、イーサネット（登録商標）などのハードワイヤードでもよく、あるいはＢｌｕｅｔｏｏｔｈ（登録商標）やＩＥＥＥ８０２．１１などの無線でもよく、その有効範囲が局所的でも広範囲でもよい。例えば、印刷用にネットワーク接続されてない独立した複写機は、８０２．１１ｂや他の無線ネットワークなどの小規模無線ＬＡＮ接続が追加される。プロキシは、ＤＭＡのないネットワーク接続装置が代理されているときとまったく同じに挙動するが、また、プロキシは、アドオン接続機能が付加された装置と通信するために使用される無線アクセス・ポイントに必要なハードウェアを含む。そのようなシステムの例は、ＬＡＮ上で物理的にネットワーク接続されまた無線アクセス・ポイントが付加されたサーバ上にインストールされたＣＷＷである。バックオフィス・エッジ・ホスト３１０とって、無線式に代理された装置１１０は、ＬＡＮ上で代理された装置と違いがないように見える。
【００５６】
アプリケーション２２０は、また、ユーザ環境内のサーバからサービスをひとまとめに管理することを可能にする。実施形態において、装置プロキシは、代理装置と関連したサービスの集約およびグループ管理機能を提供することができる。これは、例えば、システム管理者またはユーザが１組の装置上のサービスのステータスを調べるグラフィカル・ユーザ・インタフェース（ＧＵＩ）である。
【００５７】
サービス・ホスト３１０などのバックオフィス・システムに対するサービスおよびそのトランザクションの共通装置インタフェースは、装置自体で使用されるインタフェースの拡張部分でよい。これにより、サービスは、装置が直接の状況と、装置が代理を使用する状況の両方で動作することができる。プロキシと関連したトランザクションおよびデータを処理する限られた組の特定の装置プロキシ拡張機能と共に、サービス・ホストと直接通信する装置からのＡＰＩがサポートされる。装置に向けられたトランザクションはすべて、同じように見えなければならない。
【００５８】
図２を参照して、例示的な実施形態の追加部分を示す。サービスのホスト部分、すなわちサービス・ホスト３１０は、ユーザ・サイト１００、２００の外にあってもよく、製造業者や他のサービス提供者の設備３００にあってもよい。装置サービス・エッジ・ホスト４１０は、現場に配置された装置サービスのトランザクションとサービス管理を処理する。これは、分散サービス１４０をサポートするメッセージ待ち行列の管理とソフトウェア・モジュールおよび構成パラメータの対応を含む。エッジ・ホスト４１０は、また、セキュリティのホスト・エンドと装置サービス・システム１によって使用されるサービス・モデルの役割をする。
【００５９】
エッジ・ホスト４１０は、また、サービス・スポンサ・システム３１０への接続を提供する。これは、外部装置サービス界（external device services world）を内部（またはサードパーティ）サービス界（internal (or third party) services world）に接続する。サービスのスポンサとなる各組織の接続は、エッジ・サーバによって維持され、サーバとホストを維持するエンティティのセキュリティ・ルールおよび規則に従うことができる。エッジ・ホストによって、装置１１０または装置プロキシ２２０が、サービス・ホスト３１０上に含まれるサービスのバックオフィス集合体との対話の詳細の直接的な知識を持つ必要がなくなる。これは、装置サービスを、管理しやすくかつ頑強に配置する際に有利である。実施形態は、基本的な操作を標準化するために、バックオフィス・スポンサ組織に共通サービスＡＰＩを提供することが好ましい。特定のサービスは、所定のアプリケーションのトランザクションの内容を拡張しカスタマイズすることができる。
【００６０】
引き続き図２を参照して、ユーザの環境１００、２００に、装置１１０と、ＣＷＷなどのユーザ・アプリケーション２２０を配置することができる。これは、管理されたサービス環境でもよく、通常のユーザ環境でもよい。インターネットや他の適切な長距離接続機構４００を横切って、ユーザの内部システムおよびネットワーク１００、２００から、サービスおよび通信が分散されお互いをつなぐ。周知のウェブ・サービスならびに将来のウェブ・サービスは、装置／アプリケーション１１０および２２０とエッジ・ホスト４１０との間、ならびにエッジ・ホスト４１０と内部サービス提供者３１０の間で使用されることが好ましい通信機構１３０、２３０、３３０を含む。システム１は、ユーザ側（ファイアウォール１６０）とサービス提供者側（ファイアウォール３６０）の両方の既存のファイアウォールによって動作する能力のために、基本的なＩＴ産業やその他の規格を満たすように構成されることが好ましい。このシステムを適切に動作させるために、ユーザのファイアウォール１６０の特別な構成は必要ない。
【００６１】
サービス供給システム３００は、すべてのユーザ・システムが使用する頑強で十分に管理された２４ｘ７レベルのサービスおよび障害回復を提供する基本的な供給業者インフラストラクチャの一部であることが好ましい。前に示したように、エッジ・ホスト４１０は、現場に配置された装置サービスのトランザクションおよびサービス管理を処理することができる。これは、分散サービスをサポートするメッセージ待ち行列の管理ならびにソフトウェア・モジュールおよび構成パラメータの対応を含む。これは、また、装置サービス・システムによって使用されるセキュリティおよびサービス・モデルのホスト・エンドの役割をする。実施形態において、エッジ・ホストは、また、外部装置サービス界を内部（または、サードパーティ）サービス界に接続する。サービスのスポンサになる各組織への接続は、エッジ・サーバによって維持され、供給業者のセキュリティ・ルールおよび規則に従うことが好ましい。
【００６２】
実施形態において、エッジ・ホスト４１０によって、装置または装置プロキシは、含まれるサービスのバックオフィス集合体との対話の詳細の直接的知識を持たなくてもよくなる。これは、装置サービスを管理しやすくかつ頑強に配置するのを助けることができる。基本的な操作を標準化するために、共通サービスＡＰＩが、バックオフィス・スポンサ組織に提供される。特定のサービスが、所定のアプリケーションのトランザクションの内容を拡張しカスタマイズすることができる。
【００６３】
「多重送出パス」
最高レベルにおいて、システム１は、システムによって、サービス１４０が装置１１０とバックオフィス（供給業者）３００間で直接動作したり、装置プロキシ２２０の支援により動作したりするように設計される。これにより、ユーザが直接使用可能にされる新しい装置をゆっくりと取得している間に装置プロキシ２２０がきわめて迅速に多数のレガシ装置をサービス提供物にすることができるので、最も広い配置ができる限り迅速に行われる。また、ユーザによっては、プロキシを、個別に各装置からではなくそのサイトから出るメッセージのコンソリデータ／クリーニング・ハウスとして挙動させるのを好む場合があるので、両方の動作モードを有することも重要である。他のサイトでは、ユーザは、装置プロキシをインストールすることを望まない場合があり、したがって、サービスを直接使用可能にする必要がある。それぞれのパスを使用可能にする他に、最後に、ユーザが両方のシナリオを同時に行うことができるため、サービスを一緒に機能させることは有益である。
【００６４】
複数のパスが、配置のフレキシビリティを高めることができるように、そのようなパスを、サービス提供者の視点から見えなくすることは有益である。実施形態は、装置１１０とプロキシ２２０をできるだけバックオフィス・システム３１０から分離することが好ましい。これらの２つの強力な抽象化と分離により、装置１１０またはバックオフィス３００内の機能を階段的に独立に配置させることができる。さらに、どちらかの端にあるシステムの変更を行う必要がある場合、変更は、適切な抽象化が使用可能にされた場合にシステム１全体に影響を及ぼさず、保全性が強化される。
【００６５】
図１０を再び参照すると、実施形態の全体にわたる抽象化は、装置レベルで、ＤＭＡ１２０に組み込まれた抽象装置モデル１２２を含む。抽象装置モデル１２２は、基礎としてＤＭＴＦ ＣＩＭを使用して構成されることが好ましい。実施形態において、装置モデル１２２とプラットフォーム１２４は両方とも、ＤＭＡ１２０にある。共通サービスは、提示されるサービスに関係なく供給業者のドメイン３００を指定する。また、バックオフィス／供給業者レベル３００で、実施形態は、サービス・スポンサの共通ＡＰＩを使用して、供給業者バックオフィス３００からのサービスを構築し管理する。共通ＡＰＩは、タイプまたは接続機構に関係なく、装置１１０を同じように処理する。
【００６６】
実施形態におけるこのアーキテクチャは、供給業者への直接の装置通信またはプロキシを介した通信の観点から、配置のフレキシビリティなどのフレキシブルな配置オプションを提供する。フレキシビリティの他に、サービス自体を、その多数のパラメータをカスタマイズできるように定義することができる。このサービス・カスタマイズには、例えば、リモート監視サービスの一部分として送られるデータや、メータ読取りを供給業者に送る時刻または頻度がある。正確な構成パラメータは、提供されるサービスに固有でよい。
【００６７】
実施形態のプラットフォームは、サービスの構成を容易に管理できるように設計されている。このシステムにより、ユーザ・サイトにあるすべての装置に関して、あるいはある場所に関係なくユーザが所有するすべての装置に関して、サービスの構成を、個別の装置通し番号で指定することができる。実施形態において、この管理は、サービス提供者によって制御されるバックオフィスで行われる。
【００６８】
フレキシブルな配置オプションのさらに他の部分は、図３に概略的に示したように、実施形態に従って、装置に利用可能なサービスに加入基準を使用することである。加入プロセスは、例えば、個別のサービス提供者によって制御され管理することができ、任意の所定の装置に提示されるサービスは、ユーザの要望とサービス提供者の認証を組み合わせることによって制御することができる。したがって、同じ製品系列であっても、すべての装置が、いつでも同じサービスを提供したりインストールしたりしなければならないとは限らない。
【００６９】
ＤＣＳと関連するいくつかのアクティビティがある。例えば、Ａｘｅｄａ、Ｅｍｂｒａｃｅ Ｎｅｔｗｏｒｋｓ、Ｑｕｅｓｔｒａ、およびＩｍａｇｉｎｇ Ｐｏｒｔａｌｓは、サービス面で有効であった。これらの技術的な実施態様の例は、Embrace Networksの特許出願の付与前公報番号２００２−０１３３５８１ Ａ１であり、この出願は、参照により本明細書に組み込まれる。しかしながら、従来技術には、対応態様がなく、また対応のための重要なサポートがあるとは思われない。
【００７０】
４ｔｈ ｐａｓｓなどのいくつかの会社が、汎用対応ソフトウェアを販売しているが、従来技術はどれも、本発明の態様を包含するとは思われない。参考のために、Ｓｕｎは、http://java.sun.com/j2ee/provisioning/industry.htmlにそのような対応ソフトウェアの一般的なリストがある。さらに、すべての会社が、携帯電話産業をそのターゲット市場として狙っていると思われる。
【００７１】
前述のように、広域的な電気通信会社が、携帯電話上のサービスを提供し始めている。これを達成するために、すべての携帯電話は、ＣＬＤＣと呼ばれるＪａｖａ規格を使用している。このリリースされた規格は、携帯電話などの小型装置上でＪａｖａプログラムがどのように動作できるかを規定し、またはより重要なことには、Ｍｉｄｌｅｔｓと呼ばれるモジュラ・プログラムを、実行時にＣＬＤＣ Ｊａｖａ環境にどのように追加できるかを規定している。
【００７２】
この規格は、対応ユニットと、それが装置側でどのように受け入れられ組み込まれるかを定義しているが、サーバの側面については何も言及していない。このために、電気通信会社は、自分自身の対応サーバ・ソリューションを作成するか、前に列挙した対応ベンダからのものを購入していた。この分野での高い競争環境のために、代替ソリューションについて検査する方法はない。
【００７３】
第２の関連する規格は、ＯＳＧｉと呼ばれる。ＯＳＧｉは、ローカル・ネットワーク接続された装置が、リモート・サーバと通信して、モジュラ・サービスをダウンロードし実行できるようにするＪａｖａを利用したリリース規格である。この規格は、ＣＬＤＣ／Ｍｉｄｌｅｔｓと比べて、業界であまり支持を受けてこなかった。ＯＳＧｉは、また、対応のサーバ側の問題を避けている。
【００７４】
第３の規格は、SyncML Device Managementである。ＳｙｎｃＭＬは、モバイル装置をいくつかのサーバ・ベースのソースと同期させる詳細に焦点を当てたリリース規格である。この規格の狙いは、カレンダや約束のようなものにある。昨年、この同期プロトコルは、モバイル装置上のサービス設定を明示的に変更し、そのモバイル装置にサービスをダウンロードできるようにする装置管理努力によって拡張された。SynchMLは、サーバ側の対応の問題を避けている。
【００７５】
最後の規格は、名前はないが、一般にＪＳＲ−１２４と呼ばれる。要するに、Ｊａｖａプログラマは、Java Community Process（ＪＣＰ）を使用して、Java Specification Request（ＪＳＲ）を、Ｊａｖａ言語への追加および拡張機能として作成し規格化する。ＪＳＲ−１２４は、Ｊ２ＥＥクライアント対応仕様（J2EE Client Provisioning Specification）である。Ｊ２ＥＥは、ハイエンドなトランザクション処理でＪａｖａを使用するための規格である。この周辺の市場は大きく成長した。実際には、ＪＳＲ−１２４は、対応システムを表現するフレームワークを定義しようとしている。ほとんどすべての対応する新規企業と電気通信会社はほとんど、ＪＳＰの会員である。これは、すべての対応システムがＪ２ＥＥシステムとすべて標準的な方法で対話できるほど一般的でかつ、ベンダが代替の競合ソリューションを作成できるほど緩いものになるようにする。規格は、公開され草案が評価されている段階である。
【００７６】
実施形態には、共有ユーザ・サービス・ライフサイクルに基づいた共通対応モデルの定義と実施が含まれる。Provisioning Server (PS)３１０、ＰＳに話しかけるＤＣＳ装置１１０、およびＤＳＣ装置と対話する供給業者は、対応プロセスが動作する方法に関する共有モデルに従って動作することが好ましい。ＰＳ３１０と対話する関係者ごとに、役割と責任を定義するライフサイクル・モデルを作成することができる。役割と責任に基づいて、関係者がその役割に基づく目標を達成できるように、文法とコマンドが作成された。
【００７７】
例えばこの節のすべての要件を満たすサービス・ホスト３１０において動作する対応サーバ９００のアーキテクチャと実施態様を、例えば表１と図２０に概略的に示す。図２０において左から右に進み、最初の主要モジュールは、サービス顧客インタフェース９０１である。これは、外部ユーザ１１０と外部装置２２０とのすべての対話の担当することが好ましい。また、装置と顧客が使用する可能性がある様々なプロトコルから他のＰＳモジュールを分離することが好ましい。実施形態での好ましいプロトコルは、ウェブ・サービスであるが、将来的には、ｈｔｔｐ、電子メール、携帯電話やその他の送信フォーマットに拡張することができる。入ってくるトランザクションの場合、要求を処理するのに適正な内部リソースにトランザクションを送る。出てゆくトランザクションの場合、装置またはユーザのために待ち行列に入れられた他のＰＳモジュールの出力を取得し、それを、装置または顧客と対話するのに必要なプロトコルに変換する。
【００７８】
【表１】
2004220556.tif 000003
【００７９】
エンティティ管理モジュール９０２は、エンティティ情報をローカライズしサーバ９００の他の部分から分離することが好ましい汎用ＰＳリソースである。このモジュールは、装置、ユーザ、その基本設定、関連する位置情報などのエンティティに関する情報を保持する。ローカルでないエンティティ情報では、エンティティ管理モジュール９０２は、そのような他のＩＭシステムと接する１つのポイントである。モジュール９０２は、ローカルおよびネットワーク・ベースの情報にシームレスなインタフェースを提供する。
【００８０】
注文処理モジュール（order processing module）（ＯＰＭ）９０３は、サービス・スポンサからのまたポリシおよび基本設定モジュール（policy & preferences module）（ＰＰＭ）９０４によって作成された注文の処理を指示する役割を持つ。ＯＰＭ９０３は、注文要件を達成するために必要なＰＳモジュールと対話する。ＯＰＭ９０３は、また、スポンサからの照会に応えることができるように注文の状況を追跡することが好ましい。
【００８１】
登録、認証および許可モジュール（registration, authentication, & authorization module）（ＲＡＡＭ）９０５は、システムのセキュリティを常に維持する役割を持つ。ＲＡＡＭ９０５は、ＰＳのすべてのユーザに権限を与え、ユーザが特定のトランザクションを実行できるようにすることが好ましい。内部ユーザと外部ユーザをすべて適正に登録する役割を持つ。ＲＡＡＭ９０５は、エンティティ・モジュール９０２と一緒に作業して必要な情報を得ることによってこれを行う。ＲＡＡＭ９０５は、また、サービス顧客モジュール９０１と注文処理モジュール９０３と一緒に作業してトランザクションのセキュリティに関連するアーティファクトを分離する役割を持つことが好ましい。
【００８２】
サービス定義モジュール９０６は、ＰＳ９００から提供されるすべてのサービス１４０に関するすべての定義情報を維持する役割を持つ。含まれる情報の例は、バージョン情報、ファイル構成、サービス相互関係、製品系列サポートである。
【００８３】
サービス開発者インタフェース・モジュール９０７は、サービスを開発し、分散し、更新するサービス開発者の作業を支援する役割を持つ。サービス参加者インタフェース・モジュール９０８は、すべてのユーザと対話して、サービス・ライフサイクルおよびサービス・トランザクション情報を適正なリソースに導く役割を持つ。
【００８４】
実施形態は、一般的なソリューションとして例えば規則や制約などのソフトウェア計算技術を利用して、サービス・ポリシをフレキシブルにモデル化し、開発し、検査する。全体的に、対応決定自体は、それほど重要ではない。すなわち、サービス１４０を必要とする装置１１０の場合、ＰＳ９００は、許可されるかどうか、装置１１０の動作パラメータ情報（モデル・タイプ、ＯＳバージョンなど）と互換性があるバンドル（インストールされるサービスを構成するコード・ファイルの集まり）があるかどうか、複数のバンドルがある場合にそのうちのどれを選択すべきか、またサービス１４０のパラメータ設定値（ある場合）が何でなければならないかを決定する。一般に、実施形態において、以上の問題を解決するために使用できる「ビジネス・ルール」を実現するコードを作成することはできない。コーディングは、規則の変更ごとに必要になり、規則は、ポリシ作成者によって直接調査されず、それぞれの問題が他のものと分離可能であると仮定する。さらに、上記のすべての問題の答えを決定する１つのポリシ作成者がいると仮定する。したがって、実施形態において、代替のソリューションが提供されなけばならず、また提供される。
【００８５】
適切な制約または規則システムの導入により、有利な恩恵が提供される。コーディングは、「規則」がより高い抽象化レベルで入力されたときに大幅に減少する。さらに、規則は、コンピュータまたはプログラミングに満足できないポリシ作成者によって調査可能である。さらに、それぞれの問題に関係する制約および規則として実現される知識を容易に組み合わせることができ、分離可能性について心配しなくてもよい。制約と規則は、以上の問題の結論に関与する多数のポリシ作成者の存在をサポートする。価値連鎖に関与する様々なグループに基づく規則と制約の干渉は、より容易に識別し解決することができる。
【００８６】
状況によっては、ポリシ・ベースの知識を使用して正確なバンドルとパラメータを識別する対応サーバ９００の能力が有利なことがある。例えば、この能力は、ＰＳ９００が追加サービス要求を受け取り、前述の問題に対する答えを計算する必要があるときに適用されることが好ましい。さらに、ＰＳ９００は、この能力を、任意のサービスのポリシ作成者がポリシ知識を更新したときに使用する。ＰＳ９００は、ＰＳ９００に積極的に接続された既存の関連装置への変更、追加、または削除の影響を計算することができる。次に、ＰＳ９００は、変更の目的を達成するために影響を受けた装置１１０に対して必要な変更要求を生成して、将来のすべての追加サービス・トランザクションの変更を使用することができる。ＰＳ９００が、装置１１０からの構成変更の通知を受けると、ＰＳ９００は、その変更のために装置のサービス１４０および／またはパラメータを変更しなけばならないかどうかを決定する。必要は場合は、ＰＳ９００は、ポリシ知識からの要求に応じて装置１１０の変更要求を生成することができる。
【００８７】
ポリシ設定者は、規則の使用により、内部顧客要件または外部顧客要件に基づいて均一なサービス・バージョンまたはパラメータ設定値を定義することができる。この均一性は、ユーザ・レベル、サイト・レベル、装置カテゴリ、または他の関連グループで定義することができる。
【００８８】
要するに、サービス加入および配置方法は、対象となるサービス提供物１４０のユーザまたはユーザＤＭＡ１２０による識別と、そのようなサービスの活動化の要求を含む（ブロック５０１）。エッジ・ホストによる計画的な確認の間、あるいはその目的のための特別な接続の間、ＤＭＡ１２０は、供給業者システム３００に、対象および要求された活動化に関するメッセージを送る。供給業者システム３００は、エッジ・ホスト４１０からメッセージを取り出し、ビジネス・ルールおよび作業プロセスを適用してユーザ適格性を決定する（ブロック５０２）。ユーザが、承認された場合、供給業者システム３００は、エッジ・ホスト４１０に、要求されたサービス１４０を追加できることを通知する（ブロック５０３）。次に、ＤＭＡ１２０は、エッジ・ホスト４１０に連絡して、サービス１４０を追加することができるというメッセージを受け取る（ブロック５０４）。次に、ＤＭＡ１２０は、サービス１４０を作動させ、必要に応じて、そのサービスをダウンロードしかつ／またはインストールする（ブロック５０５）。次に、新しいサービスが、配置され、動作する（ブロック５０６）。
【００８９】
サービスの販売は、複数のチャネルで行うことができる。このプロセスは、スポンサ組織（サービス供給業者）によって所有されることが好ましく、スポンサ組織が選択した方法で行われる。これは、例えば、必要に応じて装置から行うことができる。
【００９０】
特定のユーザが所定の装置上のサービスを使用可能にしたいことがスポンサ組織に通知された後、実施形態は、スポンサ組織が、特定のサービスにとって妥当なビジネス・モデルに従わなければならないビジネス・ルールおよび請求書発行／納品書発行プロセスを適用することを規定している。スポンサ組織が、指定されたサービスをユーザに提供することを装置に許可できると決定した場合、スポンサ組織は、エッジ・サーバ上の共通サービス注文／エントリＡＰＩを使用して正式に注文を出す。これは、実施形態において、所望のサービスの配置および構成を開始することができるメッセージを生成することができる。
【００９１】
メッセージは、送出のために待ち行列に入れられることが好ましく、プロセスは、メッセージが送出されるまで待つ。要求装置または装置プロキシが、注文メッセージを取得した後で、システムが構成され、必要に応じて追加のソフトウェアがダウンロードされ、新しいサービスが開始される。サービス・スポンサは、実施形態によるシステムにより、サービス・スポンサが決定するどの基準が必要かに基づいて、必要に応じてサービスをオン・オフできることが好ましい。サービスは、装置に依存しないように作成されることが好ましい。装置モデル・エージェントによって提供される共通情報モデルは、実施形態において、共通データおよび方法の装置に依存しない装置を提供する。すべてのユーザが同じ要件を持つとは限らないので、サービスは構成可能である。構成可能なサービスは、必要とされる可能性のある要件および操作の変化に対応することを可能にする。サービスは、現地に既に配置済みの装置によって新しいサービスをユーザに迅速に配置できるように動的にロードすることができる。また、サービスは、最初に配置された後で管理を可能にするライフサイクルを有する。ライフサイクルのトランザクションの例には、サービスの追加、サービスの削除、サービスの修正、サービスの同期、装置登録、およびプロキシ登録があるが、これらに限定されない。
【００９２】
実施形態において、ＤＭＡ１２０は、共通に配置されたサービス１４０において、装置１１０の組み込まれた計算能力、データ、および機能にアクセスし使用できるように定義される。組み込まれたエージェント１２２とサービス・プラットフォーム１２４により、実施形態は、システム１全体に入るサービス１４０のローカル動作をサポートすることができる。これは、サービス提供物のサポートにおいて、共通接続性、サービス・マネージャ、共通データ・アクセスおよび方法、およびサービス提供者／供給業者への確実な通信を提供する。
【００９３】
前述のシステム、構成要素、方法および実施形態の場合、システムを配置することができる方法はいくつかある。この配置のフレキシビリティは、このシステムの大きな利点であり、構成要素の詳細な設計およびシステムが従う挙動モデルと密接な関係がある。抽象化とモジュール性が定義された実施形態によって、そのような配置オプションをすべて同時にインスタンス化することができる。多くのユーザ装置において、完全な有効範囲を保証するために複数のオプションを配置することが可能となる。図４から図９と図１１は、本発明によるシステムの可能な配置オプションを表すいくつかの例示的な実施形態を示す。
【００９４】
図４に示した例示的な実施形態の配置Ａは、Ｘｅｒｏｘ（登録商標）社などのいくつかの会社から現在出荷されているスマート装置の好ましい実施形態である。これは、サービス１４０の配置をサポートするためにユーザに要求されるインフラストラクチャの量を制限することができ、最も単純な実施態様を提供する。ユーザの環境では追加のハードウェアまたはソフトウェアを導入する必要はないが、装置１１０は、サービス・プラットフォーム１２４を含むＤＭＡ１２０の機能を備えていなければならない。この実施形態は、装置ソフトウェアをアップグレードするか、別の方法を使用して現場の装置にＤＭＡとサービス・プラットフォームを提供しない限り、現地に既にある多数の装置に対応することはほとんどできない。ＤＭＡを介した装置とバックオフィス・ホストとの間の通信は、実質的に物理的媒体から独立しているが、好ましい実施形態は、ユーザのネットワークおよびユーザのインターネット・アクセスを使用して、供給業者のホスト・システムに接続する。当然ながら、例えばローカル無線、長距離無線、電話、無線電話、衛星電話などの他の通信方式を使用することもできる。
【００９５】
図４に示したように、各装置１１０は、それぞれのＤＭＡ１２０を含み、ＤＭＡ１２０によって促進される自分のサービス層１４１で自分のサービス１４０を実行する。管理およびその他のアプリケーション２２０は、ユーザの環境１００にあってもよくあるいは他の場所にあってもよい別の装置２００上で使用することができる。装置１１０は、ＨＴＴＰ、ＨＴＴＰＳ、ＳＯＡＰなどのウェブ・サービス２５０を使用して、供給業者３００およびその中のサービス・ホスト３１０と通信することが好ましい。サービス・ホスト３１０は、サービス３２０と、適切なときにＤＭＡ１２０からの通信を評価しサービス１４０を配置することができるホスト・システム３４０を含む。
【００９６】
図５に示した別の例示的な実施形態の配置Ｂは、既に現場にある装置と、必要な技術が組み込まれていないサードパーティ製の装置が、装置サービスをサポートできるようにする。そのように複数の装置を処理することができるが、この説明は、簡略化するためにそのような１つの装置に注目する。この場合、比較的小さなアドオン構成要素１１５が、装置１１０に追加される。アドオン構成要素１１５は、アドオン構成要素１１５が内部データと装置１１０の機能にアクセスできるようにするために必要なソフトウェアおよびＤＭＡ１２０ならびに装置１１０への１つまたは複数の接続を含む。アドオン装置１１５が接続された場合、装置／アドオン構成要素の組み合わせは、サービス・インフラストラクチャおよびバックオフィス・システムの他の部分からは、図４に示した配置Ａのように、完全に使用可能にされた装置のように見える。これは、レガシおよびサードパーティ製造設備の実施形態による装置サービスを提供する。この場合、アドオン構成要素１１５は、ＤＭＡ１２０とそれに付随するサービス環境１２４により、図４の配置Ａのようにウェブ・サービス２５０を介して供給業者３００と通信する。
【００９７】
図６に示した第３の例示的な実施形態の配置Ｃは、アプリケーション２２０が、装置１１０のうちの少なくともいくつかのサービスを実行するプロキシとして動作することができるプロキシ構成を使用する。必要なソフトウェア成功因子のない装置１１０に、ＤＭＡ１２０やプラットフォーム１２４などが組み込まれている。しかしながら、装置のサービス・プロキシとして働くアプリケーション２２０は、例えばＬＡＮ、電話、無線、その他の通信媒体などの装置１１０と通信することができる。基礎的なプロキシは、選択された１組のサービス１４０のサービスＡＰＩ１４０を実現するが、完全なＤＭＡ１２０と装置１１０自体への標準的な動的サービス配置方法を使用しないことが好ましく、それは、そのような機能をレガシ装置でサポートすることができないためである。この配置は、また、単純なプロキシと装置との間の接続の豊かさによって制限され、データまたは機能にリモートでアクセスできない場合には、それらを必要とするサービスを配置することができない。
【００９８】
図７に示した第４の例示的な実施形態の配置Ｄは、プロキシ構成のより有利な形態である。この実施形態は、必要な組み込まれたソフトウェア成功因子（すなわち、ＤＭＡ１２０）なしに装置を使用可能にするが、例えばＬＡＮ、電話、無線などの他の方法で通信して、サービス配置システムに関与することができる。装置１１０は、装置１１０のサービス・プロキシとして働く１つまたは複数のアプリケーション２２０と通信する。サービス・プロキシは、サービス・プロキシと通信する各装置１１０のＤＭＡ１２０をホストすることができるＤＭＡ対応プロキシである。さらに、サービス・プロキシは、通信する装置１１０のＤＭＡ１２０を管理することができる。これにより、サービス１４０は、サービス・プロキシ上で、サービス１４０が装置１１０自体の上で直接動作しているかのようにまったく同じように動作することができる。また、これにより、追加のローカル・アプリケーションを、ＤＭＡ１２０ならびに各システムのデータおよび機能の共通情報モデル表現を利用することができるサービス・プロキシ上に作成することができる。これは、アプリケーションを大幅に単純化することができ、それは、アプリケーションを、各装置に固有の実施態様から隠すことができ、ＣＩＭ内のデータと方法の共通表現に構成するだけでよいためである。これは、ＣＩＭとＤＭＡに対して作成されたときにサービスが獲得するのと同じ利点である。さらに、ＣＩＭとサービスの複数のインスタンスを管理することができるＤＭＡの一部分を、一旦インスタンス化し、複数の装置のＤＭＡプロキシを管理するために使用することができる。すなわち、すべてのプロキシ化装置に関して完全なＤＭＡを複製する必要はなく、これにより、この実施形態が、接続された装置のすべてのＤＭＡを１つのサーバ上に単純にドロップするよりも効率が高くなる。
【００９９】
サービス・プロキシの実施形態のもう１つの態様は、ＣＩＭとサービスの複数のインスタンスを管理することができるＤＭＡの部分を一旦インスタンス化し使用して、複数の装置のＤＭＡプロキシを管理することができることである。したがって、すべてのプロキシ化された装置について完全なＤＭＡを複製する必要はなく、むしろ、複数の装置に１つのＤＭＡを使用することができる。これにより、１つのサーバ上に各装置ごとの１つのＤＭＡを単純にドロップするよりも、配置の効率が高まる。
【０１００】
特定のバージョンの配置ＣおよびＤにおいて、実施形態は、パーソナル・コンピュータに直接接続されたプリンタの装置プロキシの配置をカバーする。プロキシをユーザのコンピュータ上にホストすることができ、また、プロキシが対話する装置は、パラレル・インタフェースを介して接続されたプリンタなどのプリンタである。実施形態において、プロキシは、ＤＭＡまたはサービス・インタフェースを実装するデータの追加ソースとして、直接接続されたプリンタの印刷ドライバに接続することもできる。コンピュータは、ＤＭＡをホストすることができ、装置への直接接続と印刷ドライバや他のアクセス機構を介したローカル装置によってサポートされるという点で、直接接続されたプリンタは、サービスおよびシステム管理の観点からネットワーク接続されているように見える。
【０１０１】
図８に示した第５の例示的な実施形態の配置Ｅは、図６と図７に示した例示的な実施形態の一部分を変形したものを含む。サービスは、インターネットで広がる実施形態と類似の形で、ローカルに、すなわち実質的に自己完結的なサイト内で提供することができる。そのような実施形態は、ＤＭＡ１２０の抽象化を使用して、ローカル装置１１０へのより一貫した管理とサービスを提供する実施態様を可能にする。これには、バックオフィス・サービス提供者３００への接続がないが、サービス１４０は、セキュリティのために、ユーザに固有でもよく単純に自己完結されてもよい。この場合、ローカル・サービス１４０および装置１１０の管理を、すべての装置１１０の集中的な場所からより現地化されたドメインに移すことができる。ユーザは、例えば、そのような実施形態において、必要に応じて、アプリケーション・サーバと、ユーザのセキュリティ要件によってエッジ・ホストとを含む、バックオフィスの等価物をそのイントラネット上で動作させることによって、供給業者の役割を負うことができる。これは、サードパーティによって提供された場合にそのようなシステムの維持とサポートの複雑さを高めるが、抽象化が定義された場合には有用な構成が可能である。
【０１０２】
さらに例示的な実施形態の図９の配置Ｆは、使用可能にされた装置１１０から通信を受け取る複数のアプリケーション・サーバ３１０および／または複数のエッジ・ホスト４１０を使用可能にする。配置Ｆは、例えば配置Ａ、Ｂ、ＤおよびＥの要素を結合した実施形態である。サービス１４０は、適切なエッジ・ホスト４１０を介して適切なアプリケーション・サーバ３１０と適切な方法で連絡するためにサービス１４０に必要なすべてのものを示すように作成することができる。さらに、エッジ・ホスト４１０が装置１１０を接続するサービス・ホスト３１０は、任意の特定のサービス・ホストまたは供給業者３００に限定されず、エッジ・ホスト４１０から提供されるサービスＡＰＩが接続を可能にする限り、サービスを提供する適切などの関係者にも接続することができる。
【０１０３】
「装置モデル・エージェント」
例えば図１０の概略図において、前に考察し示したような装置モデル・エージェント（ＤＭＡ）１２０は、実施形態によるエンド・ツー・エンド・システム１の特権を与える構成要素である。ＤＭＡ１２０を、装置１１０、アドオン・モジュール１１５および／または装置／サービス・プロキシに組み込んで、サービス１４０が動作する共通装置モデル１２２、ＣＩＭ ＡＰＩ１２３および装置サービス環境１２４を提供することができる。ＤＭＡの役割は、その寿命全体にわたって装置を取り巻く業務プロセスおよびサービスに積極的に関与する能力を装置１１０に提供することである。これは、分散管理タスクフォース（ＤＭＴＦ）からの共通情報モデル・オブジェクト・マネージャ（Common Information Model Object Manager）（ＣＩＭＯＭ）の態様と、組み込まれた動的なサービスの操作および管理の新しい環境の態様とを組み合わせる。エージェントは、サービスをローカルに操作し、ＣＩＭにおいて提供された情報を管理する役割を持つ。エージェントは、装置、サービス（ローカルなサービスと、ネットワーク接続された環境の全体にわたって分散されたサービスの両方）、および他の分散されたシステム構成要素と対話する。
【０１０４】
ＤＭＡは、ＤＭＴＦによって指定されているような装置と独立ＣＩＭ ＡＰＩを提供するが、装置と独立のサービスＡＰＩも提供する。ソフトウェア・エージェントのように、ＤＭＡは、ローカルに行われるかまたは他の分散された構成要素との対話によって行われる自主的挙動と適応的挙動で連動することができる。ＤＭＡは、また、例えば、この場合も装置および環境におけるイベントにローカルにまたは分散的に反応することができ、実施形態において、サービスとアクションの自主管理に関わることができる。好ましい例示的な実施形態において、ＤＭＡの装置独立性は、例えばＪＡＶＡやＪ２ＭＥ小フットプリントＪＡＶＡ規格の使用によって拡張される。当然ながら、ＤＭＡは、この特定の実施形態に限定されず、すべての特徴を提供する様々な程度の複雑さと難しさを備えた任意の適切なソフトウェア構造に組み込むことができる。ＤＭＡのこの例示的な実施形態は、Ｊ２ＭＥ Connected Device ConfigurationをFoundation Profileと共に使用して、多数のリソースを有する大きなシステム構成要素から限られたリソースを有する小さいシステムまで、最も広い範囲の装置を使用可能にでき好都合である。この場合も、装置モデル・エージェントは、この実施形態に限定されず、装置の必要に応じて、ＪＡＶＡやその他のプログラム言語の変形物において多くの他の実施形態が可能である。Ｊ２ＭＥ環境は、ＤＭＡソフトウェアが、装置および製品プラットフォーム全体にわたって装置に独立かつ再使用可能であることを保証することができる。Ｊ２ＭＥは、また、ネットワーク接続され分散されたシステムのサポート、組み込まれたセキュリティ機能、およびコードの動的ダウンロードおよび操作のサポートを提供する。
【０１０５】
実施形態は、例えばＪＡＶＡやＪ２ＭＥ小フットプリントＪＡＶＡ規格などのプラットフォームに依存しない規格の使用によるエージェントの装置独立性の拡張を含むことが好ましい。当然ながら、エージェントは、そのような実施形態に限定されず、すべての特徴を提供する様々なレベルの複雑さと難しさを備えた任意の適切なソフトウェア構造に組み込むことができる。Ｊ２ＭＥConnected Device ConfigurationをFoundation Profileと共に使用するエージェントの実施形態は、多数のリソースを有する大きなシステム構成要素から、限られたリソースを有する小さい組み込みシステムまで、広い範囲の装置を使用可能にすることができる。他の多くの実施形態は、エージェントが組み込まれるかまたはエージェントが提供する装置によって、必要に応じてＪＡＶＡやその他のプログラム言語の変形物を使用可能である。Ｊ２ＭＥ環境は、エージェント・ソフトウェアが実質的に装置独立でありかつ実質的に装置および製品プラットフォーム全体にわたって確実に再使用可能なままにできるので、好ましい環境である。さらに、Ｊ２ＭＥは、ネットワーク接続された分散システムと、組み込みセキュリティ機能と、コードの動的ダウンロードおよび操作のサポートを含む。
【０１０６】
以上説明した利点に加えて、ＤＭＡは、複数の異なるデータ・ソースを共通提供者ＡＰＩの後ろに隠すことができる。これは、さらにソフトウェア・エージェントからの装置の詳細を抽象化する。実施形態において、個別の４つのデータ・ソースを、共通提供者およびＣＩＭの後ろにひとまとめにすることができ、それによりサービスは、データ・ソースの詳細を知る必要がない。例えば、ＥＰＳＶ、ＰＷＳ、ＣＡＮバス、およびＷｅｂ ＵＩにおいて、データをこの方法で管理することができる。また、装置モデル・エージェントに含まれる提供者層とＣＩＭを、所定の製品または装置のために容易にカスタマイズできるようにする実施形態において、１組のツールを提供することができる。これにより、装置モデル・エージェントを採用または維持するプログラムが、データ・ソースへのＣＩＭ要素のマッピングだけを対象とし、装置モデル・エージェント全体の管理を対象とする必要がないので、再使用と速度のリリースが促進される。
【０１０７】
システム構成要素のエンド・ツー・エンド・アーキテクチャのイネーブリング機能は、実施形態において、様々な分散構成要素の間で使用される通信方法の適切な抽象化を含む。この抽象化は、物理的接続機構ならびにセッション・レベルまでのプロトコルに適用されることが好ましい。両方のレベルにおけるそのような抽象化は、通信方法の詳細を分散構成要素から隠すのに役立ち、それにより、それらの構成要素は、サービスの動作に集中することができ、構成要素は、通信媒体またはプロトコルの変化から分離される。例えば、これにより、システムは、サービス自体がどれが使用されるかに注意することなく、無線リンク上で電子メールを使用したり専用のイーサネット・リンク上でウェブ・サービスを使用したりすることができる。
【０１０８】
このタイプの抽象化は、装置にとっては新しいものであり、いくつかの重要な利点を提供する。それは、任意の所定のユーザに、システム構成要素の配置のフレキシビリティを提供することである。セッション層までの物理接続とプロトコル接続の任意の所定の組み合わせから予想することができるサービス品質の情報を伝えることができる。システムは、様々な構成のサービス品質を監視して、特定のユーザに提供される所定のサービスが必要とするサービス品質を提供する通信リンクの有効性を評価する構成要素を、ホスト／バックオフィス側に備えることができる。これは、エンド・ツー・エンド・システム全体のなかの対応部分と自己監視部分の要素である。
【０１０９】
通信の抽象化は、また、いくつかのフォルトトレランスを提供する。１つの接続機構が、なんらかの理由で停止した場合、通信モジュールが、それを検出し、失敗したその接続を、サービス品質が変化した可能性があるという事実以外をシステムの他の部分が知ることなしに、別の動作している接続と置き換えることができる。
【０１１０】
実施形態において、代替として、サービスは、装置またはプロキシ内に「ハードコード」されてもよい。すなわち、サービスの追加および削除と関連した多数の管理機能が必要ない。装置で動作するサービスの組み込み部分は、分散構成要素間のウェブ・サービス・トランザクションに従わなければならない。これにより、バックオフィスは、システム内の完全な動的サービスと同じように「ハードコード」されたサービスを有効に処理することができる。
【０１１１】
ハードコードされたサービスは、バックオフィス加入によって使用可能にすることができる。これにより、サービス提供者は、任意の所定の装置上で使用可能にされた特定のサービスを制御することができ、これは、サービス提供者に、提供されたサービスが業務ニーズに基づいてどのように市場に広まるかを決定するフレキシビリティを提供する。例えば、サービスは、パッケージの一部でもよく、無料で提供されてよく、有料で提供されてもよく、更新を必要としてもよく、完全なサービス提供のために別のトランザクションを必要とするトライアル・ベースで提供されてもよい。
【０１１２】
ハードコードされたサービスは、特定の要件のための共通の基本的挙動と一定の拡張機能を共用することが好ましい。サービスは、一緒に動作するが、インテリジェント・プロキシ上および／またはバックオフィス・サーバ内の組み込みプラットフォームにおいて装置自体上で動作する構成要素を有することが好ましい。これらのサービスは、ハードコードされるが、供給業者／サービス提供者のバックオフィス内のサービス・ライフサイクル管理システムによって構成し管理することができる。
【０１１３】
実施形態が使用することが好ましい規格のタイプには、分散管理タスクフォース（ＤＭＴＦ）、ウェブ・ベース企業管理（Web Based Enterprise Management）（ＷＢＥＭ）、および共通情報モデル（ＣＩＭ）がある。前に説明したように、ＣＩＭは、実施形態に、サービスの再使用を可能にする装置モデルおよび抽象化を提供する。さらに、実施形態は、ウェブ・サービス、ＸＭＬ、様々なバージョンのＨＴＴＰ、およびＳＳＬを使用する。また、実施形態は、例えばVeriSignからのサーバ側証明書を使用することができ、この証明書は、ファイアウォールとインターネットを横切る通信を使用可能にする。装置およびバックオフィスにおけるアプリケーション環境を使用可能にするために、実施形態は、例えば、Java 2 Micro Edition （Ｊ２ＭＥ）、Insignia CorporationによるEmbedded Virtual Machine、Java 2 Enterprise Edition（Ｊ２ＥＥ）、BEA WebLogic 7.0 Application Server Technology Suite、およびOracle8iを使用することができる。当然ながら、これらは、単なる例であり、必要に応じて他の構成要素を使用することができる。さらに、現在予測されておらず実施形態のシステムに追加することができる新しい構成要素が開発される可能性が高く、そのような構成要素は、実施形態の範囲内にある。提供されるサービス、そのライフサイクル、および特定の製品のＤＭＴＦ ＣＩＭの拡張機能は、実施形態の範囲内にある新しい技術の例である。
【０１１４】
実施形態は、さらに、既に配置済みのシステムへの新しいサービスの迅速な追加および配置を可能にする。例えば、新製品の発売後すぐに、現地で最初の３ヶ月の動作から学んだ教訓に基づいて新しい診断サービスが開発される。このサービスの正確な性質と挙動は、製品が発売されたときは予想できず、したがって診断サービスは、発売された製品には含まれていなかった。実施形態により、そのような診断サービスを、導入された装置に実質的にいつでも追加することができる。
【０１１５】
実施形態は、新しい「サービス・バンドル」が含まなければならないサービス・モデルと内部仕様を意図している。したがって、サービスの権限と構成情報の他に現地の既存の装置に新しい機能を追加しなければならない場合に、新しいコードをダウンロードすることができる。この機能は、実施形態に従って、新しい機能を容易に受け入れるように設計された装置に組み込まれたサービス・プラットフォームと共に使用することができる。さらに、実施形態の組み込みサービス・プラットフォームと共に使用されるとき、ＤＭＡに組み込まれたＣＩＭによって装置独立の抽象化が提供されるので、プラットフォーム全体に新しいサービスの新しいコードを再使用することができる。そのようなプラットフォームのない装置では、新しいコードを、例えば現地でパッチを当てるかアップグレードするためのさらに特殊なソフトウェア・ダウンロード・サービスとしてさらに追加することができるが、そのようなサービスを使用可能にするコードは、ほとんどプラットフォーム固有であり、したがってあまり再使用できない。
【０１１６】
実施形態のこのシステムは、診断ルーチンや他のサービスを、装置のプラットフォームにとってきわめてフレキシブルな方法で提供する。そのような使用可能にされた装置は、バックオフィスのサービス提供者にとって、実施形態による他の各ＤＭＡ対応装置と同じように見える。さらに、装置内部のプラットフォーム上でローカルに動作する装置系列のサービスはすべて、インテリジェント・プロキシを介してではなく供給業者システムに直接通信することができる。
【０１１７】
配置のもう１つの変形は、ＤＭＡを製品自体に完全に組み込むことである。この実施態様は、それらが両方ともＤＭＡ対応プラットフォームであるという点で、例１の実施態様ときわめて類似している。しかしながら、この例では、小フットプリントＤＭＡプラットフォームは、製品に組み込まれ、印刷機構インタフェース・プラットフォーム（Print Station Interface Platform）（ＰＳＩＰ）と組み込み型装置コントローラの両方と通信する。その製品は、小フットプリント・システムによって必要とされる限られたリソースを受け入れ可能であり、必要なインタフェース構成要素の配置と一体化は、比較的容易である。
【０１１８】
再利用可能なＤＭＡは、既にＪＶＭを有するシステムへの「臨時収容所（drop-in）」である。小フットプリントＤＭＡは、システム・リソースを消費するものではなく、そのようなプラットフォームの実施を大幅に高速化することができる。
【０１１９】
「自動メータ読取り」
実施形態に組み込まれた配置フレキシビリティを使用するもう１つの例は、エンド・ツー・エンド・サービスの観点からシステムを見ることによって理解される。この場合、サービスは、自動メータ読取り（automated meter reads）である。このサービスは、ループ内に人間を入れることなく、一般に電話、ファックス、電子メールまたはウェブ・エントリによって受け取った毎月または４半期ごとのメータ読取りを取得することを重視している。これは、読み取りの精度と適時性の両方を高め、ユーザの時間を節約し、供給業者に納品書発行と請求書発行を改善させることができる。
【０１２０】
装置から要求されるデータが、小さくまた大部分が既に使用可能であるため、インテリジェント・プロキシを使用することができ、すべてのＳＮＭＰ対応製品の関与を容易にすることができる。これは、ＤＭＡ対応であるが完全にはＳＮＭＰに準拠していない装置と共に使用され、すなわち、広い有効範囲を簡単に達成できる。この場合も、この事例での抽象化とシステム・モジュール性が重要である。バックオフィス・システムは、装置が供給業者とどのように接触したか（直接またはプロキシを介した）を知る必要がなく、必要なものは装置の通し番号だけであり、予定されたときにメータ読取りを要求することができる。装置のサービスへの関与を可能にする方法と、バックオフィスのサービス提供者から要求を出す方法をこのように分離することは、配置フレキシビリティを提供する際に利点である。
【０１２１】
「早期警報システム」
実施形態において、現地でのより多くの試験をサポートするために、レポート・システムやリモート監視サービスやその他のリモート・サービスが組み合わされて、１組のツールが構成される。基本的なシステムとデータ収集サービスは、人間の観察と報告に依存するデータ収集システムを補うことができる。同時に、システムの組み合わせは、設計チームが製品の問題解決活動を基本とすることができるより大きく統合された知識を提供する。さらに、現地の装置から収集したデータの共通モデルは、プラットフォームをまたがって使用することができる報告ツールおよび基本パフォーマンス報告機能を配置する機構を作成する。
【０１２２】
「リモート制御および装置サービスによるプレミアム・リモート・アシスタンス」
実施形態の基本原理の１つは、装置自体が自分のライフサイクルとサポートに積極的に関わらなければならないことである。これは、トラブルまたは状態を報告するいくつかの状況において有効である。これは、現地のシステムが良好に動作し続けるようにするために、システム性能を監視しソフトウェアまたは構成を自動的に変更することができる装置に組み込まれた診断エージェントと共に動作することもできる。しかしながら、ユーザが経験する多くの問題は、装置の故障と関連したものと同じくらいユーザの問題と操作エラーに関連したものがある。さらに、周知のように、記録装置は、複雑な電気機械システムであるため、必ずしも遠隔で修復できるとは限らない。
【０１２３】
現地の装置の操作サポートのニーズに対応し、現場のオペレータと共に作業する新しい方法を支援するために、この実施形態では、リモートＵＩと人間対人間のサポート・システムが組み合わされている。サポート自動化ソリューションは、高品質なサービスとサポート提供物の一部分を補うことができる。これは、データ収集とリモート監視を自動化し、また前述の多くのリモート・サービスを提供する。また、この組み合わせにより、追加の訓練、問題解決およびソフトウェアの微調整が必要とされるときに、共用ＵＩによって装置のオペレータと一緒に直接作業してオペレータを支援する優れた方法が提供される。
【０１２４】
「接続トレードオフ」
図４１に、ユーザ・サイトの装置とバックオフィスの間の通信リンクのいくつかの例示な選択肢を示す。Ａ、ＢおよびＣと示した３つの主な選択肢がある。選択肢ＡとＣだけが、装置と供給業者のバックオフィス間の接続を独力で完成させることに注意されたい。選択肢Ｂは、供給業者に戻るリンクを完成させるために、ＡまたはＣに接続する必要がある。
【０１２５】
各選択肢の長所と短所のまとめを表２に示す。
【０１２６】
【表２】
2004220556.tif 000004
【０１２７】
接続選択肢はすべて、異なる手段で供給業者に入る場合でも、同じバックオフィス・インフラストラクチャを再使用することが好ましい。
【０１２８】
選択肢は、グループとしては、様々なユーザ要件を満たす配置のためのフレキシビリティを高めることができるので、すべての選択肢が魅力的である。好ましい接続方法は、実現可能なとき、選択肢ＡのＬＡＮとインターネットを介した有線接続である。これは、最小の開発投資と最小の作業費用の選択肢である。短期間ではこれが特に有力であるが、サービスの価値が検証されており、リソースは、初期のサービス開発に焦点を合わせることが必要とされ、装置に接続する追加の方法を提供しない。しかしながら、この選択肢だけを追求すると、初期にサービスから外された未接続の装置には対応されない。当面の間、各サービスは、提供物に未接続の装置を手作業で含める方法を検討しなければならない。
【０１２９】
次に好ましい接続方法は、選択肢Ｃの携帯電話または双方向ページャの技術による長距離無線である。システムは、この構成で、有線装置によってシームレスに動作することができ、この機能を使用可能にすると、何かユーザ問題が発生したときにその問題を解決できるようになる。しかしながら、多数の製品の全体にわたって大規模に無線機能を配置した状態ではいくつかの問題がある。例えば、現地のきわめて幅広い多数の製品と互換性を持つようにいくつかの異なるアドオン・モジュールを開発することは、ほとんどのシステムが、詳しい装置データおよび動作にアクセスする同じインタフェースを持たないため、コストが高くなる可能性がある。さらに、無線接続と通信コストを追加する追加の費用は法外に高価なことがあり、その接続を使用していくつかのサービスが利用できるようになる。単純でより容易に配置可能な無線構成には、提供できるサービスの数とタイプに固有の制限があり、そのためコストの正当化が難しい。最終的に、無線接続が、供給業者／サービス提供者または別の関係者がファイアウォールを回避してそのネットワーク上にある他のリソースにアクセスする可能性がある方法であるため、ユーザは、無線接続も有するネットワーク接続システムに対する心配を表明した。
【０１３０】
最後に、選択肢Ｂは、ローカル無線接続である。この方法は、ローカル無線接続技術が、我々のユーザ環境およびプリンタに具体的にどのように組み込まれるかにより使用することができる。
【０１３１】
「装置サービスのサポート・エンド・ツー・エンド・インフラストラクチャ」
ユーザ・サイトの装置をレガシ・システムと業務プロセスに接続するためのエンド・ツー・エンド・インフラストラクチャをサポートすることが必要とされる。図１と図２に示したエンド・ツー・エンド・システムは、エンド・ツー・エンド・インフラストラクチャの初期の例示的な実施形態である。これは、基本的なデュアル・モードの装置の関与（直接およびサービス・プロキシ経由）をサポートし、初期のサービス通信と加入モデルを使用し、例えば供給業者の環境でホストされたエッジ・サーバを介してサービス・データおよびアクションの共通エントリ・ポイントを使用する。エッジ・ホストは、追加の実施形態に適した形で区分することができるが、１つのシステム上に物理的にホストされてもよく、それにより、市場獲得と採用が増大したときに準備コストが最小になる。
【０１３２】
【表３】
2004220556.tif 000005
【０１３３】
表３に列挙した各分野は、技術的配置の分野あるいはサードパーティのＣＯＴＳシステムを取得し調査しなければならない分野を表す。これらの分野は、また、技術の十分な要件がまだ分かっていない分野を表す。
【０１３４】
前述のように、ユーザ支援自助プログラム（user assisted self-help program）、装置中心サービス（device-centric services）、および／またはＥＣＡＴのリモート監視をサポートするように元々設計されてない印刷製品は、そのような提供物が、初期出荷の高速化と製品の連続した成功に重要なことがある。そのような製品のニーズは、その状態に関してまたユーザがどのように使用してきたかに関して現地の装置から報告を毎日（または何らかの他の期間）受け取ることである。我々は、このサービスをリモート監視と呼んできた。これは、プログラム・チームが、現地で問題をより早期に識別できるようにし、販売、マーケティング、およびサポートがその出力も改善する重要な情報を提供する。
【０１３５】
これに対する１つのソリューションは、コントローラ上に、コントローラからＩＯＴにローカルに接続された装置中心サービス（Device-Centric Services）（ＤＣＳ）の装置モデル・エージェント（ＤＭＡ）１２０を提供することである。アドオン構成要素またはカスタマ・サポート・プラットフォーム（Customer Services Platform）（ＣＳプラットフォーム）１１５は、このニーズに対するソリューションである。ＣＳプラットフォーム１１５は、いくつかの既存のインタフェースのうちの１つまたは複数を介してＩＯＴにローカルに接続し、データおよび機能の見方を統一し、ローカルの機能の操作および管理をローカルＵＩに提供し、サービス・プラットフォーム１２４およびＡＰＩにリモート接続および装置中心サービスを提供する組み込みシステムの形を取ることができる。ＣＳプラットフォーム１１５は、装置中心サービスのフレームワーク内のサービス・プラットフォーム１２４によって使用可能にされるＤＭＡ１２０と組み込みサービス層１４１の両方の製品の実施形態である。
【０１３６】
図１２、図１６〜図１９および図２１を参照して、ＣＳプラットフォーム１１５は、ネットワーク接続された組み込み型パーソナル・コンピュータの形をとることができることが好ましい。さらに、アドオン構成要素は、ヘッドレス・ボックス（headless box）の形をとることができる。どの特定の形においても、アドオン構成要素１１５は、少なくとも１つの物理的インタフェースを介してＩＯＴに接続される。ＣＳプラットフォーム１１５のＵＩは、ローカル・ネットワーク上の任意のブラウザで使用でき、ＣＳプラットフォーム１１５の組み込みウェブ・サーバ１３０によって提供される。好ましい実施形態において、ユーザは、ＣＳプラットフォーム１１５のローカルＵＩとして、自分のＤＦＥ上のブラウザを使用する。ＣＳプラットフォーム１１５は、ローカル・ネットワーク・プロキシ、ファイアウォール・パスワード、ＤＮＳサーバＩＰアドレスなどを知るために、任意のブラウザが構成されるかのように、ネットワーク接続され構成されることが好ましく、それにより、インターネット４００上で使用可能なエッジ・サーバ４１０に接続することができる。動作するとき、ＣＳプラットフォーム１１５は、この接続を使用して、メッセージと命令を検査し、加入されたサービス１４０をサポートするために必要なデータも送る。エッジ・サーバ４１０は、装置サービスのエンド・ツー・エンド動作と関連した待ち行列、メッセージ、サービス、およびトランザクションを管理する。
【０１３７】
ＣＳプラットフォーム１１５は、マザーボード７０１と、Ｌｉｎｕｘなどの組み込みソフトウェア・オペレーティング・システム７０４を備えた低コストの組み込みパーソナル・コンピュータを利用したプラットフォームであることが好ましいが、他のオペレーティング・システムを使用することができる。アドオン構成要素１１５は、補助入出力やスタティック・メモリ・ボード７０２などのハードウェアによってカスタマイズすることができるが、そのようなカスタマイズは、コストを抑えるために最小であることが好ましい。構成要素１１５は、内部ハードウェア・プラットフォームが時間の経過と共に変化して、プラットフォームのコストを２／３に削減することができる最小汎用パーソナル・コンピュータの価格曲線に従うことができるように設計されている。内部記憶媒体７０３として、ハード・ディスク・ドライブ以上に信頼性を高めたコンパクト・フラッシュ（登録商標）・メモリなどのメモリを使用することができる。また、コンパクト・フラッシュ・メモリを使用すると、配置された新しいサービス１４０に追加の記憶リソースが必要な場合に、ＣＳプラットフォーム１１５をアップグレードするコストが下がり、さらに、コンパクト・フラッシュ・メモリは、システムにとって通常のハード・ディスク・ドライブと同じように見える。さらに、アドオン構成要素１１５に標準的なパーソナル・コンピュータ技術を使用すると、費用曲線に従う迅速な改訂が可能になり、標準的なアドオン技術（例えば、ウェブ・カメラ）がプラットフォームと互換性をもつことが容易になりかつ保証される。
【０１３８】
ＣＳプラットフォーム・アドオン構成要素１１５と装置のＩＯＴの間の接続パスの例には、Fuji XeroxプロトコルおよびインタフェースのElectronic Partner (EPSV) ７１２〜７１４、ＲＳ４２２および／またはＲＳ２３２シリアル・ポート７１５、７１６、サービス・ラップトップを装置に接続するためにカスタマ・サポート・エンジニアによって使用される接続ＰＷＳ７１７〜７１８、ＣＡＮバス接続７１９〜７２１、およびＵＳＢ（図示せず）がある。また、デジタル・フロント・エンドに対する独自のインタフェースのような追加のインタフェースを監視して、サービスおよびシステム管理活動のための追加のデータを提供することができる。特に、ＣＳプラットフォーム１１５は、そのような接続に限定されないように設計されることが好ましいため、他の接続も実施形態の範囲内にある。
【０１３９】
ルータ７３０を含み、ルータ７３０は、別の接続がアクティブになる場合に多数の情報を管理し、かついくつかの活動のプリエンプションを操作する役割を持つことが好ましい。したがって、通信は、通信がデータ破損問題なしに行われることができるように実現される。
【０１４０】
組み込みソフトウェア・システムは、前述の診断ルーチンなどのローカルにホストされた機能と、動的に追加し構成することができるサービスの両方をサポートしてフレキシブルな構成要素を提供することが好ましい。したがって、実施形態は、装置中心サービス・プラットフォームに基づいてＤＭＡ１２０を組み込んだシステム構成要素と、ＣＳプラットフォーム１１５がシステムのローカル・イネブラとして働いて装置中心サービスに積極的に関与できるようにする組み込みＪＶＭおよびウェブ・サーバとを意図している。
【０１４１】
組み込みＤＭＡ１２０は、デジタル・フロント・エンドおよび／またはＤＭＡ１２０を独力で実行する能力に関係なく、サービス１４０を装置１１０から直接提供できるようにする。これにより、装置１１０は、ＤＣＳサービス・モデルを介してサービス提供物に積極的に関与することができる。アドオン構成要素１１５は、また、システムのまわりに構成される新しいサービス１４０のプログラマチック・インタフェースを提供し、それにより、製品と一体化された迅速かつ頑強なソリューションが可能になる。さらに、アドオン構成要素１１５内にウェブ・サーバ１３０を含むため、ＩＯＴのインタフェースとしてのＣＳプラットフォーム１１５とリモート・サービス提供物の間での直接ウェブ・サービス・トランザクションおよびサービスが可能である。
【０１４２】
カスタマ・サポート技術者ではなく訓練されたユーザに合わせてカスタマイズされたＩＯＴ診断ルーチン７４０は、既にＩＯＴによって提供されている既定の診断ルーチンのための使い易くかつ国際化されたＵＩを提供する。診断ルーチンは、例えば、トナー密度レベルを最適化し、均一な画像品質を得ることができる（最高設定７４１）。提供することができる他のサービス７４２には、Belt Edge Learnがあり、これは、横方向の位置決めとベルト操作性能を改善するために新しい中間ベルトの縁に関して学習するルーチンである。Belt Edge Learnの目的は、２つのベルト・エッジ・センサを使用してベルトの動きを追跡することである。これらのセンサから受け取ったデータを使用し、ＩＯＴは、ベルト・トラッキング・ローラ／モータ／センサを使用して自動的に調整して、ベルトが内側寄り／外側寄りの動きなく回転するようにする。さらに他のサービスには、例えば、画像位置決めシステム上にＩＯＴにおいて見つかった完全な画像をセットアップするセットアップ・ルーチンであるＲｅｇｉＣｏｎと、システムによって印刷されるハーフトーン密度を調整するセットアップ・ルーチンであるＨａｌｆｔｏｎｅがある。ハーフトーン・パターンの印刷により、ページ全体にわたって一定の階調レベルがユーザ設定可能になる。ほとんどすべての画像品質欠陥がハーフトーン・パターンで現れるので、ハーフトーン・パターン自体は、問題を診断するために使用される。
【０１４３】
ＣＳプラットフォーム・アドオン１１５は、組み込みウェブ・サーバを介してウェブ・ベースＵＩを使用することが好ましい。これは、ＣＳプラットフォーム１１５自体のハードウェア・コストを削減し、代わりに、ほとんど必ず存在しかつネットワーク接続された装置１１０のデジタル・フロント・エンドと関連付けられたモニタ、キーボードおよびマウス・ハードウェアを使用する。また、これは、ローカル・ネットワーク上の適切なブラウザによって、他のネットワーク接続されたＰＣからアクセス可能である。そのようなＵＩは、時間の経過と共に新しいサービスおよび機能の高い操作性と拡張性を提供する。このアプリケーションだけのＧＵＩを提供するコストは、法外に高くなる。実施形態において、ウェブ・ベースのＵＩは、文脈依存ヘルプとコール・センタや他のサポート・サイトへのリンクを含むことができ、システムをより使い易くする。ＵＩは、例えば、ハードワイヤード・ネットワーク接続されたパーソナル・コンピュータを含むユーザのＬＡＮ上で接続された任意のブラウザで使用可能である。さらに、無線アクセス・ポイントが、ＣＳプラットフォーム１１５に直接接続されているかまたはユーザのネットワーク上に取り付けられている場合に、互換ブラウザを有する無線接続されたパーソナル・コンピュータまたは手持ち式コンピュータをＵＩとして使用することができる。
【０１４４】
実施形態の装置中心サービス・アドオン構成要素１１５は、事前にロードされ許可されたいくつかのサービスを有することが好ましいが、これは不要な場合もある。ＣＳプラットフォームは、加入したサービス提供物の装置中心サービス・モデルに従う。ＰＤＴは、基本のサービス・セットをイネーブルすることを決定した。さらに、構成要素は、リモート・サイトからの通知により、ＣＳプラットフォーム・ファームウェアのソフトウェア・ダウンロードとリモート・アップグレードのためにイネーブルされることが好ましい。
【０１４５】
システムは、同期サービスによって、リモートＤＣＳホスト３１０または４１０と定期的に連絡して、新しいトランザクションが待っているかどうかを確認することが好ましい。そのうちの１つは、新しいソフトウェアがシステムに使用可能であるという可能性がある。使用可能な場合は、管理タブから使用可能なアップグレード・ステータス画面によってユーザに通知することができる。ユーザは、また、ソフトウェア・アップグレード画面のリフレッシュ・ステータス・ボタンによって手動で最新版を確認するように選択することができる。アップグレードが可能な場合、ユーザは、そのアップグレードを受け入れる選択をすることができる。受け入れた場合、ソフトウェア・ダウンロード・プロセスは、自動的に、必要な最新版をダウンロードし、それをインストールし、古い方のバージョンを保存し、システムを再起動する。
【０１４６】
構成要素１１５は、ｅＳｅｒｖｉｃｅ提供物をサポートする供給業者にセキュアな暗号化された通信を戻す。実施形態の診断ルーチンは、動作が完全にローカルな場合でも、サービスとして扱われる。次に、そのサービスを、すべてのサービスに使用されるサービス加入モデルによって制御することができる。これにより、必要になったときに、ＣＳプラットフォームの機能を有効に無効にすることができる。
【０１４７】
システムは、初期のサービス・セットをユーザに提供できることが好ましい。そのような初期の提供物には、例えば、自動請求書発行、自動供給品補充、リモート監視がある。自動請求書発行は、要望に応じてまたは自動的に、装置中心サービスのインフラストラクチャを介して、必要な伝票発行メータを供給業者に報告する加入サービスであることが好ましい。自動供給品補充は、名前が示す通り、メータ供給品を人間の介在なしにユーザのサイトに適時かつ正確に送出するようにするのに必要な情報を供給業者に提供するために、トナー使用量イベント、領域有効範囲イベント、およびトナー・ボトル変更イベントを追跡する加入サービスであることが好ましい。リモート監視は、定期的に、システムで見つかった構成可能なデータ・セットを収集し、それを標準的な方法でモデル化し、それを供給業者に戻すサービスであることが好ましい。そのサービスにおいて見つかったデータのタイプの例には、請求書発行メータ、ＩＯＴ故障、媒体経路詰まり、画像領域有効範囲、媒体使用量（重量、サイズ、およびタイプ）、機能使用量、トナー・ステータス、片面／両面印刷量、媒体トレイ使用量、縮小と拡大、コピー・モード、および高頻度サービス項目のステータスがある。
【０１４８】
適切なシステム動作を保証するために、システムに追加のサービス・セットを組み込むことができる。例えば、ＤＭＡハウスキーピング・サービス、健康モニタ、ＤＭＡ−ＩＯＴ間通信ステータス・モニタ、サービス同期サービスなどであり、ＤＭＡシステムのリモート部分と定期的に連絡をとって、ＤＭＡが行うべき新しい指示または活動があるかどうかを確認するサービスである。
【０１４９】
セキュリティを保証するために、アドオン構成要素１１５は、実施形態において標準的なセキュアなウェブ・データ伝送技術および証明書を使用する。例えば、ＶｅｒｉＳｉｇｎ証明書、ＲＳＡ暗号化、ＳＳＬ、および関連した技術を使用することができる。さらに、アドオン構成要素１１５は、ユーザが装置から送られたすべてのメッセージを調べることを可能にする詳細なトランザクション・ログを提供することができる。ＣＳプラットフォーム１１５から送られたトランザクションは、すべて送信または暗号化のためにパッケージされる前に、ＸＭＬ形式でログをとることができる。これは、本当に言っていることだけを送っているという供給業者の記述の信頼性を高めるため、ユーザによる別の検査機能層を提供する。
【０１５０】
実施形態において、データをエッジ・ホスト４１０に送る前に３つの許可レベルを呼び出すことができる。契約上の取り決めは、データが自動的に送られ、またユーザが伝送ログを調べることができるということを述べていると期待される。様々な取り決めをすることが必要なユーザのために、複数の許可レベルに対応するオプションが、システムに組み込まれている。レベルは、トランザクション・ログにすべてのトランザクションの記録を維持する監査（Audit）およびログ（Log）と、バックオフィスへの送信が達成されたときに画面メッセージ、電子メールまたは何らかの他の手段によってユーザ代表者に通知する単純通知（Simple Notification）と、バックオフィス３００へのメッセージの待ち行列を維持し、待ち行列が空でないときにユーザ代表者に通知する承認後送信（Approval Before Sending）とを含むことができる。承認後送信において、ユーザ代表者は、必要に応じてメッセージを調べ、次にデータの送信を認めることができる。デフォルト許可レベルは設定可能であるが、好ましい出荷デフォルト・レベルは、監査とログである。事前支援自助ツールおよびＩＯＴ自体の診断アクセスでも、すべての機能に１つのパスワードを有する。以前のシステムには、複数の人々の役割に対応し、それに従ってパスワードを管理する方法はなかった。
【０１５１】
実施形態において、イネーブルされる多数の役割には、例えば、技術主オペレータ（Technical Key Operator）（ＴＫＯ）、カスタマ・サポート技術者（Customer Service Engineer）（ＣＳＥ）、およびシステム管理者（System Administrator）（ＳＡ）がある。任意の所定の役割のアクセスを構成するシステムは、ウェブ・ベースのＧＵＩによって提供される。パスワードは、最初、それぞれの役割に個別化された共通のパスワードに設定されることが好ましい。実施形態のシステムは、ＳＡが、自分のパスワードを構成しＴＫＯのパスワードを管理できることを意図しており、これにより、標準的なＩＴ産業のプロセス、プロトコル、および手順を使用して、ネットワーク接続された役割ベースのパスワード管理が可能になり、かつ任意またはすべての役割に関してリモートで認証されたログインおよびパスワード管理が可能になる。リモート・ログインは、訪れるどのＣＳプラットフォーム１１５上でも同じパスワードを使用したいＣＳＥには特に魅力的なことがある。リモート・ログインの認証は、パスワードのみ、パスワードとトークンの組み合わせ、または他の任意の適切な方法でよい。これは、リモート・ホスト・サイトに対するＣＳプラットフォームのネットワーク接続性によって制限され、バックアップ（または、ローカル）共通ＣＳＥまたはユーザの役割パスワードが、提供される必要がある。
【０１５２】
プラットフォームは、忘れたローカル・パスワードをリモートでリセットするプロセスを含むこともできる。ＳＡは、ヘルプ・デスクを呼び出し、話している本人として首尾良く認証される。ヘルプ・デスクは、ＣＳプラットフォーム（ＩＯＴ通し番号で示された）に命令を出して、それをそのＳＡパスワードをリセットさせる。ＳＡは、ＳＹＮＣボタンを手で押して、ＣＳプラットフォームにエッジ・ホスト４１０と連絡をとらせ、ＳＡパスワードをリセットする命令を受け取り、操作を完了するように伝える。他のすべてがＣＳに失敗した場合は、プラットフォーム・ファクトリ・リセット手順に従って、すべてのパスワードをデフォルト構成にリセットすることができる。
【０１５３】
通常のＤＣＳサービス加入および活動プロセスによって、新しいソフトウェア・サービス１４０を、ＣＳプラットフォーム・アドオン構成要素に追加することができる。加入したサービスは、ＤＭＡ１２０とＤＣＳエンド・ツー・エンド・システム１によって自動的に管理し導入することができる。これにより、ＣＳプラットフォーム１１５は、時間の経過と共に新しいサービスを提供することができる。新しいソフトウェア・アップグレードは、ＣＳプラットフォームのリモート・ソフトウェア・アップグレード機能によって提供することができる。これにより、ＣＳプラットフォーム１１５のより重要なアップグレードを、技術担当者がユーザ・サイトを訪れることなく、ユーザ承認を受けて実行することができる。これにより、コストが大幅に削減されるので、システム・アップグレードを配置することができる頻度が増える。
【０１５４】
以上の特徴ならびにほとんどのシステム・ハードウェアおよびソフトウェアへのＣＯＴＳ技術の使用のために、プラットフォームにリモートで追加された適切なサービスによって新しいハードウェアを追加することができる。ハードウェアの拡張を必要とする新しいサービスの例は、ユーザにとってウェブ・カメラを利用したサポートになる。低コストのＵＳＢウェブ・カムを追加することにより、抱えている問題のスナップ写真を撮ってその写真をヘルプ・デスクまたはコール・センタに送ることができるので、ＣＳプラットフォーム１１５は、ユーザが電話上よりも適切なリモート・サービスを受けることができるサービスを加入ユーザに提供することができる。
【０１５５】
実施形態は、ＣＳプラットフォーム１１５と同じサブネット上でネットワーク接続されたパーソナル・コンピュータ上のＣＳプラットフォームの導入を意図している。インストール・プロセスは、その概略図を図１９に示し、標準的なネットワーク・ユーティリティと、ＣＳプラットフォームの後ろにあるＬＥＤ表示の組み合わせを使用して、インストーラのプロセスを進める。ＣＳプラットフォーム１１５は、ヘッドレスな組み込みシステムであることが好ましいので、インストール・プロセスは、注意を要する場合がある。ここに示したステップは、インストールを行う１つの可能な方法であるが、他の方法も可能である。コマンド画面上のフィードバックと装置のＬＥＤの組み合わせが、インストールのための確実なプロセスを提供する。構成要素１１５は、最初、電源投入待機状態であり（ブロック８０１）、ユーザによって電源投入される（ブロック８０２）。ステータスＬＥＤまたは類似のものが、構成要素１１５が起動中であることを示すために点滅し、次に、構成要素１１５が準備完了状態になったときに点灯することが好ましい（ブロック８０３）。実施形態において、ユーザは、構成要素１１５のＭＡＣアドレスを読み出し（ブロック８０４）、ＵＩでコマンド・ウィンドウを開き（ブロック８０５）、ＭＡＣアドレスやその他の情報と共にコマンドを入力する（ブロック８０６）。次に、ユーザは、構成要素１１５をピング（ping）して（ブロック８０７）その構成要素をテストし、次に、１つまたは複数のＬＥＤが点灯状態になるような完了の表示を待つ（ブロック８０８）。次に、ユーザは、ブラウザで構成要素のウェブ・サーバ１３０まで進み（ブロック８０９）、管理者としてログオンし（ブロック８１０）、必要に応じてネットワーク情報を構成して（ブロック８１１）、構成要素１１５がエッジ・ホスト４１０と通信できるようにする。構成要素１１５が再起動し、その間に、ＩＯＴの電源を遮断しなければならない（ブロック８１３）。両方の再起動が完了した後、インストールとセットアップが完了する（ブロック８１３）。
【０１５６】
固定ＩＰアドレスの使用およびＩＰアドレスを取得するＤＨＣＰの使用を含む、ネットワーク接続のための複数の方法でＣＳプラットフォームを構成することができる。固定アドレスは、ほとんどのユーザにとって好ましく、準備ができたときにブラウザをＣＳプラットフォームＵＩに示しやすくするという利点を有する。代わりに、ＤＨＣＰは導入がきわめて容易であるが、ＣＳプラットフォームとＤＮＳサービス接続に装置ドメイン・ネームを必要とする。自動ドメイン・ネームを提供する１つの可能な方法は、ＩＯＴ通し番号を、ＭＡＣアドレスの最後の２桁と組み合わせることである。ユーザに既知の容易に使用可能な情報とデフォルトのＣＳプラットフォームの他の組み合わせが可能である。
【０１５７】
ＣＳプラットフォームは、任意のブラウザが構成されるのと同じように、ネットワーク用に構成される。これは、ＣＳプラットフォームＵＩ上で書式に記入することによって手作業で行うことができる。また、ウェブ・ブラウザ・プラットフォームに既にある設定を確認するルックアップ機能をＯＳが備えている場合は、その機能によって行うことができる。これは、基準となる設定値を提供し、次に、ユーザは、必要に応じてそれをカスタマイズしたり修正したりすることができる。構成した後で、ユーザがネットワーク管理ページを終了する前に、供給業者エッジ・サーバ４１０とすぐに連絡をとって設定が正しいことを確認しようとするテスト構成ボタンを提供することができる。
【０１５８】
ＣＳプラットフォーム１１５のユーザは、ＣＳプラットフォーム・ウェブ・ページへのブックマークをなくす場合があり、ユーザがそのウェブ・ページを再び見つけ易くする方法を提供する必要がある。システムを構成するためにＤＨＣＰが使用される場合は、ユーザは、指示に従うだけでＣＳプラットフォームのデフォルトまたはハードコードされたドメイン・ネームを決定することができる。また、ユーザの環境においてＤＦＥまたはネットワーク接続されたパーソナル・コンピュータ上にインストールされ動作し、またすべてのＣＳプラットフォームを見つけ表示する発見ツールを提供することができる。この発見ツールは、供給業者のウェブ・サイトからダウンロードすることもできる。ツールへのリンクは、ＣＳプラットフォームＵＩから使用することができ、したがって、ＣＳプラットフォームＩＰアドレスの紛失に備えてダウンロードし保存することができる。また、このツールは、インストール中にＤＦＥにローカルに保存するオプションによって、ＣＳプラットフォーム上にローカルに記憶させることができる。
【０１５９】
前述のように、ルータは、ＣＳプラットフォームへの並列アクセスの方法を管理する。ＣＳプラットフォーム・ルータは、供給業者ゲートウェイおよびＤＭＡ要件ならびに現地の装置１１０と互換性をもつことが好ましい。ルータは、ローカルＰＷＳポートとＩＯＴ診断（シリアル）ポートの間で直接接続を提供する。実施形態のルータは、また、例えばＩＯＴ診断（シリアル）ポートを介してネットワーク・クライアントにネットワーク接続を提供し、ＩＯＴ ＣＡＮバスならびに様々な装置１１０のＥＰサービスへのネットワーク経路をサポートすることができ、すべての（ＥＰ以外）通信トラフィックおよび優先順位を調停する。優先順位は、動作モードが滑らかに移行できるようにイネーブルされる。例えば、ＤＣＵソフトウェア・アップグレードのアプリケーション・セッションの優先順位、ＩＯＴシリアル・ポート３のローカルＰＷＳポートＩＯＴ診断セッションのもう１つの優先順位、および他のネットワーク・セッションのもう１つの優先順位がある。通常のシステム動作では、「オープン」なローカルＰＷＳセッションはプリエンプションされないことが好ましく、ローカルＰＷＳセッション要求は、ネットワーク診断アプリケーション・セッションを中断できることが好ましい。すべての中断が適切でなければならない。ネットワークＤＣＵソフトウェア・アップグレード・セッションのリエンプションは、許容できないことが好ましいが、ＥＰおよび／またはＣＡＮバス・セッションは、ＣＡＮセッションが１度に１つだけ許容される限り、いつでも許容されることが好ましい。ＤＭＡ ＥＰゲートウェイ・サーバ／クライアント・クライアントは、ＥＰポートへの排他的アクセスを有することが好ましく、ＤＣＵ Ｖ２．０は、ネットワーク上のローカルＰＷＳトランザクションの経路をサポートすることが好ましい。
【０１６０】
ＤＣＵ ｖ２．０のサポートにおいて、コミュニケーション・コントローラは、例えば、START_DIAG_SESSIONイベント（このイベントの顧客は、ＤＭＡプッシュ・イベント提供者である）を生成し、END_DIAG_SESSIONイベント（このイベントの顧客はＤＭＡプッシュ・イベント提供者である）を生成し、ＤＭＡプッシュ・イベント・提供者へのPWS_MESSAGE_EVENTとしてLOCAL_PWS_PORTとIOT_SERIALコミュニケーション・ポートの間で各メッセージを送ることによって、ネットワーク上のローカルＣＳＥ診断セッションの内容を提供することができる。
【０１６１】
ＤＣＵ ｖ２．０のさらに他のサポートにおいて、コミュニケーション・コントローラは、例えばＣＴＳ（Clear To Send）信号として指定されたＲＳ２３２信号を利用することによって、システムに接続されたＰＷＳに存在を伝える方法を提供することによって、ローカルＰＷＳポートを介したＩＯＴシリアル・ポートへのローカルＣＳＥ診断接続をサポートすることができる。ＣＴＳ信号は、ＤＣＵに論理ハイ・レベルで保持されることが好ましい。
【０１６２】
ＲＳ２３２インタフェースのＤＳＲ（データ信号レディ）信号は、ＩＯＴの診断モードを制御することができる。ＤＣＵは、この制御を保存するか必要に応じて「作成」する。ＩＯＴが、診断モードで、電源が遮断された場合は、ＩＯＴへのＤＳＲ信号がハイに設定されたときに診断モードで立ち上がる。ＰＳＷは、ＤＳＲ信号を制御する。
【０１６３】
特定の実施形態を説明したが、出願人または当業者には、現在予測されずまたは予測することができない代替、修正、変形、改良および実質的等価物が現れる可能性がある。したがって、出願され修正された併記の特許請求の範囲は、そのような代替、修正、変形、改良および実質的等価物をすべて包含するように意図されている。
【図面の簡単な説明】
【０１６４】
【図１】実施形態のアーキテクチャ全体の概略図である。
【図２】実施形態のアーキテクチャ全体のもう１つの概略図である。
【図３】実施形態によるサービス申し込みおよび配置の方法の概略図である。
【図４】実施形態による配置オプションの概略図である。
【図５】実施形態による追加の配置オプションの概略図である。
【図６】実施形態による追加の配置オプションの概略図である。
【図７】実施形態による追加の配置オプションの概略図である。
【図８】実施形態による追加の配置オプションの概略図である。
【図９】実施形態による追加の配置オプションの概略図である。
【図１０】実施形態による装置モデル・エージェントのより詳細な概略図であり、実施形態による装置、装置モデル・エージェント、サービス・プロキシおよびサービス・ホスト間の対話のより詳細な概略図である。
【図１１】実施形態による装置、装置モデル・エージェント、サービス・プロキシ、およびサービス・ホストの間の対話のより詳細な概略図である。
【図１２】実施形態による追加の配置オプションの概略図である。
【図１３】装置モデル・エージェントとその装置との関係をより強調した、実施形態による追加の配置オプションの概略図である。
【図１４】別の観点から装置モデル・エージェントとその装置に対する関係をより強調した、実施形態による追加の配置オプションの概略図である。
【図１５】実施形態による装置モデル・エージェントのサービス・マネージャの動作方法の概略的のフローチャートである。
【図１６】実施形態によるＣＳプラットフォーム・アドオン構成要素の概略図である。
【図１７】実施形態によるＣＳプラットフォーム・アドオン構成要素のもう１つの概略図である。
【図１８】実施形態によるＣＳプラットフォーム・アドオン構成要素の無線配置スキームの概略図である。
【図１９】実施形態によるＣＳプラットフォーム・アドオン構成要素を設定する方法の概略図である。
【図２０】実施形態による対応サーバの概略図である。
【図２１】実施形態によるＣＳプラットフォーム・アドオン構成要素のより概略的な図である。
【符号の説明】
【０１６５】
１００  ユーザ環境、１１０  ローカル装置、１２０  分散装置エージェント、１３０  ウェブ・サーバ、２００  アプリケーション・サーバ、２１０  装置プロキシ、２２０  ユーザ・アプリケーション、３００  サービス供給システム、３１０  アプリケーション・サーバ、３２０  ホスト・システム。
【図１】
2004220556.tif 000006
【図２】
2004220556.tif 000007
【図３】
2004220556.tif 000008
【図４】
2004220556.tif 000009
【図５】
2004220556.tif 000010
【図６】
2004220556.tif 000011
【図７】
2004220556.tif 000012
【図８】
2004220556.tif 000013
【図９】
2004220556.tif 000014
【図１０】
2004220556.tif 000015
【図１１】
2004220556.tif 000016
【図１２】
2004220556.tif 000017
【図１３】
2004220556.tif 000018
【図１４】
2004220556.tif 000019
【図１５】
2004220556.tif 000020
【図１６】
2004220556.tif 000021
【図１７】
2004220556.tif 000022
【図１８】
2004220556.tif 000023
【図１９】
2004220556.tif 000024
【図２０】
2004220556.tif 000025
【図２１】
2004220556.tif 000026
【外国語明細書】
2004220556.tif 000027
2004220556.tif 000028
2004220556.tif 000029
2004220556.tif 000030
2004220556.tif 000031
2004220556.tif 000032
2004220556.tif 000033
2004220556.tif 000034
2004220556.tif 000035
2004220556.tif 000036
2004220556.tif 000037
2004220556.tif 000038
2004220556.tif 000039
2004220556.tif 000040
2004220556.tif 000041
2004220556.tif 000042
2004220556.tif 000043
2004220556.tif 000044
2004220556.tif 000045
2004220556.tif 000046
2004220556.tif 000047
2004220556.tif 000048
2004220556.tif 000049
2004220556.tif 000050
2004220556.tif 000051
2004220556.tif 000052
2004220556.tif 000053
2004220556.tif 000054
2004220556.tif 000055
2004220556.tif 000056
2004220556.tif 000057
2004220556.tif 000058
2004220556.tif 000059
2004220556.tif 000060
2004220556.tif 000061
2004220556.tif 000062
2004220556.tif 000063
2004220556.tif 000064
2004220556.tif 000065
2004220556.tif 000066
2004220556.tif 000067
2004220556.tif 000068
2004220556.tif 000069
2004220556.tif 000070
2004220556.tif 000071
2004220556.tif 000072
2004220556.tif 000073
2004220556.tif 000074
2004220556.tif 000075
2004220556.tif 000076
2004220556.tif 000077
2004220556.tif 000078
2004220556.tif 000079
2004220556.tif 000080
2004220556.tif 000081
2004220556.tif 000082
2004220556.tif 000083
2004220556.tif 000084
2004220556.tif 000085
2004220556.tif 000086
2004220556.tif 000087
2004220556.tif 000088
2004220556.tif 000089
2004220556.tif 000090
2004220556.tif 000091
2004220556.tif 000092
2004220556.tif 000093
2004220556.tif 000094
2004220556.tif 000095
2004220556.tif 000096
2004220556.tif 000097
2004220556.tif 000098
2004220556.tif 000099
2004220556.tif 000100
2004220556.tif 000101
2004220556.tif 000102
2004220556.tif 000103
2004220556.tif 000104
2004220556.tif 000105
2004220556.tif 000106
2004220556.tif 000107
2004220556.tif 000108
2004220556.tif 000109
2004220556.tif 000110
2004220556.tif 000111