JP2021530073A - 分散コンピューティングデバイスの自動制御 - Google Patents

Abstract

システムは、少なくとも１つのプロセッサー及び少なくとも１つのプロセッサーでの実行のための命令を記憶するメモリを含むものである。命令は、クライアントデバイスの所望でないシステム状態に対応するサービスチケットを受け取ること、及び技術者デバイスとクライアントデバイスとの間の遠隔制御セッションを調整することを含むものである。命令は、クライアントデバイスを所望でないシステム状態から所望のシステム状態へ移行するために、遠隔制御下で、技術者により実行されるアクションのセットを取得することを含むものである。ここで、アクションのセットのうちの各アクションは、クライアントデバイスとの１つまたは複数のユーザーインターフェース（ＵＩ）の相互作用を表現しているものである。命令は、技術者からの入力を受け取ることに応じて、アクションのセットを選択的に変更すること、及び第２クライアントデバイスにおいて、解決プロファイル（ＲＰ）からアクションのセットを選択的に再生することを含むものである。ここで、ＲＰは、変更したアクションのセット及び識別したキーワードに基づくものである。

Description

関連出願の相互参照

本出願は、２０１８年７月２日に出願した米国仮出願番号６２／６９３，４１０のＰＣＴ国際出願である。上記出願の全開示は、参照することにより本明細書に組み込まれる。

本開示は、分散コンピューティングデバイスに関し、またより具体的には、分散コンピューティングデバイスを遠隔制御するための装置及び方法に関する。

コンピュータの存在する環境では、コンピュータのユーザーは、ユーザーのコンピュータで様々なインシデントに遭遇する可能性がある。例えば、ユーザーがファイルをネットワークハードドライブに保存できない、ドキュメントを印刷できない、特定のアプリケーションを起動できない、などの可能性がある。ユーザーは、インシデントを解決するための知識とリソースを持っているであろう情報技術（ＩＴ）技術者に連絡する場合がある。しかしながら、例えば技術者が他のユーザーを支援している場合や、インシデントが通常の営業時間外に発生した場合など、技術者がユーザーに即時の支援を提供することができない可能性がある。

一旦、技術者が支援を提供できるようになると、技術者がユーザーのコンピュータに遠隔接続する前に、技術者はユーザーに許可を要求し、そしてユーザーからの承認を得られなければならない。技術者は、ユーザーのインシデントを解決するために、アクションのセットを実行することがある。インシデントの解決に応じて、技術者は他の技術者とその解決策について話し合うことにより、もしも他の技術者がそのインシデントに遭遇した場合に、他の技術者は、同様の解決策を実行することができる。

ここで記載された背景技術の説明は、開示の文脈を一般的に示すことを目的とするものである。現在の発明者の研究は、この背景技術のセクションに記載されている範囲において、並びに出願時点でさもなければ先行技術となり得ない記述の態様は、明示的または黙示的に、本開示に対する先行技術として、認めるものではない。

システムは、少なくとも１つのプロセッサーと、少なくとも１つのプロセッサーによる実行のための命令を記憶するように構成された非一時的コンピュータ読取可能媒体とを有している。命令は、クライアントデバイスの所望でないシステム状態に対応するサービスチケットを受け取ることを含んでいる。命令は、サービスチケットを技術者に割り当てることを含んでいる。命令は、技術者デバイスとクライアントデバイスとの間の遠隔制御セッションを調整することを含んでおり、ここで、技術者デバイスは、技術者の制御下にあるものである。命令は、クライアントデバイスを所望でないシステム状態から所望のシステム状態へ移行させるために、遠隔制御下で、技術者により実行されるアクションのセットを取得することを含んでおり、ここで、アクションのセットのうちの各アクションは、クライアントデバイスとの１つまたは複数のユーザーインターフェース（ＵＩ）の相互作用を表現しているものである。命令は、サービスチケットの特性に基づいて、キーワードのセットを識別することを含んでいる。命令は、識別したキーワードをアクションのセットと関連付けることを含んでいる。命令は、アクションのセット及び識別したキーワードを技術者へ提示することを含んでいる。命令は、技術者からの入力を受け取ることに応じて、アクションのセットを選択的に変更することを含んでいる。命令は、技術者承認に応じて、解決プロファイル（ＲＰ）を保存することを含んでおり、ここで、ＲＰは、変更したアクションのセット及び識別したキーワードに基づくものである。命令は、第２クライアントデバイスのために提出された第２サービスチケットを受け取ることに応じて、第２クライアントデバイスにおいて、ＲＰからのアクションのセットを選択的に再生することを含んでいる。

他の特徴では、アクションのセットのうちの各アクションは、基本的解決ステップ（ＢＲＳ）データ構造に保存され、ＢＲＳデータ構造は、ＢＲＳデータ構造定義に準拠し、そしてＲＰは、ＢＲＳデータ構造の実行順序をエンコードするものである。他の特徴では、アクションのセットのうちの第１アクションに対応する第１ＢＲＳデータ構造は、第１アクションが実行される前に取り込まれたクライアントデバイスのスクリーンショットを含むものである。他の特徴では、第１ＢＲＳデータ構造は、コマンドを保存しており、コマンドにおいては、実行がクライアントデバイスを所望でないシステム状態から第２システム状態へ移行させるものである。

他の特徴では、アクションのセットのうちの第１アクションは、マウスイベント及びキーボードのキー押下げイベントのうちの少なくとも１つを含むものである。他の特徴では、第２クライアントデバイスが所望でないシステム状態にあることに応じて、命令は、第２クライアントデバイスでＲＰを再生することを含むものである。他の特徴では、ＲＰは、アクションのセットと１対１で対応するファイルの集まりとして、保存されるものである。他の特徴では、アクションのセットを取得することは、遠隔制御セッションの完了時に、クライアントデバイスまたは技術者デバイスのうちの１つからアクションのセットを受け取ることを含むものである。

他の特徴では、アクションのセットを取得することは、技術者デバイスによりクライアントデバイスへ送付されたものとして、アクションのセットを記録することを含むものである。他の特徴では、サービスチケットを技術者に割り当てることは、技術者によるチケットの要求に応じて実行されるものである。他の特徴では、命令は、技術者からの変更要求に応じて、キーワードのセットを変更することを含むものである。

他の特徴では、キーワードのセットは、オペレーティングシステムタイプ及びアプリケーションの名前のうちの少なくとも１つを含んでいる。他の特徴では、命令は、ウェブブラウザ、電子メールインターフェース、チャットインターフェース、及び電話のうちの少なくとも１つからサービスチケットを生成することを含んでいる。他の特徴では、命令は、保存することの後、他の技術者と共有するために、ＲＰを知識ベース（ＫＢ）アーティクルに選択的に変換することを含んでおり、ここで、ＫＢアーティクルは、シリーズ化したＲＰを含んでいる。

方法は、クライアントデバイスの所望でないシステム状態に対応するサービスチケットを受け取ることを含むものである。この方法は、サービスチケットを技術者に割り当てることを含むものである。この方法は、技術者デバイスとクライアントデバイスとの間の遠隔制御セッションを調整することを含むものである。技術者デバイスは、技術者の制御下にあるものである。この方法は、クライアントデバイスを所望でないシステム状態から所望のシステム状態へ移行させるために、遠隔制御下で、技術者により実行されるアクションのセットを取得することを含むものである。アクションのセットのうちの各アクションは、クライアントデバイスとの１つまたは複数のユーザーインターフェース（ＵＩ）の相互作用を表現しているものである。この方法は、サービスチケットの特性に基づいて、キーワードのセットを識別することを含むものである。この方法は、識別したキーワードをアクションのセットと関連付けることを含むものである。この方法は、アクションのセット及び識別したキーワードを技術者へ提示することを含むものである。この方法は、技術者からの入力を受け取ることに応じて、アクションのセットを選択的に変更することを含むものである。この方法は、技術者承認に応じて、解決プロファイル（ＲＰ）を保存することを含むものである。ＲＰは、変更したアクションのセット及び識別したキーワードに基づくものである。この方法は、第２クライアントデバイスのために提出された第２サービスチケットを受け取ることに応じて、第２クライアントデバイスにおいて、ＲＰからのアクションのセットを選択的に再生することを含むものである。

他の特徴では、アクションのセットのうちの各アクションは、基本的解決ステップ（ＢＲＳ）データ構造に保存され、ＢＲＳデータ構造は、ＢＲＳデータ構造定義に準拠するものである。ＲＰは、ＢＲＳデータ構造の実行順序をエンコードするものである。他の特徴では、アクションのセットのうちの第１アクションに対応する第１基本的解決ステップ（ＢＲＳ）データ構造は、第１アクションが実行される前に取り込まれたクライアントデバイスのスクリーンショットを含むものである。第１ＢＲＳデータ構造は、コマンドを保存しており、コマンドにおいては、実行がクライアントデバイスを所望でないシステム状態から第２システム状態へ移行させるものである。他の特徴では、この方法は、第２クライアントデバイスが所望でないシステム状態にあることに応じて、第２クライアントデバイスでＲＰを再生することを含むものである。他の特徴では、ＲＰは、アクションのセットと１対１で対応するファイルの集まりとして、保存されるものである。

他の特徴では、アクションのセットを取得することは、遠隔制御セッションの完了時に、クライアントデバイスまたは技術者デバイスのうちの１つからアクションのセットを受け取ること、及び技術者デバイスによりクライアントデバイスへ送付されたものとして、アクションのセットを記録すること、のうちの少なくとも１つを含むものである。他の特徴では、サービスチケットを技術者に割り当てることは、技術者によるチケットの要求に応じて実行されるものである。この方法は、技術者からの変更要求に応じて、キーワードのセットを変更することを含むものである。他の特徴では、アクションのセットのうちの第１アクションは、マウスイベント及びキーボードのキー押下げイベントのうちの少なくとも１つを含むものである。キーワードのセットは、オペレーティングシステムタイプ及びアプリケーションの名前のうちの少なくとも１つを含むものである。他の特徴では、この方法は、ウェブブラウザ、電子メールインターフェース、チャットインターフェース、及び電話のうちの少なくとも１つからサービスチケットを生成することを含むものである。他の特徴では、この方法は、保存することの後、他の技術者と共有するために、ＲＰを知識ベース（ＫＢ）アーティクルに選択的に変換することを含むものである。ＫＢアーティクルは、シリーズ化したＲＰを含むものである。

本開示の適用可能なさらなる領域は、発明を実施するための形態、特許請求の範囲、及び図面から明らかになるであろう。発明を実施するための形態及び特定の例は、例示のみを目的としており、開示の範囲を限定することを意図するものではない。

本開示は、発明を実施するための形態及び添付の図面からより完全に理解されるだろう。

図１は、例示的な分散コンピューティングシステムのブロック図である。 図２は、制御サーバの例示的な実施形態の機能ブロック図である。 図３は、解決ストーリー作成モジュールの例示的な実施形態の機能ブロック図である。 図４は、本開示の原理による例示的なデータ構造定義のグラフィカルな図表である。 図５は、自動化モジュールの例示的な実施形態の機能ブロック図である。 図６は、例示的な解決プロファイル（ＲＰ）記録のフローチャートである。 図７は、仮想のサービスチケットの例示的な自動解決のフローチャートである。 図８Ａは、解決ストーリーアプリケーションの例示的な解決ストーリー作成スクリーンである。 図８Ｂは、解決ストーリーアプリケーションの例示的な解決ストーリー作成スクリーンである。 図９は、解決ストーリーアプリケーションの例示的な注釈付き解決ストーリー作成スクリーンである。

図面において、参照番号は、類似及び／または同一の要素を識別するために再使用される場合がある。

＜イントロダクション＞
本開示によれば、分散コンピューティングシステムは、遠隔制御セッション中に、アクションのセット及びクライアントデバイスの付随的なスクリーンショットを記録することができる。記録は、遠隔制御セッション中にクライアントデバイスに保存されることができる。遠隔制御セッションにより、技術者はサービスチケットを解決するために、クライアントデバイスにおいて、アクションのセットを遠隔で実行することができる。アクションのセットのうちの各アクションは、例えばマウスイベント及び／またはキーボードイベントなどのように、クライアントデバイスとの１つまたは複数のユーザーインターフェース（ＵＩ）の相互作用を表現している。サービスチケットは、クライアントデバイスの所望でないシステム状態に対応する場合がある。サービスチケットには、インシデント、要求、クライアントデバイスのシステム状態に特化しない要求（例えば、メールシステム配布リストの作成、ログイン資格証明のリセットなど）などを含むことができる。例えば、所望でないシステム状態は、クライアントデバイスのユーザーがクライアントデバイスで経験している課題である可能性がある――これはインシデントとも呼ばれる。別の例として、所望でないシステム状態は、クライアントデバイス上に、特定のアプリケーションが存在しないことである場合がある――これは要求とも呼ばれる。

記録が完了する時、記録は圧縮され、そしてクライアントデバイスから制御サーバに送付される。様々な実施形態では、記録は、制御サーバ上で、または技術者によって操作される技術者デバイス上で実行されることができる。キーワードのセットは、サービスチケットの特性に基づいて識別されることができる。キーワードのセットは、記録と関連付けられることができる。

記録とキーワードのセットは、技術者に提示される。技術者は、記録とキーワードのセットをレビュー及び変更することができる。技術者は、アクションのセットからいくつかのアクションを削除することができる。なぜなら、それらのアクションは関係性がない、または冗長な場合があるためである。技術者はまた、スクリーンショットに注釈（例えば、矢印、強調表示、テキスト、ラベルなど）を追加することができる。技術者は、アクションに説明（例えば、追加の指示――ウィンドウを下にスクロールするなど――、コメントなど）を追加することができる。レビューと編集が完了する時、変更されたアクションのセットとキーワードのセットが解決ストーリーとして保存されることができる。

解決ストーリーは、遠隔制御セッション中に技術者によって実行されたアクションのセットを表現している。解決ストーリーは、他の技術者に提示されることにより、サービスチケットをどのように解決するかを他の技術者に説明することができる。様々な実施形態では、解決ストーリーは、技術者によって実行されたアクションのセットを説明するために、ユーザーに示されることができる。

解決ストーリーはまた、第２ユーザーによって操作された第２クライアントデバイスのために提出された第２サービスチケットをすばやく解決するために使用されることができる。様々な実施形態では、サービスチケットは、例えばパフォーマンスメトリクスなどの監視データを受け取る異常検出プロセスによって検出された異常に応じて、自動的に提出されることができる。

第２サービスチケットは、例えば、自然言語処理（ＮＬＰ）及び／または機械学習を使用して分類される。一旦、第２サービスチケットが分類されると、第２サービスチケットを解決するための最適な手法に対応する最短経路が決定される。例えば、最短経路は、例えば解決までの時間、変更の数、再起動の必要の有無などの、１つまたは複数の基準に従って決定される。もしも、解決ストーリーからのアクションのセットが最短経路に寄与するならば、解決ストーリーからのアクションのセットは、第２クライアントデバイスにおいて実行されることにより、第２サービスチケットを解決することができる。

＜環境＞
図１は、例示的な分散コンピューティングシステム１００のブロック図である。分散コンピューティングシステム１００は、制御サーバ１０２、クライアントデバイス１０４、及び技術者デバイス１０６を含んでいる。制御サーバ１０２、クライアントデバイス１０４、及び技術者デバイス１０６は、例えば、ローカルエリアネットワーク（ＬＡＮ）、インターネットなどのワイドエリアネットワーク（ＷＡＮ）、及び／または他のタイプのネットワークなどの、ネットワーク１０７を介して互いに通信することができる。制御サーバ１０２がｓｏｆｔｗａｒｅ−ａｓ−ａ−ｓｅｒｖｉｃｅ（ＳａａＳ）モデルに従って提供されることができ、またはクラウドインフラを使用して提供されることができることを単に説明するために、制御サーバ１０２は、ネットワーク１０７内に示されている。制御サーバ１０２、クライアントデバイス１０４、及び技術者デバイス１０６は、無線及び／または有線接続を使用してネットワーク１０７に接続することができる。クライアントデバイス１０４及び技術者デバイス１０６は、制御サーバ１０２とは異なる地理的位置に配置されることができる。クライアントデバイス１０４は、技術者デバイス１０６とは異なる地理的位置に配置されることができる。

クライアントデバイス１０４及び技術者デバイス１０６のそれぞれは、タブレット、ラップトップコンピュータ、パーソナルコンピュータ（ＰＣ）などであることができる。クライアントデバイス１０４は、ウェブブラウザ１０８及び遠隔支援エージェント１１０を含んでいる。例えば、遠隔支援エージェント１１０は、制御サーバ１０２を制御するオペレータによって提供されることができる。

クライアントデバイス１０４のユーザーは、ウェブポータルにログインし、そしてウェブブラウザ１０８を使用してサービスチケットを開くことができる。サービスチケットは、インシデント――すなわち、異常または予期しない動作（例えば、既存のファイルにアクセスすることができないなど）――、またはより優れた機能または異なる機能のための要求（例えば、新しいファイルストアへアクセスすることができることなど）、に関連する場合がある。インシデントまたは要求は、クライアントデバイス１０４（おそらく特別な管理者特権を必要とするが）を単独で使用して解決可能であるか、別のリソース（例えば、メールサーバを構成するものなど）を単独で使用して解決可能であるか、またはクライアントデバイス１０４及び１つまたは複数の他のリソースを必要とする場合がある。本出願は、それら３つのシナリオすべてに適用可能であるが、説明の簡潔さのため、サービスチケットがクライアントデバイス１０４を単独で使用して解決され得るシナリオを以下に説明する。

システム（クライアントデバイス１０４がその一部である）の現在の状態は、所望でないものとして説明されることができる――例えば、インシデントが異常な動作を明らかにした、または要求が幾つかの認識された欠陥を示しているなどである。したがって、サービスチケットは、クライアントデバイス１０４の所望のシステム状態とは異なる所望でないシステム状態に対応する。さらなる例として、すでにインストールされているアプリケーションが開かないという障害は、インシデントとして表現されることができる――その一方、ユーザーがクライアントデバイスにおいて特定のアプリケーションを起動することができないということで、インストールされる新しいアプリケーションのための要求がされる場合がある。

ユーザーは、サービスチケットが提出される前に、例えば、タイトル、発生した症状の説明、連絡先情報（例えば、名前、ユーザー名、電子メールアドレス、電話番号など）などを、サービスチケットのある特定のフィールドに挿入する必要がある場合がある。サービスチケットの連絡先情報などのいくつかのフィールドは、例えばチケット作成日、チケットＩＤ、チケット番号などの追跡フィールドなどのように、自動挿入される場合がある。これらのタイプのフィールドは、自動挿入フィールドと呼ばれる場合がある。

技術者デバイス１０６を操作する技術者は、例えば、技術者の連絡先情報（例えば、名前、電子メールアドレス、電話番号など）、チケットの優先順位、チケットのソースなどを、サービスチケットのある特定のフィールドに挿入する必要がある場合がある。一旦、ユーザーがサービスチケットを提出すると、新しいサービスチケットが受信されたことを技術者に知らせる通知が、技術者デバイス１０６に送信される場合がある。技術者は、チケット管理システムにログインすることにより、ウェブブラウザ１１８を使用してサービスチケットを閲覧することができる。技術者は、サービスチケットの割り当てを要求することができる。技術者に割り当てられているサービスチケットに応じて、技術者は、サービスチケットを診断及び解決するために、クライアントデバイス１０４に遠隔接続することができる。

ウェブブラウザ１１８は、制御サーバ１０２を介してクライアント制御モジュール１１２に遠隔制御の初期化要求を送信することができる。遠隔制御の初期化要求は、ユーザーに対して、遠隔制御セッションへの同意を求めさせるものである。いくつかの実施形態では、ユーザーは、事前に同意を与えている場合がある――その場合には、ユーザーは遠隔セッションの開始のために居合わせる必要はない。一旦、ユーザーによって同意が与えられると、遠隔制御ソフトウェア１２０は、ネットワーク１０７を介してクライアント制御モジュール１１２との遠隔制御セッションを確立する。遠隔制御セッションにより、技術者は、クライアントデバイス１０４を遠隔制御することができる。様々な実施形態では、クライアント制御モジュール１１２は、Ｓｐｌａｓｈｔｏｐ遠隔制御ソフトウェア、ＴｅａｍＶｉｅｗｅｒ遠隔制御ソフトウェア、または他のタイプの遠隔制御ソフトウェアであることができる。

遠隔制御セッションの確立に応じて、記録モジュール１１６は、遠隔制御セッションを記録する。遠隔制御セッション中に、技術者は、サービスチケットを解決するために、入力デバイスを使用してアクションのセットを実行することができる。例えば、キーボード、タッチパッド、マウス、タッチスクリーンなどの入力デバイスは、技術者デバイスに接続されることができる。アクションのセットのうちの各アクションは、クライアントデバイス１０４との１つまたは複数のユーザーインターフェース（ＵＩ）の相互作用を表現している。ＵＩの相互作用は、マウスのマウスイベント及び／またはキーボードのキーに対応することができる。例えば、マウスイベントは、ボタンダウン、ボタンアップ、クリック（例えば、ボタンダウンのすぐ後にボタンアップが続く）などであることができる。キー押下げは、すぐ後にキーアップが続くキーダウンとして表現されることができる。

上述のとおり、アクションのセットのうちの各アクションは、１つまたは複数のＵＩの相互作用を表現する。例えば、ダイアログボックスは、すべてチェックのついていない５つのチェックボックスを含むことができる。技術者は、チェックボックスでマウスイベント（例えば、クリック）を実行して、チェックボックスを確認済みとしてチェックマークをつけることができる。５つのチェックボックスのすべてをチェックすることは、５つのマウスイベントを必要とする場合がある――各チェックボックスに対して１つのマウスイベント。この場合、５つのマウスイベントは、一括して１つのアクションと呼ぶことができる。その他の場合、５つのマウスイベントは、５つの個別のアクションとして記録されることができる――１つのアクションに対応している各マウスイベント。

遠隔制御セッションの記録は、アクションのセットと、及び各アクションが実行される前のクライアントデバイス１０４のスクリーンショットとを含むことができる。例えば、もしも技術者がウィンドウを開き、その後テキストボックスまでウィンドウを下にスクロールし、そしてテキストボックスにテキストを入力すると、２つのスクリーンショットが記録されることができる。１番目のスクリーンショットは開かれたウィンドウを含むことができ、そして２番目のスクリーンショットは、入力されたテキストを含むテキストボックスを含むことができる。クライアントデバイス１０４のスクリーンショットは、第１のアクションが実行される前に記録されることができる。例えば、もしも技術者がダイアログボックスを閉じたい場合は、技術者は、Ｘ上でマウスイベント（例えば、クリック）を実行する前に、Ｘ上でマウスポインタを操作することができる。スクリーンショットは、Ｘ上でマウスイベントを実行した結果ではなく、Ｘ上でのマウスポインタを含むことができる。様々な実施形態では、第１のアクションの実行の後にスクリーンショットが記録されることができる。

遠隔制御セッションの終了に応じて、記録は完了する。技術者がクライアントデバイス１０４との接続を切断したときに、遠隔制御セッションは終了することができる。記録は、圧縮（例えば、ｒａｒまたはｚｉｐ形式を使用して）されることができ、そして制御サーバ１０２に送信されることができる。様々な実施形態では、遠隔制御セッション中に様々な時間間隔（例えば、毎分、３分ごと、１０分ごとなど）で、記録は、制御サーバ１０２に部分的に送信されることができる。記録モジュール１１６は、クライアントデバイス１０４に配置されているように示され、そして表現されているが、記録モジュール１１６及び記録は、制御サーバ１０２、技術者デバイス１０６、または別の場所に配置されることができる。

監視モジュール１１４は、クライアントデバイス１０４のメトリクスを監視するものであり、このメトリクスは、パフォーマンスメトリクス、インストールされたアプリケーション、ユーザーリストなどを含むことができる。メトリクスは、例えば、プロセッサー使用率、メモリ（例えば、揮発性または不揮発性メモリ、キャッシュなど）の使用率、大容量記憶装置（例えば、フラッシュメモリ、磁気ハードディスクドライブ（ＨＤＤ）など）の使用率、ネットワークの接続性（例えば、有線、無線など）などの、クライアントデバイス１０４のシステムリソースを含むことができる。監視モジュール１１４は、所定のスケジュールに基づいて、メトリクスを制御サーバ１０２に送信することができる。例えば、所定のスケジュールは、１日１回、１日２回、週１回などであることができる。様々な実施形態では、メトリクスにおいて検出された異常に応じて、メトリクスは制御サーバ１０２に直ちに送信されることができる。様々な実施形態では、メトリクスにおいて異常が検出されたことを知らせる通知が技術者に送信されることができる。監視モジュール１１４からの情報（例えば、オペレーティングシステム、インストールされたＲＡＭ、パッチレベル、ＣＰＵ利用率など）は、クライアントデバイス１０４のために作成されたサービスチケットに追加されることができる。

図２は、制御サーバ１０２の例示的な実施形態の機能ブロック図である。制御サーバ１０２は、ウェブポータル２０２、電子メールインターフェース２０４、チャットモジュール２０６、チケット管理モジュール２０８、チケットデータベース２１０、遠隔調整モジュール２１２、解決ストーリー作成モジュール２１４、メトリクスデータストア２１６、異常検出モジュール２１８、自動化モジュール２２０、手動作成モジュール２２２、及び解決ストーリーデータストア２２４を含んでいる。

ユーザーは、ウェブポータル２０２にログインし、そしてウェブブラウザ１０８を使用してサービスチケットを開くことができる。チケット管理モジュール２０８は、提供されたフィールドに基づいてサービスチケットを生成し、またある特定のフィールドに自動挿入することもできる。

様々な実施形態では、例えば電子メール、チャット、または電話を使用して、ユーザーは、ヘルプデスクまたは技術者に直接連絡をすることができる。電子メールインターフェース２０４は、ユーザーの電子メールから関連情報を識別し、そしてその関連情報に基づいてサービスチケットのフィールドに自動挿入することができる。

チャットモジュール２０６は、ユーザーと技術者またはヘルプデスクスタッフとの間で交換されるチャット会話で提供される関連情報を識別することができる。チケット管理モジュール２０８は、関連情報に基づいてサービスチケットを生成する。ユーザーと技術者との間で交換されるチャット会話は、サービスチケットに添付されることができる。サービスチケットは、チャット会話が終了した後に生成されることができる。様々な実施形態では、サービスチケットは、チャット会話中に生成されることができる。様々な他の実施形態では、チケットは、ユーザーと技術者との間の電話中に交換される関連情報から生成されることができる。

チケット管理モジュール２０８は、ウェブポータル２０２、電子メールインターフェース２０４、及びチャットモジュール２０６を含む様々なソースから受信したサービスチケットを生成及び管理する。技術者は、ウェブブラウザ１１８からチケット管理モジュール２０８にログインすることにより、サービスチケットのステータス（例えば、割り当て待ち、オープン、進行中、クローズなど）を含むサービスチケットを閲覧することができる。チケット管理モジュール２０８は、「割り当て待ち」とマークされたサービスチケットを対応可能な技術者に割り当てることができる。チケット管理モジュール２０８は、サービスチケットを要求した技術者にサービスチケットを割り当てるか、またはサービスチケットの特性について最も関連のある知識を有する技術者にサービスチケットを割り当てることができる。例えば、もしもサービスチケットがネットワークの接続性のインシデントを示しているならば、ネットワークについて最も知識のある技術者がサービスチケットを解決するために割り当てられることができる。一旦、チケットが技術者に割り当てられると、チケット管理モジュール２０８は、サービスチケットのステータスを「割り当て待ち」から「オープン」に更新することができる、またチケット管理モジュール２０８は、技術者がサービスチケットを割り当てられたことを技術者に知らせる通知を、技術者に送信することができる。

通知に応じて、技術者は、チケット管理モジュール２０８から対応するサービスチケットを選択することができる。技術者は、サービスチケットの技術者フィールドの一部を挿入することができる。付加的に、チケット管理モジュール２０８により、技術者が「オープン」ステータスの下で技術者に割り当てられたすべてのオープンサービスチケットのリストを閲覧することが可能になる。

技術者がサービスチケットを解決する準備ができた時、技術者はクライアントデバイス１０４に遠隔接続することができる。ウェブブラウザ１１８は、遠隔調整モジュール２１２を介してクライアント制御モジュール１１２に遠隔制御の初期化要求を送信することができる。一旦、クライアントデバイス１０４のユーザーによって同意が与えられると、遠隔制御ソフトウェア１２０は、クライアント制御モジュール１１２と直接遠隔制御セッションを行うことができる。チケット管理モジュール２０８は、遠隔制御セッションに応じて、サービスチケットのステータスを「オープン」から「進行中」に更新することができる。

記録モジュール１１６は、遠隔制御セッションを記録するように構成されている。チケット管理モジュール２０８は、技術者による遠隔制御セッションの終了に応じて、サービスチケットのステータスを「進行中」から「クローズ」に更新することができる。遠隔制御セッションが終了される時、記録は圧縮され、そして解決ストーリー作成モジュール２１４に送信されることができる。記録は、解決ストーリーとして解決ストーリーデータストア２２４に保存される前に、技術者によって閲覧及び変更されることができる。解決ストーリーは、遠隔制御セッション中に技術者によって実行されたアクションのセットを表現している記録であることができる。解決ストーリーは、サービスチケットをどのように解決するかを他の技術者に説明するために他の技術者に提示されることができ、技術者によって実行されたアクションのセットを説明するためにユーザーに示されることができ、また第２クライアントデバイスのために提出された第２サービスチケットを受信することに応じて、第２クライアントデバイスにおいて、解決ストーリーからのアクションのセットを自動的に実行するために使用されることができる。

手動作成モジュール２２２は、アクションのセットのうちの各アクションを手動で作成するものである。例えば、技術者は、ＪａｖａＳｃｒｉｐｔ Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ（ＪＳＯＮ）ドキュメントとして構築された、１つまたは複数のＵＩの相互作用を含むテキストドキュメントを作成することができる。手動で作成されたアクションはまた、スクリーンショット操作アプリケーション（例えば、ウィンドウズ（登録商標）切り抜きツールなど）を使用して、技術者によって手動で記録されたスクリーンショットを含むことができる。付加的にまたは代替的に、手動作成モジュール２２２は、知識ベース（ＫＢ）アーティクルをアクションのセットに変換することによって、アクションのセットのうちの各アクションを手動で作成することができる。手動で作成された解決ストーリーは、解決ストーリーデータストア２２４に保存される。

メトリクスデータストア２１６は、監視モジュール１１４からクライアントデバイス１０４のメトリクスを受信する。異常検出モジュール２１８は、メトリクスデータストア２１６に保存されたメトリクスを処理し、そして例えば履歴動作エンベロープ範囲外の逸脱などの、メトリクスの異常を検出するものである。一旦、異常が検出されると、異常検出モジュール２１８は、メトリクスから関連情報を識別し、そして関連情報に基づいてサービスチケットを生成することができる。チケット管理モジュール２０８は、必須のフィールド及び自動挿入されたフィールドに基づいてサービスチケットを生成する。

自動化モジュール２２０は、保存された解決ストーリーに基づいて、新しいサービスチケットを自動的に解決しようと試みるものである。もしも関連のある解決ストーリーが利用可能であるならば、遠隔調整モジュール２１２は、自動化モジュール２２０とクライアント制御モジュール１１２との間の接続を確立することができる。一旦、接続が確立されると、自動化モジュール２２０は、クライアント制御モジュール１１２と直接通信することにより、解決ストーリーの一部として保存されたＵＩの相互作用を再生することができる。自動化モジュール２２０は、完全に自動化されることができ、そのため、ある特定のサービスチケットは、技術者のいかなる介入なしに自動的に解決されることができる。様々な実施形態では、自動化モジュール２２０は、部分的に自動化されることができ、そのため、ある特定のサービスチケットが技術者の助けを借りて解決されることができる。例えば、技術者は、解決ストーリーのうちのどのアクションを実行するのかを選択することができ、そして自動化モジュール２２０は、サービスチケットを解決するために、選択されたアクションを実行することができる。

＜解決ストーリー作成＞
図３は、解決ストーリー作成モジュール２１４の例示的な実施形態の機能ブロック図である。解決ストーリー作成モジュール２１４は、記録データストア３０２、キーワード識別モジュール３０４、レビューモジュール３０６、及び解決ストーリー承認モジュール３０８を含んでいる。解決ストーリー作成モジュール２１４は、記録モジュール１１６から受信した記録に基づいて解決ストーリーを生成することができる。記録は、記録データストア３０２に保存される。解決ストーリーは、遠隔制御セッション中に技術者によって実行されたアクションのセットを表現する記録を含むことができる。解決ストーリーは、解決プロファイル（ＲＰ）データ構造内に保存された、基本的解決ステップ（ＢＲＳ）データ構造のセットとして保存されることができる。アクションのセットのうちの各アクションは、図４に記載されているように、ＢＲＳとして保存され、そのＢＲＳはＢＲＳデータ構造定義に準拠するものである。ＲＰは、各アクションごとに、ＢＲＳへのポインタを保存または含んでいるデータ構造である。

キーワード識別モジュール３０４は、サービスチケットの特性に基づいて、キーワードのセットを識別するものである。キーワード識別モジュール３０４は、例えば、サービスチケットと関連づけられている、例えば、タイトル及び／または説明などのテキストからキーワードのセットを識別することができる。キーワード識別モジュール３０４は、例えば、自然言語処理（ＮＬＰ）を使用して、キーワードのセットを識別することができる。もしもＮＬＰが何のキーワードも識別できない場合は、キーワードのセットは、最初は空のセットである場合がある。サービスチケットの特性は、クライアントデバイス１０４のオペレーティングシステムタイプ、アプリケーション名、及び／またはハードウェアのカテゴリ（例えば、ネットワークハードウェア、プリンタハードウェア、入力デバイスハードウェアなど）を含むことができる。キーワード識別モジュール３０４は、キーワードのセットを記録に関連付け、これにより記録を迅速に分類する。

レビューモジュール３０６によって、遠隔制御セッション中に技術者が実行したアクションのセットを、技術者が、レビュー及び編集することを可能になる。アクションのセットのうちの各アクションは、ＢＲＳに対応することができる。技術者は、ＢＲＳのセットを編集することができる。例えば、技術者は、関係性がない、または冗長なスクリーンショット及び／またはアクションを削除し、スクリーンショットに注釈（例えば、矢印、強調表示、テキストなど）を追加し、またはアクションに説明（例えば、追加の指示、コメントなど）を追加することができる。レビューモジュール３０６はまた、技術者が、記録に関連づけられているキーワードのセットを編集（例えば、追加または削除などによって）することを可能にする。一旦、レビューと編集が完了すると、変更されたＢＲＳのセットとキーワードのセットは、ＲＰとして保存されることができる――ＲＰは解決ストーリーとも呼ばれる。

解決ストーリー承認モジュール３０８は、解決ストーリーがベストプラクティスに従っていると決定するものである。例えば、解決ストーリーが、サービスチケットを最も少ない副作用（例えば、ユーザーのウィンドウズ（登録商標）プロファイルの削除や再作成など）で解決するための最も効率的な方法であると決定するために、ＩＴ管理者は、解決ストーリーをレビューすることができる。効率とは、アクションの最小量、使用されるリソースの最小量などによって定義されることができる。承認された解決ストーリーは、解決ストーリーデータストア２２４に保存される。

＜データ構造＞
図４は、ＢＲＳ４０２及びＲＰ４１２を含む例示的なデータ構造定義の図表である。ＢＲＳ４０２は、ＢＲＳ４０２の説明及び指示を提供するステップデータ４０４を含んでいる。ステップデータ４０４は、テキスト説明、作成者、作成日、ＢＲＳ識別（ＩＤ）、及び名前を含んでいる。テキスト説明は、自動的に生成されることができるＢＲＳ４０２の説明であり、それは技術者が変更することができる。作成者は、ＢＲＳ４０２を作成した技術者、またはＢＲＳ４０２の生成に使用されるツールであることができる。作成日は、ＢＲＳが生成された日付である。ＢＲＳ ＩＤは、ＢＲＳ４０２を独自に識別する識別子であり、また数字または英数字の値を含むことができる。ＢＲＳ４０２の名前は、テキスト説明から導き出されることができる。

ステップデータ４０４はまた、画像フィールド、オーバーレイ、重みの配列、ＢＲＳ４０２に必要なリソース、コマンド、及び検証を含んでいる。画像フィールドは、関連のあるスクリーンショットが保存されるユニフォームリソースロケーター（ＵＲＬ）を指定することができる。重みの配列は、例えば、解決までの時間、変更の数、再起動の必要の有無など、所定の基準のセットの各々の基準ごとに数値的重みを含んでいる。ＢＲＳ４０２に必要なリソースは、クライアントデバイスでＢＲＳ４０２を実行するために必要とされるハードウェアまたはソフトウェアコンポーネントを表現することができる。コマンドは、クライアントデバイスでアクションを実行する方法の概要を示すことができ、また、検証は、コマンドが首尾よく実行されたことを検証する方法の概要を示すことができる。

ＢＲＳ４０２はまた、パラメータデータ４０６、メディアコンテナ４０８、及びオーバーレイコンテナ４１０を含んでいる。パラメータデータ４０６は、ユーザーのタイプに基づいてＢＲＳ４０２を実行するために挿入された、予め定義されたパラメータのセットである。例えば、パラメータデータ４０６は、経路、ホスト名、及びユーザー名を含むことができる。メディアコンテナ４０８は、クライアントデバイスの１つまたは複数のスクリーンショットを含むことができる。様々な実施形態では、メディアコンテナ４０８は、クラウド記憶装置に配置されることができる。オーバーレイコンテナ４１０は、スクリーンショットの上に付けられる注釈（例えば、矢印、ハイライト、形状、テキストなど）を含んでいる。

ＢＲＳ４０２は、ファイルシステム内のディレクトリ（例えば、圧縮されたフォルダなど）であることができる。ステップデータ４０４及びパラメータデータ４０６は、ＪＳＯＮファイルまたはドキュメント、ハイパーテキストマークアップ言語（ＨＴＭＬ）ファイルまたはドキュメント、または拡張可能マークアップ言語（ＸＭＬ）ファイルまたはドキュメント（そのディレクトリに保存されている）であることができる。

ＲＰ４１２は、例えばファイルシステムフォルダなどのＢＲＳコンテナ４１３に保存されたＢＲＳのセットを含んでいる。ＢＲＳコンテナ４１３は、ＢＲＳ４１４−１，４１４−２，・・・，及び４１４−Ｎのセット（集合的に、ＢＲＳ４１４）を含んでおり、ここで、Ｎは、１以上の整数である。ＢＲＳのそれぞれは、ＢＲＳ ＩＤによって特徴付けられる。ＢＲＳ ＩＤは、ＢＲＳがＢＲＳコンテナ４１３でリストに載せられている順序に対応することができる。例えば、ＢＲＳ４１４−１は、ＢＲＳ４１４−２のＢＲＳ ＩＤより１つ低いＢＲＳ ＩＤを有することができ、またＢＲＳ−（ｎ−ｌ）のＩＤは、ＢＲＳ４１４−ＮのＩＤより１つ低いものであることができる。様々な実施形態では、ＢＲＳ ＩＤは、ステップデータ４０４の一部としてそれぞれのＢＲＳに保存される。

ＲＰ４１２はまた、テキスト説明４１６、作成者４１８、作成日４２０、及びＲＰ ＩＤ４２２を含んでいる。テキスト説明４１６は、自動的に生成されることができるＲＰ４１２の説明であり、またそれは技術者が修正することができる。作成者４１８は、ＲＰ４１２の作成者、またはＲＰ４１２を生成するために使用されるツールであることができる。作成日４２０は、ＲＰが生成された日付である。ＲＰ ＩＤ４２２は、ＲＰ４１２を識別する独自の識別子であり、また数字または英数字の値を含むことができる。

ＲＰ４１２はまた、第１のステップＩＤ４２４及び解決ステップリスト４２６を含んでいる。第１のステップＩＤ４２４は、ＢＲＳコンテナ４１３内のどのＢＲＳ４１４から開始するかを識別する。例えば、第１のステップＩＤ４２４は、ＢＲＳ４１４−２を識別することができる。様々な実施形態では、解決ステップリスト４２６は、ＢＲＳ４１４の実行の順序を説明する配列である。

解決ステップリスト４２６の各エントリは、次のステップに進むための条件、現在のステップのＢＲＳ ＩＤ、現在のステップが終了した際の遅延、条件が満たされた時の次のステップのＩＤ、及び条件が満たされない時の次のステップのＩＤを含んでいる。次のステップの条件は、どのステップが次に実行されるかを決定する。具体例として、ＲＰは、１０のステップに対応する１０個のＢＲＳを含んでおり、ここで、ステップ６は、クライアントデバイス上に特定のフォルダを作成する。簡単な説明としては、複数のＢＲＳ４１４の複数のＩＤは、単にそれぞれ、オフセット＋１からオフセット＋Ｎまでの整数であることができる、ここで、オフセットとは、ＲＰ４１２に以前に記録されたＢＲＳの最後に使用されたＩＤである。

解決ステップリスト４２６の最初の４つのエントリは、単にＢＲＳ４１４−１から４１４−４までをそれぞれ指定し、関連付けられた条件を持たず、そして単に次のステップとしてその次のＩＤを指定することができる。言い換えれば、最初のエントリは、現在のステップとしてＢＲＳ４１４−１を指定し、そして次のステップとしてＢＲＳ４１４−２を指定する。様々な実施形態では、条件のテストを回避するために、条件を空値に設定することができる。一方、この例では、解決ステップリスト４２６の第５のエントリは、現在のステップとしてＢＲＳ４１４−５を指定し、もしも条件が満たされた場合には次のステップとしてＢＲＳ４１４−７を指定し、そしてもしも条件が満たされない場合には次のステップとしてＢＲＳ４１４−６を指定する。条件は、クライアントデバイスのファイルシステム内の特定のフォルダの存在の有無のテストをする。ＢＲＳ４１４−７は、特定のフォルダを作成するコマンドをエンコードし、これにより、特定のフォルダが既に存在する場合にはスキップされる。

ＲＰ４１２は、ファイルシステム内の、例えば、圧縮ファイル（例えば、ｚｉｐ、ｒａｒ、または７ｚ圧縮方式を使用して）などの集まりであることができる。テキスト説明４１６、作成者４１８、作成日４２０、ＲＰ ＩＤ４２２、第１のステップＩＤ４２４、及び解決ステップリスト４２６は、集合的に、ＪＳＯＮファイルまたはドキュメント、ＨＴＭＬファイルまたはドキュメント、またはＸＭＬファイルまたはドキュメントであることができる。

＜自動修正＞
図５は、自動化モジュール２２０の例示的な実施形態の機能ブロック図である。自動化モジュール２２０は、サービスチケットを解決するために、解決ストーリーからのアクションのセットを実行する。自動化モジュール２２０は、分類モジュール５０２、解決策決定モジュール５０４、及び自動化実行モジュール５０６を含んでいる。

分類モジュール５０２は、サービスチケットをチケット管理モジュール２０８から分類する。分類モジュール５０２は、例えば、ＮＬＰ及び／または機械学習を使用してサービスチケットを分類することができる。分類モジュール５０２は、サービスチケットで識別された症状のタイトル及び説明を処理することによってサービスチケットを分類することができる。ある特定の症状は、様々なインシデントまたは要求と関連付けられることができる。分類モジュール５０２は、インシデントを分類するために追加のテスト結果を取得することができる。

例えば、もしもサービスチケットが、ファイルを遠隔ディスクに保存できないことを識別している場合は、１つまたは複数の条件により、この所望でない状態を結果として生じさせた可能性がある――例として、遠隔ディスクへの接続の欠如、遠隔ディスクに書き込むために許可が不十分であること、または遠隔ディスクのスペース（残りのクォータ割り当ての物理スペースのどちらかの一方）が利用できないことなどがある。分類モジュール５０２は、遠隔ディスクへの接続性テスト、ユーザー許可の問い合わせ、及び遠隔ディスク上での利用可能な空きスペースの問い合わせを含む、テストを要求することができる。追加情報からの結果に基づき、分類モジュール５０２は、サービスチケットを分類することができる。様々な実施形態では、もしも分類モジュール５０２がサービスチケットを分類することができないならば、技術者がサービスチケットを分類するように求められる場合がある。

解決策決定モジュール５０４は、サービスチケットの分類に基づいて、解決ストーリーまたはＲＰが利用可能であるかどうかを決定する。もしも関連のある解決ストーリーが利用可能であるならば、解決策決定モジュール５０４は、解決ストーリーデータストア２２４から解決ストーリーを回収することができる。もしも利用可能な解決ストーリーがない場合には、チケット管理モジュール２０８は、サービスチケットのステータスを「解決ストーリー利用不可」に更新することができる。その後、チケットは技術者によって手動で処理されることができる。

自動化実行モジュール５０６は、解決策実行モジュール５０８、解決策検証モジュール５１０、及び遠隔制御ソフトウェア１２０と類似していることができる遠隔制御ソフトウェア５１２を含んでいる。遠隔制御ソフトウェア５１２は、サービスチケットと関連付けられたクライアントデバイスと自動化実行モジュール５０６との間の接続を確立する。

接続が確立された後、解決策実行モジュール５０８は、クライアントデバイス上に読み込まれた解決ストーリーからのアクションのセットを実行する。解決策実行モジュール５０８は、クライアントデバイスを所望でないシステム状態から所望のシステム状態へ移行するために、解決ストーリーからアクションのセット（それぞれが１つまたは複数のＵＩの相互作用を含む）を再生することができる。解決策検証モジュール５１０は、クライアントデバイスを所望でないシステム状態から所望のシステム状態へ移行することによって、解決ストーリーがサービスチケットを解決したことを検証することができる。アクションのセットがサービスチケットを解決したことを首尾よく検証することに応じて、チケット管理モジュール２０８は、サービスチケットのステータスを「クローズ」に更新することができ、そして遠隔制御ソフトウェア５１２は、接続を終了することができる。

＜制御＞
図６は、例示的なＲＰ記録及び使用のフローチャートである。制御は６００から開始し、ここでクライアントデバイスのユーザーがサービスチケットを開くことになる。６０２において、制御は、サービスチケットを技術者に割り当てる。技術者は、サービスチケットをその技術者に割り当てるように要求することができる。６０４において、制御は、チケットに関連のあるＲＰが既に利用可能であるかどうかを決定する。もしも利用可能であれば、制御は６０８に移る。そうでない場合には、制御は６０６へ続行する。６０８において、制御は、技術者が利用可能なＲＰを承認するかどうかを決定する。もしも承認された場合には、制御は６１０へ続行する。そうでない場合には、制御は６０６に移る。６１０において、制御は、技術者がアクションを実行するためにＲＰを表示する。これは、技術者がステップスルーできる一連のスクリーンショットを技術者に表示することを含むことができる。その後、制御は終了する。

６０６において、制御は、クライアントデバイスの遠隔制御セッションの記録を開始する。６１２において、制御は、サービスチケットの解決策を見つけられるかどうかを決定する。もしも解決策が見つけられた場合には、制御は６１４で続行される。そうでない場合には、制御は６１２に戻る。６１４において、制御は、サービスチケットを閉じ、遠隔制御セッションの記録を停止し、そして６１６において続行する。６１６において、制御は、キーワードのセットを識別するために、サービスチケット及び遠隔制御セッションの記録を構文解析する。６１８において、制御は、技術者にキーワードと記録のドラフトを示す。

６２０において、制御は、技術者が記録のドラフトに対する変更があるかどうかを決定する。もしも変更がある場合には、制御は６２２に移る。そうでない場合には、制御は６２４へ続行する。６２２において、制御は、記録のドラフトに技術者の変更を加え、６２４へ続行する。６２４において、制御は、記録をＲＰとして保存する。制御は、６２４の後に終了することができる。様々な実施形態では、制御は６２６まで継続することができ、そこで制御は、ＲＰをＫＢアーティクルに変換し、その後、終了する。

ＫＢアーティクルは、スクリーンショットのセットと共に、ＲＰを人間に解読可能なドキュメント（例えば、ウェブドキュメント、ポータブルドキュメント形式（ＰＤＦ）ドキュメントなど）にシリーズ化することができる。ＫＢアーティクルは、ＲＰでマウスイベントが発生した所の同等の位置に近接するテキストを識別することができる。ＫＢアーティクルは、識別したテキストをスクリーンショットに関連付けることができる。結果としてのＫＢアーティクルは、テキスト、スクリーンショット、テキスト、スクリーンショット、テキストなどを含むことができる。

図７は、サービスチケットの例示的な自動修正のフローチャートである。サービスチケット――関連する解決ストーリーが存在する可能性のある――が受け取られた後、制御は、７００から開始する。７００において、制御は、サービスチケットで識別されたインシデントまたは要求のための根本原因を識別する。例えば、ファイルを開くことができないことは、インストールされた適切なアプリケーションの欠如、接続性の問題、アクセス制限などにより引き起こされている可能性がある。別の例では、特定のプリンタの使用要求は、所望でないシステム状態、つまり印刷できないこと、として表現されることができる。この状態の根本原因は、プリンタドライバーの欠如、クライアントのオペレーティングシステムに対してプリンタが識別されていない、ネットワークの接続性の問題、ある特定のドメインからのクライアントのコンピュータの不存在、対応するプリントスプーラーへのアクセス権の欠如などである可能性がある。

７０２において、制御は、サービスチケットによって関係づけられる所望でないシステム状態に対し、単一の根本原因があるかどうかを決定する。単一の根本原因がある場合には、制御は７１０に移る。そうでない場合は、制御は７０４へ続行する。７０４において、制御は、サービスチケットの根本原因を決定するために、追加のテストを実行する。 ７０６において、制御は、テストに基づいてサービスチケットの根本原因を分類しようと試みる。７０８において、制御は、根本原因（または原因）が分類されることができるかどうかを決定する。分類されることができる場合には、制御は７１０へ続行する。そうでない場合は、制御は７２８に移る。７２８において、制御は、すべての追加のテストが仕尽くされたかどうかを決定する。仕尽くされた場合には、制御は、７３０においてエラー処理を実行し、その後、終了する。そうでない場合は、制御は７０４に戻る。

７１０において、制御は、インシデントの分類された原因を扱うために、予め定義されたＲＰの存在の有無を決定する。存在する場合には、制御は７１４へ続行し、ここで制御は予め定義されたＲＰを選択する。そうでない場合は、制御は７１２へ続行する。７１２において、制御は、サービスチケットを解決するための最適なステップ（例えば、ＢＲＳ）を決定する。簡単な例として、システムの現在の状態を状態Ａと呼び、一方、システムの所望の状態を状態Ｄと呼ぶことができる。最適なステップは、以下を含むことができる：
・システムを状態Ａから状態Ｂに移行する第１ＢＲＳ；
・システムを状態Ｂから状態Ｄに移行する第２ＢＲＳ；
・システムを状態Ａから状態Ｃに移行する第３ＢＲＳ；及び
・システムを状態Ｃから状態Ｄに移行する第４ＢＲＳ。

例えば、これらのＢＲＳは、例えばコンボリューショナルニューラルネットワーク、ディープニューラルネットワーク、ディープビリーフネットワークなどのディープラーニング分析を使用して決定されることができる。

７１６において、制御は、決定された最適なステップからＢＲＳのセットを選択する。例えば、この選択は、コンボリューショナルニューラルネットワーク、ディープニューラルネットワーク、ディープビリーフネットワークなどのディープラーニング分析を使用して実行されることができる。様々な実施形態では、最短経路アルゴリズムは、サービスチケットを解決するために、予め定義されたＢＲＳを選択することができる。上記の例を継続すると、２つの可能な組み合わせがある――第１及び第２ＢＲＳを使用するか、または第３及び第４ＢＲＳを使用するかである。最短経路アルゴリズムは、２つの可能な組み合わせのうちのどちらを使用するかを決定する。最短経路アルゴリズムは、例えば各ＢＲＳについて上述した重みの配列の幾つかまたはすべてなどのように、１つまたは複数の基準に基づいて、経路長を評価することができる。これらの重みは、例えば、解決までの時間、変更の数、再起動の必要の有無などを含むことができる。

７１８において、制御は、選択された解決策（すなわち、予め定義されたＲＰ、または選択されたＢＲＳのセット）を実行する。７２０において、制御は、選択された解決策が有効であったかどうかを検証する。７２２において、制御は、選択された解決策がサービスチケットを解決したかどうかを決定する。解決した場合には、制御は、７２４においてサービスチケットを閉じ、その後、終了する。そうでない場合は、制御は、７２６においてエラー処理を実行し、その後、終了する。

＜アプリケーションユーザーインターフェース＞
図８Ａ及び図８Ｂは共に、解決ストーリーアプリケーションの例示的な解決ストーリー作成スクリーンを形成し、このアプリケーションは、ウェブアプリケーションまたはネイティブアプリケーションであることができる。解決ストーリーアプリケーションは、技術者が解決ストーリーアプリケーション内をナビゲートすることを可能にするナビゲーション区画ウィンドウ８０２を含むことができる。例えば、図８Ａ及び図８Ｂ（集合的に図８とも呼ばれる）のナビゲーション区画ウィンドウ８０２は、ダッシュボードタブ、チケットタブ、アラートタブ、デバイスタブ、顧客タブ、解決タブ、知識ベースタブ、オンラインバックアップタブ、メールセキュリティタブ、ウェブルートタブ、支払い請求タブ、レポートタブ、及び管理者タブを含んでいる。チケットタブにより、サービスチケットのリストが提供され、そして技術者は特定のサービスチケットを閲覧することができる。解決タブは、図８の例に示すように、既存の解決ストーリーを閲覧するために、または新しい解決ストーリーを作成するために使用されることができる。

選択された解決ストーリー（作成されたばかりの可能性がある）に対して、注釈ツールバー８０４は、スクリーンショットに注釈を付けるために使用される。注釈ツールバー８０４は、スクリーンショットにオーバーレイを追加する、例えば、ポインタ、テキストカーソル、クロッピングツール、ハイライトマーカー、形状セレクタなどのようなツールを含むことができる。

図９は、解決ストーリーアプリケーションの例示的な注釈付き解決ストーリー作成スクリーンである。技術者が、バッテリーセーバーの設定を強調するために、スクリーンショットに長方形形状のハイライトで注釈を付けたものである。長方形の形状は、注釈ツールバー８０４の形状セレクタツールから選択された。縦線とテキスト挿入カーソルによって示されているように、長方形の形状の右に、技術者が、テキストを入力する用意ができている。

＜結論＞
前述の説明は、本質的に単なる例示であり、また、本開示、その適用、または使用を限定することを決して意図するものではない。本開示の広範な教示は、様々な形態で実施することができる。したがって、本開示には特定の例が含まれるが、本図面、本明細書、および以下の特許請求の範囲を検討することにより、他の変更が明らかになるため、本開示の真の範囲は、限定されるべきではない。方法内の１つまたは複数のステップは、本開示の原理を変更することなく、異なる順序で（または同時に）実行できることを理解すべきである。さらに、本実施例のそれぞれは、特定の特徴を有するものとして上に記載されているが、本開示の任意の実施例に関して記載されているこれらの特徴のいずれか１つまたは複数は、たとえその組み合わせが、明確に説明されていないとしても、任意の他の実施例の特徴中で、及び／またはそれと組み合わすことによって、実施されることができる。言い換えれば、記述された実施例は、相互に排他的ではなく、そして、１つまたは複数の実施例の相互の順序の変更は、本開示の範囲内である。

要素間（例えば、モジュール間）の空間的、及び機能的関係は、「接続」、「係合」、「インターフェース」、及び「結合」を含む様々な用語を使用して説明される。「直接」であると明示的に説明されていない限り、第１の要素と第２の要素との間の関係が上述の開示に記載されている場合、その関係は、第１の要素と第２の要素との間に他の介在要素が存在しない直接的な関係、及び、１つまたは複数の介在要素が第１要素と第２要素との間に存在する（空間的または機能的に）間接的な関係も包含する。本明細書で使用される場合、Ａ、Ｂ、及びＣの少なくとも１つの句は、非排他的論理「ＯＲ」を使用して、論理（Ａ ＯＲ Ｂ ＯＲ Ｃ）を意味すると解釈されるべきであり、また、その句は、「Ａの少なくとも１つ、Ｂの少なくとも１つ、及びＣの少なくとも１つ」を意味すると解釈されるべきではない。サブセットという用語は、必ずしも適切なサブセットを必要としない。言い換えれば、第１のセットの第１のサブセットは、第１のセットと同一の広がりを有する（等しい）と解釈されることができる。

図面において、矢印で示されている矢の方向は、一般に、イラストに関係する情報（データや指示など）の流れを示すものである。例えば、要素Ａと要素Ｂが様々な情報を交換する場合で、要素Ａから要素Ｂに送信される情報がイラストに関連する場合、矢印は要素Ａから要素Ｂを指すことができる。この一方向の矢印は、要素Ｂから要素Ａに送信される他の情報がないことを意味するものではない。さらに、要素Ａから要素Ｂに送信される情報について、要素Ｂは、情報の要求または受信確認を要素Ａに送信することができる。

本出願において、以下の定義を含むものである。「モジュール」という用語または「コントローラ」という用語は、「回路」という用語に置き換えることができる。「モジュール」という用語は、コードを実行するプロセッサーハードウェア（共有、専用、またはグループ）及びプロセッサーハードウェアによって実行されるコードを保存するメモリハードウェア（共有、専用、またはグループ）を指すか、その一部であるか、またはそれを含む場合がある。

モジュールは、１つまたは複数のインターフェース回路を含むことができる。いくつかの例では、インターフェース回路は、ローカルエリアネットワーク（ＬＡＮ）、インターネット、ワイドエリアネットワーク（ＷＡＮ）、またはそれらの組み合わせに接続する有線または無線のインターフェースを含むことができる。本開示の任意の所与のモジュールの機能は、インターフェース回路を介して接続された複数のモジュール間で分散されることができる。例えば、複数のモジュールで負荷分散が可能になる。さらなる例では、サーバ（遠隔またはクラウドとしても知られる）モジュールは、クライアントモジュールに代わっていくつかの機能を達成することができる。

上述で使用されたコードという用語は、ソフトウェア、ファームウェア、及び／またはマイクロコードを含むことができ、また、それは、プログラム、ルーチン、関数、クラス、データ構造、及び／またはオブジェクトを指すことができる。共有プロセッサーハードウェアは、複数のモジュールからの幾つかまたはすべてのコードを実行する単一のマイクロプロセッサーを包含するものである。グループプロセッサーハードウェアは、１つまたは複数のモジュールからの幾つかまたはすべてのコードを実行する、追加のマイクロプロセッサーと組み合わされたマイクロプロセッサーを包含するものである。複数のマイクロプロセッサーと言及する時は、個別のダイ上の複数のマイクロプロセッサー、単一のダイ上の複数のマイクロプロセッサー、単一のマイクロプロセッサーの複数のコア、単一のマイクロプロセッサーの複数のスレッド、または上述の組み合わせを含むものである。

共有メモリハードウェアは、複数のモジュールからの幾つかまたはすべてのコードを記憶する単一のメモリデバイスを包含するものである。グループメモリハードウェアは、他のメモリデバイスと組み合わせて、１つまたは複数のモジュールからの幾つかまたはすべてのコードを記憶するメモリデバイスを包含するものである。

メモリハードウェアという用語は、コンピュータ読取可能媒体という用語のサブセットである。本明細書で使用されるコンピュータ読取可能媒体という用語は、媒体（搬送波上など）を通って伝搬する一時的な電気信号または電磁信号を包含するものではない。従って、コンピュータ読取可能媒体という用語は、有形で非一時的であると見なされるものである。非一時的なコンピュータ読取可能媒体の非限定的な例は、不揮発性メモリデバイス（フラッシュメモリデバイス、消去可能なプログラム可能な読取専用メモリデバイス、またはマスク読取専用メモリデバイスなど）、揮発性メモリデバイス（静的ランダムアクセスメモリデバイスまたは動的ランダムアクセスメモリデバイスなど）、磁気記憶装置メディア（アナログまたはデジタル磁気テープまたはハードディスクドライブなど）、及び光記憶装置メディア（ＣＤ、ＤＶＤ、またはブルーレイディスクなど）である。

本出願で説明される装置および方法は、コンピュータプログラムに具体化された１つまたは複数の特定の機能を実行するように汎用コンピュータを構成することによって作成された専用コンピュータによって、部分的または完全に実施されることができる。上述の機能ブロック及びフローチャート要素は、ソフトウェア仕様として機能し、熟練した技術者またはプログラマーの定型業務によって、コンピュータプログラムに変換することができる。

コンピュータプログラムは、少なくとも１つの非一時的なコンピュータ読取可能媒体に記憶されているプロセッサー実行可能命令を含んでいる。コンピュータプログラムはまた、記憶されたデータを含むか、またはそれに依存することができる。コンピュータプログラムは、専用コンピュータのハードウェアと情報を交換する基本的な入出力システム（ＢＩＯＳ）、専用コンピュータの特定のデバイスと情報を交換するデバイスドライバ、１つまたは複数のオペレーティングシステム、ユーザーアプリケーション、バックグラウンドサービス、バックグラウンドアプリケーションなどを含むことができる。

コンピュータプログラムは、次のものを含むことができる：（ｉ）ＨＴＭＬ（ハイパーテキストマークアップ言語）、ＸＭＬ（拡張マークアップ言語）、またはＪＳＯＮ（ＪａｖａＳｃｒｉｐｔオブジェクト表記）などの解析される説明文、（ｉｉ）アセンブリコード、（ｉｉｉ）コンパイラによってソースコードから生成されたオブジェクトコード、（ｉｖ）インタプリタによる実行用のソースコード、（ｖ）ジャストインタイムコンパイラによるコンパイル及び実行用のソースコードなど。単なる例として、ソースコードは、次に挙げる言語の構文を使用して記述できる：Ｃ，Ｃ＋＋，Ｃ＃，Ｏｂｊｅｃｔｉｖｅ−Ｃ，Ｓｗｉｆｔ，Ｈａｓｋｅｌｌ，Ｇｏ，ＳＱＬ，Ｒ，Ｌｉｓｐ，Ｊａｖａ（登録商標），Ｆｏｒｔｒａｎ，Ｐｅｒｌ，Ｐａｓｃａｌ，Ｃｕｒｌ，ＯＣａｍｌ，Ｊａｖａｓｃｒｉｐｔ（登録商標），ＨＴＭＬ５（Ｈｙｐｅｒｔｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ ５ｔｈ ｒｅｖｉｓｉｏｎ），Ａｄａ，ＡＳＰ（Ａｃｔｉｖｅ Ｓｅｒｖｅｒ Ｐａｇｅｓ），ＰＨＰ（ＰＨＰ：Ｈｙｐｅｒｔｅｘｔ Ｐｒｅｐｒｏｃｅｓｓｏｒ），Ｓｃａｌａ，Ｅｉｆｆｅｌ，Ｓｍａｌｌｔａｌｋ，Ｅｒｌａｎｇ，Ｒｕｂｙ，Ｆｌａｓｈ（登録商標），ＶｉｓｕａｌＢａｓｉｃ（登録商標），Ｌｕａ，ＭＡＴＬＡＢ（登録商標），ＳＩＭＵＬＩＮＫ，及びＰｙｔｈｏｎ（登録商標）。

Claims (24)

1. 少なくとも１つのプロセッサーと、及び
   前記少なくとも１つのプロセッサーによる実行のための命令を記憶するように構成された非一時的コンピュータ読取可能媒体とを有しており、
   前記命令は、次のものを含むものである：
   クライアントデバイスの所望でないシステム状態に対応するサービスチケットを受け取ること；
   前記サービスチケットを技術者に割り当てること；
   技術者デバイスと前記クライアントデバイスとの間の遠隔制御セッションを調整すること、ここで、前記技術者デバイスは、前記技術者の制御下にあるものであり；
   前記クライアントデバイスを前記所望でないシステム状態から所望のシステム状態へ移行させるために、遠隔制御下で、前記技術者により実行されるアクションのセットを取得すること、ここで、前記アクションのセットのうちの各アクションは、前記クライアントデバイスとの１つまたは複数のユーザーインターフェース（ＵＩ）の相互作用を表現しているものであり；
   前記サービスチケットの特性に基づいて、キーワードのセットを識別すること；
   前記識別したキーワードを前記アクションのセットと関連付けること；
   前記アクションのセット及び前記識別したキーワードを前記技術者へ提示すること；
   前記技術者からの入力を受け取ることに応じて、前記アクションのセットを選択的に変更すること；
   技術者承認に応じて、解決プロファイル（ＲＰ）を保存すること、ここで、前記ＲＰは、前記変更したアクションのセット及び前記識別したキーワードに基づくものであり；及び
   第２クライアントデバイスのために提出された第２サービスチケットを受け取ることに応じて、前記第２クライアントデバイスにおいて、前記ＲＰからの前記アクションのセットを選択的に再生すること、を有するように構成されたシステム。
2. 前記アクションのセットのうちの各アクションは、基本的解決ステップ（ＢＲＳ）データ構造に保存されており、前記ＢＲＳデータ構造は、ＢＲＳデータ構造定義に準拠するものである、及び
   前記ＲＰは、前記ＢＲＳデータ構造の実行順序をエンコードするものである、請求項１に記載のシステム。
3. 前記アクションのセットのうちの第１アクションに対応する第１基本的解決ステップ（ＢＲＳ）データ構造は、前記第１アクションが実行される前に取り込まれた前記クライアントデバイスのスクリーンショットを含むものである、請求項１に記載のシステム。
4. 前記第１ＢＲＳデータ構造は、コマンドを保存しており、前記コマンドにおいては、実行が前記クライアントデバイスを前記所望でないシステム状態から第２システム状態へ移行させる、請求項３に記載のシステム。
5. 前記アクションのセットのうちの第１アクションは、マウスイベント及びキーボードのキー押下げイベントのうちの少なくとも１つを含むものである、請求項１に記載のシステム。
6. 前記第２クライアントデバイスが前記所望でないシステム状態にあることに応じて、前記命令は、前記第２クライアントデバイスで前記ＲＰを再生することを含むものである、請求項１に記載のシステム。
7. 前記ＲＰは、前記アクションのセットと１対１で対応するファイルの集まりとして、保存される、請求項１に記載のシステム。
8. 前記アクションのセットを取得することは、前記遠隔制御セッションの完了時に、前記クライアントデバイスまたは前記技術者デバイスのうちの１つから前記アクションのセットを受け取ることを含むものである、請求項１に記載のシステム。
9. 前記アクションのセットを取得することは、前記技術者デバイスにより前記クライアントデバイスへ送付されたものとして、前記アクションのセットを記録することを含むものである、請求項１に記載のシステム。
10. 前記サービスチケットを前記技術者に割り当てることは、前記技術者による前記チケットの要求に応じて実行される、請求項１に記載のシステム。
11. 前記命令は、前記技術者からの変更要求に応じて、前記キーワードのセットを変更することを含むものである、請求項１に記載のシステム。
12. 前記キーワードのセットは、オペレーティングシステムタイプ及びアプリケーションの名前のうちの少なくとも１つを含むものである、請求項１に記載のシステム。
13. 前記命令は、ウェブブラウザ、電子メールインターフェース、チャットインターフェース、及び電話のうちの少なくとも１つから前記サービスチケットを生成することを含むものである、請求項１に記載のシステム。
14. 前記命令は、前記保存することの後、他の技術者と共有するために、前記ＲＰを知識ベース（ＫＢ）アーティクルに選択的に変換することを含むものである、ここで、前記ＫＢアーティクルは、シリーズ化したＲＰを含むものである、請求項１に記載のシステム。
15. クライアントデバイスの所望でないシステム状態に対応するサービスチケットを受け取ること、
    前記サービスチケットを技術者に割り当てること、
    技術者デバイスと前記クライアントデバイスとの間の遠隔制御セッションを調整すること、ここで、前記技術者デバイスは、前記技術者の制御下にあるものであり、
    前記クライアントデバイスを前記所望でないシステム状態から所望のシステム状態へ移行させるために、遠隔制御下で、前記技術者により実行されるアクションのセットを取得すること、ここで、前記アクションのセットのうちの各アクションは、前記クライアントデバイスとの１つまたは複数のユーザーインターフェース（ＵＩ）の相互作用を表現しているものであり、
    前記サービスチケットの特性に基づいて、キーワードのセットを識別すること、
    前記識別したキーワードを前記アクションのセットと関連付けること、
    前記アクションのセット及び前記識別したキーワードを前記技術者へ提示すること、
    前記技術者からの入力を受け取ることに応じて、前記アクションのセットを選択的に変更すること、
    技術者承認に応じて、解決プロファイル（ＲＰ）を保存すること、ここで、前記ＲＰは、前記変更したアクションのセット及び前記識別したキーワードに基づくものであり、及び
    第２クライアントデバイスのために提出された第２サービスチケットを受け取ることに応じて、前記第２クライアントデバイスにおいて、前記ＲＰからの前記アクションのセットを選択的に再生すること、を有する方法。
16. 前記アクションのセットのうちの各アクションは、基本的解決ステップ（ＢＲＳ）データ構造に保存され、前記ＢＲＳデータ構造は、ＢＲＳデータ構造定義に準拠するものである、及び
    前記ＲＰは、前記ＢＲＳデータ構造の実行順序をエンコードするものである、請求項１５に記載の方法。
17. 前記アクションのセットのうちの第１アクションに対応する第１基本的解決ステップ（ＢＲＳ）データ構造は、前記第１アクションが実行される前に取り込まれた前記クライアントデバイスのスクリーンショットを含むものであり、及び
    前記第１ＢＲＳデータ構造は、コマンドを保存しており、前記コマンドにおいては、実行が前記クライアントデバイスを前記所望でないシステム状態から第２システム状態へ移行させる、請求項１５に記載の方法。
18. 前記第２クライアントデバイスが前記所望でないシステム状態にあることに応じて、前記第２クライアントデバイスで前記ＲＰを再生すること、をさらに有する請求項１５に記載の方法。
19. 前記ＲＰは、前記アクションのセットと１対１で対応するファイルの集まりとして、保存される、請求項１５に記載の方法。
20. 前記アクションのセットを取得することは、次のうちの少なくとも１つを含むものである：
    前記遠隔制御セッションの完了時に、前記クライアントデバイスまたは前記技術者デバイスのうちの１つから前記アクションのセットを受け取ること；及び
    前記技術者デバイスにより前記クライアントデバイスへ送付されたものとして、前記アクションのセットを記録すること、を有する請求項１５に記載の方法。
21. 前記サービスチケットを前記技術者に割り当てることは、前記技術者による前記チケットの要求に応じて実行されるものであり、及び
    前記方法はさらに、前記技術者からの変更要求に応じて、前記キーワードのセットを変更すること、を有する請求項１５に記載の方法。
22. 前記アクションのセットのうちの第１アクションは、マウスイベント及びキーボードのキー押下げイベントのうちの少なくとも１つを含むものであり、及び
    前記キーワードのセットは、オペレーティングシステムタイプ及びアプリケーションの名前のうちの少なくとも１つを含むものである、請求項１５に記載の方法。
23. ウェブブラウザ、電子メールインターフェース、チャットインターフェース、及び電話のうちの少なくとも１つから前記サービスチケットを生成すること、をさらに有する請求項１５に記載の方法。
24. 前記保存することの後、他の技術者と共有するために、前記ＲＰを知識ベース（ＫＢ）アーティクルに選択的に変換することをさらに有し、ここで、前記ＫＢアーティクルは、シリーズ化したＲＰを含むものである、請求項１５に記載の方法。

Images