ホーム > 特許ランキング > 株式会社両毛システムズ
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2022047624
(43)【公開日】2022-03-25
(54)【発明の名称】コンピュータシステムおよび接続方法
(51)【国際特許分類】
G06Q 50/06 20120101AFI20220317BHJP
G06F 13/00 20060101ALI20220317BHJP
【ＦＩ】
G06Q50/06
G06F13/00 540A
【審査請求】未請求
【請求項の数】9
【出願形態】ＯＬ
(21)【出願番号】P 2020153511
(22)【出願日】2020-09-14
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＪＡＶＡＳＣＲＩＰＴ
(71)【出願人】
【識別番号】397042218
【氏名又は名称】株式会社両毛システムズ
(74)【代理人】
【識別番号】110002066
【氏名又は名称】特許業務法人筒井国際特許事務所
(72)【発明者】
【氏名】金谷 陽介
(72)【発明者】
【氏名】木村 圭介
(72)【発明者】
【氏名】福田 捷平
(72)【発明者】
【氏名】劉 芳
(72)【発明者】
【氏名】岡田 亮
(72)【発明者】
【氏名】竹内 健吾
【テーマコード（参考）】
5B084
5L049
【Ｆターム（参考）】
5B084AA01
5B084AA12
5B084AA26
5B084AA29
5B084AA30
5B084AB04
5B084AB11
5B084AB18
5B084AB31
5B084BA07
5B084BB02
5B084BB03
5B084BB16
5B084CB12
5B084CB23
5B084CF12
5B084DB02
5B084DB08
5B084DC02
5B084DC03
5B084DC06
5B084DC18
5B084DC28
5L049CC06
(57)【要約】
【課題】各顧客システムが各外部サービスを利用する場合に、顧客システムのセキュリティの確保とともにコストや手間を低減できる技術を提供する。
【解決手段】実施の形態のコンピュータシステムは、複数の顧客システム２と、外部サービスを提供する複数の外部事業者システム（外部システム３）との間に介在し、クラウドコンピューティングに基づいたサービスを提供するコンピュータ（サーバ１０）を備える。コンピュータ（サーバ１０）には、顧客システム２毎に、顧客システム２が利用する１つ以上の外部システム３の外部サービス、および外部サービス毎のＡＰＩ接続方式が設定される。コンピュータ（サーバ１０）は、顧客システム２からのアクセスを受けた場合、設定に基づいて、顧客システム２が利用する外部システム３の外部サービスへＡＰＩ接続方式でアクセスし、外部サービスからの応答を取得して顧客システム２に送信する。
【選択図】図１
【解決手段】実施の形態のコンピュータシステムは、複数の顧客システム２と、外部サービスを提供する複数の外部事業者システム（外部システム３）との間に介在し、クラウドコンピューティングに基づいたサービスを提供するコンピュータ（サーバ１０）を備える。コンピュータ（サーバ１０）には、顧客システム２毎に、顧客システム２が利用する１つ以上の外部システム３の外部サービス、および外部サービス毎のＡＰＩ接続方式が設定される。コンピュータ（サーバ１０）は、顧客システム２からのアクセスを受けた場合、設定に基づいて、顧客システム２が利用する外部システム３の外部サービスへＡＰＩ接続方式でアクセスし、外部サービスからの応答を取得して顧客システム２に送信する。
【選択図】図１
【特許請求の範囲】
【請求項1】
複数の顧客システムと、外部サービスを提供する複数の外部事業者システムとの間に介在し、クラウドコンピューティングに基づいたサービスを提供するコンピュータを備えるコンピュータシステムであって、
前記コンピュータには、顧客システム毎に、顧客システムが利用する１つ以上の外部事業者システムの外部サービス、および前記外部サービス毎のＡＰＩ接続方式が設定され、
前記コンピュータは、前記顧客システムからのアクセスを受けた場合、前記設定に基づいて、前記顧客システムが利用する前記外部事業者システムの前記外部サービスへ前記ＡＰＩ接続方式でアクセスし、前記外部サービスからの応答を取得して前記顧客システムに送信する、
コンピュータシステム。
前記コンピュータには、顧客システム毎に、顧客システムが利用する１つ以上の外部事業者システムの外部サービス、および前記外部サービス毎のＡＰＩ接続方式が設定され、
前記コンピュータは、前記顧客システムからのアクセスを受けた場合、前記設定に基づいて、前記顧客システムが利用する前記外部事業者システムの前記外部サービスへ前記ＡＰＩ接続方式でアクセスし、前記外部サービスからの応答を取得して前記顧客システムに送信する、
コンピュータシステム。
【請求項2】
請求項１記載のコンピュータシステムにおいて、
前記ＡＰＩ接続方式は、少なくとも、ＷｅｂＳｏｃｋｅｔ方式と、コールバック方式とを有する、
コンピュータシステム。
前記ＡＰＩ接続方式は、少なくとも、ＷｅｂＳｏｃｋｅｔ方式と、コールバック方式とを有する、
コンピュータシステム。
【請求項3】
請求項１記載のコンピュータシステムにおいて、
前記顧客システムに備えるクライアント端末には、前記事業者の前記コンピュータとの間で通信して機能を利用するための、ソフトウェアプログラムに基づいた専用ツールを備え、
前記クライアント端末は、前記顧客システムのオペレータによる前記専用ツールの操作に基づいて、前記コンピュータにアクセスし、前記設定の確認のための画面を表示する、
コンピュータシステム。
前記顧客システムに備えるクライアント端末には、前記事業者の前記コンピュータとの間で通信して機能を利用するための、ソフトウェアプログラムに基づいた専用ツールを備え、
前記クライアント端末は、前記顧客システムのオペレータによる前記専用ツールの操作に基づいて、前記コンピュータにアクセスし、前記設定の確認のための画面を表示する、
コンピュータシステム。
【請求項4】
請求項１記載のコンピュータシステムにおいて、
前記コンピュータは、リバースプロキシおよびプロキシを備えるＷｅｂサーバと、ＷｅｂＡＰＩを備えるアプリケーションサーバと、ＤＢサーバとを有し、
前記アプリケーションサーバは、前記外部事業者システムの前記外部サービスから前記ＡＰＩ接続方式でデータを取得した場合、前記データを前記ＤＢサーバのデータベースに格納し、
前記顧客システムは、前記コンピュータに対し、定期的に問合せのアクセスを行い、
前記コンピュータは、前記問合せのアクセスに対し、前記データベースに前記顧客システムの前記データがある場合には前記データを読み出して応答として前記顧客システムに送信する、
コンピュータシステム。
前記コンピュータは、リバースプロキシおよびプロキシを備えるＷｅｂサーバと、ＷｅｂＡＰＩを備えるアプリケーションサーバと、ＤＢサーバとを有し、
前記アプリケーションサーバは、前記外部事業者システムの前記外部サービスから前記ＡＰＩ接続方式でデータを取得した場合、前記データを前記ＤＢサーバのデータベースに格納し、
前記顧客システムは、前記コンピュータに対し、定期的に問合せのアクセスを行い、
前記コンピュータは、前記問合せのアクセスに対し、前記データベースに前記顧客システムの前記データがある場合には前記データを読み出して応答として前記顧客システムに送信する、
コンピュータシステム。
【請求項5】
請求項１記載のコンピュータシステムにおいて、
前記顧客システムは、オペレータと作業者との間で、作業依頼および作業完了報告のやり取りを含む業務を管理するシステムであり、
前記顧客システムが前記業務のために利用する前記外部事業者システムの前記外部サービスとして、ＳＮＳ・チャットサービスを設定可能であり、
前記作業依頼および作業完了報告のやり取りは、前記ＳＮＳ・チャットサービス上での通信として処理される、
コンピュータシステム。
前記顧客システムは、オペレータと作業者との間で、作業依頼および作業完了報告のやり取りを含む業務を管理するシステムであり、
前記顧客システムが前記業務のために利用する前記外部事業者システムの前記外部サービスとして、ＳＮＳ・チャットサービスを設定可能であり、
前記作業依頼および作業完了報告のやり取りは、前記ＳＮＳ・チャットサービス上での通信として処理される、
コンピュータシステム。
【請求項6】
請求項５記載のコンピュータシステムにおいて、
前記顧客システムは、エネルギーインフラ事業者の基幹システムであり、
前記作業者は、利用者のメータの検針や保守を行う保守員であり、
前記作業依頼は、前記利用者の前記メータの検針や保守に関する作業依頼である、
コンピュータシステム。
前記顧客システムは、エネルギーインフラ事業者の基幹システムであり、
前記作業者は、利用者のメータの検針や保守を行う保守員であり、
前記作業依頼は、前記利用者の前記メータの検針や保守に関する作業依頼である、
コンピュータシステム。
【請求項7】
請求項１記載のコンピュータシステムにおいて、
前記顧客システムは、エネルギーインフラ事業者の基幹システムであり、オペレータと作業者との間で、作業依頼および作業完了報告のやり取りを含む業務を管理するシステムであり、
前記作業者は、利用者のメータの検針や保守を行う保守員であり、
前記作業依頼は、前記利用者の前記メータの検針や保守に関する作業依頼であり、
前記複数の外部事業者のうちの少なくとも１つの外部事業者として、前記メータに関する外部サービスを提供するメータ事業者を有し、
前記顧客システムが前記業務のために利用する前記外部事業者システムの前記外部サービスとして、前記メータ事業者の前記外部サービスを設定可能であり、
前記作業依頼および作業完了報告のやり取りは、前記メータ事業者の前記外部サービスを経由する通信として処理される、
コンピュータシステム。
前記顧客システムは、エネルギーインフラ事業者の基幹システムであり、オペレータと作業者との間で、作業依頼および作業完了報告のやり取りを含む業務を管理するシステムであり、
前記作業者は、利用者のメータの検針や保守を行う保守員であり、
前記作業依頼は、前記利用者の前記メータの検針や保守に関する作業依頼であり、
前記複数の外部事業者のうちの少なくとも１つの外部事業者として、前記メータに関する外部サービスを提供するメータ事業者を有し、
前記顧客システムが前記業務のために利用する前記外部事業者システムの前記外部サービスとして、前記メータ事業者の前記外部サービスを設定可能であり、
前記作業依頼および作業完了報告のやり取りは、前記メータ事業者の前記外部サービスを経由する通信として処理される、
コンピュータシステム。
【請求項8】
請求項７記載のコンピュータシステムにおいて、
前記複数の外部事業者のうちの少なくとも１つの外部事業者として、ＳＮＳ・チャットサービスを提供する外部事業者を有し、
前記顧客システムが前記業務のために利用する前記外部事業者システムの前記外部サービスとして、さらに、前記ＳＮＳ・チャットサービスを設定可能であり、
前記作業依頼および作業完了報告のやり取りは、前記メータ事業者の前記外部サービスを経由し、かつ前記ＳＮＳ・チャットサービス上での通信として処理される、
コンピュータシステム。
前記複数の外部事業者のうちの少なくとも１つの外部事業者として、ＳＮＳ・チャットサービスを提供する外部事業者を有し、
前記顧客システムが前記業務のために利用する前記外部事業者システムの前記外部サービスとして、さらに、前記ＳＮＳ・チャットサービスを設定可能であり、
前記作業依頼および作業完了報告のやり取りは、前記メータ事業者の前記外部サービスを経由し、かつ前記ＳＮＳ・チャットサービス上での通信として処理される、
コンピュータシステム。
【請求項9】
複数の顧客システムと、外部サービスを提供する複数の外部事業者システムとの間に介在し、クラウドコンピューティングに基づいたサービスを提供するコンピュータを備えるコンピュータシステムにおける接続方法であって、
前記コンピュータに、顧客システム毎に、顧客システムが利用する１つ以上の外部事業者システムの外部サービス、および前記外部サービス毎のＡＰＩ接続方式が設定されるステップと、
前記コンピュータが、前記顧客システムからのアクセスを受けた場合、前記設定に基づいて、前記顧客システムが利用する前記外部事業者システムの前記外部サービスへ前記ＡＰＩ接続方式でアクセスし、前記外部サービスからの応答を取得して前記顧客システムに送信するステップと、
を有する、接続方法。
前記コンピュータに、顧客システム毎に、顧客システムが利用する１つ以上の外部事業者システムの外部サービス、および前記外部サービス毎のＡＰＩ接続方式が設定されるステップと、
前記コンピュータが、前記顧客システムからのアクセスを受けた場合、前記設定に基づいて、前記顧客システムが利用する前記外部事業者システムの前記外部サービスへ前記ＡＰＩ接続方式でアクセスし、前記外部サービスからの応答を取得して前記顧客システムに送信するステップと、
を有する、接続方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、情報処理や通信に係わるコンピュータシステム等の技術に関し、特に、顧客の組織のシステムと、各種のアプリケーションサービス等を提供する外部事業者のシステムとの間に介在する事業者のクラウドコンピューティングシステム等の技術に関する。
【背景技術】
【0002】
情報処理や通信に係わる事業者は、自治体やインフラ事業者等の団体、会社等の組織を顧客として、顧客の業務処理の一部を請け負う場合や、顧客の業務処理を支援するサービスを提供する場合がある。事業者は、例えばインターネット上にデータセンタやクラウドコンピューティングシステム等のシステム（事業者システムと記載する場合がある）を構築する。事業者システムのサーバ等のコンピュータは、顧客の組織のシステム（顧客システムと記載する場合がある）におけるＬＡＮ（言い換えると内部ネットワークや閉域網）上のコンピュータからのアクセスを受け、処理を行って結果を応答する。
【0003】
顧客システムのＬＡＮ上のコンピュータは、業務処理のために、インターネット等の外部ネットワーク上に存在する外部事業者のシステム（外部システムと記載する場合がある）によるサービス（外部サービスと記載する場合がある）を利用したい場合がある。例えば、顧客システムは、アプリケーション・サービス・プロバイダ（ＡＳＰ）が提供する各種のアプリケーションサービスを利用したい場合がある。顧客システムは、外部サービスの利用によって、例えば業務処理の効率または品質を高める。例えば、顧客がエネルギーインフラのガス事業者である場合、業務として、需要家のガス使用量の検針や料金請求等がある。外部サービスの例としては、決済代行、文書作成、ＳＮＳ・チャットサービス等の各種が挙げられる。ガス事業者の場合、外部サービスの例としては、ガスメータ事業者によるガスメータの自動検針等のサービスも挙げられる。
【0004】
クラウドコンピューティングシステム等に係わる先行技術例としては、特許第６２２５２８３号公報（特許文献１）が挙げられる。特許文献１には、「閉域ネットワーク接続装置」等として、「専用の接続機器や手続などを必要とすることなく、閉域ネットワークと外部ネットワークに接続された外部装置との接続を確立する」旨が記載されている。
【0005】
ガス事業者等のシステムに係わる先行技術例としては、特開２０１６－８１０７３号公報（特許文献２）が挙げられる。特許文献２には、「ガス使用状況管理方法およびプログラム」として、「宅内、宅外のいずれにおいてもガス使用状況（ガス使用量、ガス請求額等）を、簡単かつ見易い形態で確認可能」である旨が記載されている。
【先行技術文献】
【特許文献】
【0006】
【特許文献1】特許第６２２５２８３号公報
【特許文献2】特開２０１６－８１０７３号公報
【発明の概要】
【発明が解決しようとする課題】
【0007】
上記顧客システムのＬＡＮ上のコンピュータが、外部ネットワーク上の外部事業者システムのサーバ等による外部サービスを利用する場合を考える。その場合、一般に、そのコンピュータは、そのサーバが公開するアプリケーション・プログラミング・インタフェース（ＡＰＩ）を通じてそのサーバにアクセスする。その場合、顧客システムのコンピュータは、ＡＰＩ接続方式に応じて、ＩＰアドレス等の情報を外部公開する必要がある場合がある。その外部公開にはセキュリティリスクがある。すなわち、外部からそのコンピュータを通じて顧客システム内に不正アクセスされてデータが漏洩する等の恐れがある。
【0008】
顧客システムは、その外部公開の点に関するセキュリティの確保とともに、利用したい外部サービスのＡＰＩに応じた実装が必要である。ＡＰＩに応じた実装とは、例えばプログラムの設計や、ハードウェアの設置、および運用保守等がある。顧客は、そのような顧客システムの実装や運用保守に係わるコストや手間を要する。
【0009】
また、顧客システムは、複数のアプリケーション等の外部サービスを利用したい場合や、利用する外部サービスを変更したい場合には、それらに応じて、実装や改修に係わるコストや手間をさらに要する。外部サービスに対するＡＰＩ接続方式には、いくつかの種類があり、方式に応じた実装等が必要である。また、顧客は、利用する外部事業者の外部サービス毎に、利用の契約や設定が必要であり、そのための管理や作業に係わるコストや手間も大きい。
【0010】
また、クラウドコンピューティングによるサービスを提供する事業者は、複数の顧客の各々の顧客システムと、複数の外部事業者の各々の外部システムの外部サービスとの間に介在する。顧客に応じて利用したい外部サービスは様々である。従来の事業者システムは、顧客システム毎に異なる各種の外部サービスの利用の要望に対し、対応する場合、個別に各外部サービスへの各ＡＰＩ接続方式での接続が可能なように、各サーバ等の設備を設ける。このような構成は、非効率的な面があり、事業者システムの肥大化や複雑化も招き、事業者のコストや手間が大きい。
【0011】
本発明の目的は、顧客の業務処理等を支援する事業者のクラウドコンピューティングシステム等の技術に関して、各顧客システムが各外部サービスを利用する場合に、顧客システムのセキュリティの確保とともにコストや手間を低減できる技術を提供することである。
【課題を解決するための手段】
【0012】
本発明のうち代表的な実施の形態は、以下に示す構成を有する。実施の形態のコンピュータシステムは、複数の顧客システムと、外部サービスを提供する複数の外部事業者システムとの間に介在し、クラウドコンピューティングに基づいたサービスを提供するコンピュータを備えるコンピュータシステムであって、前記コンピュータには、顧客システム毎に、顧客システムが利用する１つ以上の外部事業者システムの外部サービス、および前記外部サービス毎のＡＰＩ接続方式が設定され、前記コンピュータは、前記顧客システムからのアクセスを受けた場合、前記設定に基づいて、前記顧客システムが利用する前記外部事業者システムの前記外部サービスへ前記ＡＰＩ接続方式でアクセスし、前記外部サービスからの応答を取得して前記顧客システムに送信する。
【発明の効果】
【0013】
本発明のうち代表的な実施の形態によれば、顧客の業務処理等を支援する事業者のクラウドコンピューティングシステム等の技術に関して、各顧客システムが各外部サービスを利用する場合に、顧客システムのセキュリティの確保とともにコストや手間を低減できる。
【図面の簡単な説明】
【0014】
【図1】本発明の実施の形態１のコンピュータシステムを含む、システムの全体概要構成を示す。
【図2】実施の形態１で、特に事業者システムの構成例を示す。
【図3】実施の形態１で、顧客と事業者との契約・設定に係わる構成例を示す。
【図4】実施の形態１で、外部事業者と事業者との契約・設定に係わる構成例を示す。
【図5】実施の形態１で、契約設定確認画面および契約設定情報の例を示す。
【図6】実施の形態１で、ある顧客システムからある外部システムの外部サービスを利用する場合の通信等のシーケンスを示す。
【図7】本発明の実施の形態２に関して、コールセンタ業務の構成例を示す。
【図8】実施の形態２に対する比較例のシステムを示す。
【図9】本発明の実施の形態２のコンピュータシステムの構成を示す。
【図10】実施の形態２で、安全な通信の仕組みについての第１説明図を示す。
【図11】実施の形態２で、安全な通信の仕組みについての第２説明図を示す。
【図12】本発明の実施の形態３に関して、ガスメータ業務の構成例を示す。
【図13】実施の形態３に対する比較例のシステムを示す。
【図14】本発明の実施の形態３のコンピュータシステムの構成を示す。
【図15】従来からあるＡＰＩ接続方式の例として、（Ａ）第１ＡＰＩ接続方式、（Ｂ）第２ＡＰＩ接続方式、および（Ｃ）第３ＡＰＩ接続方式を示す。
【発明を実施するための形態】
【0015】
＜実施の形態１＞
図１～図６等を用いて、本発明の実施の形態１のコンピュータシステム等について説明する。実施の形態１の接続方法は、実施の形態１のコンピュータシステムで実行されるステップを有する方法である。
図１～図６等を用いて、本発明の実施の形態１のコンピュータシステム等について説明する。実施の形態１の接続方法は、実施の形態１のコンピュータシステムで実行されるステップを有する方法である。
【0016】
本開示のコンピュータシステムは、各顧客システムからの各外部サービスの利用の要望に対し、各ＡＰＩ接続方式での各外部サービスへの接続や連携ができるように、統一的に対応できるコンピュータの設備を設ける。このコンピュータシステムは、事業者のコンピュータを介して、複数の顧客システムと複数の外部システムの外部サービスとの間で多対多の関係で接続し、顧客システムからの外部サービスの利用に係わる各ＡＰＩ接続方式での接続を制御する。また、このコンピュータシステムは、多対多の関係での利用に関する契約および設定を容易かつ柔軟に可能とする。顧客は、利用する外部サービスに応じた実装等が不要である。顧客は、顧客システムから各外部サービスの利用の際に、事業者システムを介して容易に利用でき、利用する外部サービスの変更も可能である。
【0017】
［１－１．システム］
図１は、実施の形態１のコンピュータシステムを含む、システム１００の全体概要構成を示す。図１のシステム１００は、インターネットを含む通信網上において、複数の顧客システム２と、複数の外部システム３と、それらの間に介在する事業者システム１とを有する。事業者システム１は、顧客に対しクラウドコンピューティングシステムによるサービス等を提供する事業者によるコンピュータシステムである。顧客システム２は、顧客である団体や会社等の組織のコンピュータシステムである。外部システム３は、外部事業者システムであり、外部事業者が運営するコンピュータシステムである。外部事業者は、顧客および事業者から見て外部サービスを提供する事業者であり、例えばＡＳＰである。外部とは、顧客システム１を内部とした場合の外部である。
図１は、実施の形態１のコンピュータシステムを含む、システム１００の全体概要構成を示す。図１のシステム１００は、インターネットを含む通信網上において、複数の顧客システム２と、複数の外部システム３と、それらの間に介在する事業者システム１とを有する。事業者システム１は、顧客に対しクラウドコンピューティングシステムによるサービス等を提供する事業者によるコンピュータシステムである。顧客システム２は、顧客である団体や会社等の組織のコンピュータシステムである。外部システム３は、外部事業者システムであり、外部事業者が運営するコンピュータシステムである。外部事業者は、顧客および事業者から見て外部サービスを提供する事業者であり、例えばＡＳＰである。外部とは、顧客システム１を内部とした場合の外部である。
【0018】
実施の形態１のコンピュータシステムは、言い換えると、接続システムや通信システムである。実施の形態１のコンピュータシステムは、顧客システム２と外部システム３の外部サービスとの間でのＡＰＩ接続を含む接続を制御するシステムである。実施の形態１のコンピュータシステムは、主に、事業者システム１として実装されている。このコンピュータシステムは、構成要素として、顧客システム２のうちのクライアント端末２０に実装される専用ツール２１（図２）を含む。事業者システム１は、言い換えると、クラウドコンピューティングシステムまたはコンピュータシステムである。事業者システム１は、インターネット上の特定の通信網に構成される。事業者システム１は、クラウドコンピューティングによるサービスによって顧客システム２の業務処理を支援する。事業者システム１は、各顧客および各外部事業者との間での契約・設定に関する管理を行う。事業者システム１は、契約・設定に基づいて、顧客システム２が業務処理のために外部システム３の外部サービスにアクセスする際に介在して接続を制御する。事業者システム１は、顧客からみた利用の選択肢となる複数の外部事業者の外部サービスに対応する実装を有し、それらの外部サービスの各ＡＰＩ接続方式に対応する実装を有する。顧客は、契約・設定の際に、それらの選択肢の範囲から、利用する外部サービスを選択することができる。
【0019】
実施の形態１のコンピュータシステムは、事業者システム１内において、複数の顧客システム２の各クライアント端末２０から複数の外部システム３の各サーバ３０の外部サービスを利用する際に介在して通信・接続を制御する設備を有する。この設備は、特有のプログラムやデータベース（ＤＢ）等を含むサーバ１０を含む。サーバ１０は、言い換えるとクラウドサーバであり、ＷｅｂＡＰＩ１２０やＤＢ１３０を備える。サーバ１０は、プログラム処理等に基づいて実現される所定の機能として、契約・設定管理機能、およびサービス監視機能等を有する。契約・設定管理は、顧客と事業者との間での契約および機能等の設定に関する管理と、外部事業者と事業者との間での契約および設定に関する管理とを含む。契約・設定管理は、顧客からの要望に応じて顧客が利用する機能や外部サービスを変更する設定変更を含む。サービス監視は、顧客システム２からのアクセスに応じて外部システム３の外部サービスにアクセスする際の監視とＡＰＩ接続制御とを含む。サーバ１０は、複数の顧客システム２の各クライアント端末２０からのＨＴＴＰ／ＨＴＴＰＳプロトロコル等でのアクセスを受け付けて応答する部分と、複数の外部システム３のサーバ３０へのアクセスを行って応答を得る部分とを含む。
【0020】
各顧客システム２は、例えば組織の業務処理を管理する基幹システムであり、ＬＡＮ上に接続されるコンピュータとしてクライアント端末２０やサーバ等を有する。本例では、複数の顧客システム２として、顧客システム２Ａ，２Ｂ，……を有する。例えば、顧客Ａの顧客システム２Ａは、クライアント端末２０Ａを有する。顧客組織内の業務担当者等のオペレータＯＰは、クライアント端末２０を操作して業務を行う。クライアント端末２０は、外部システム３のサーバ３０に対し、直接的には通信接続せず、事業者のサーバ１０を介して利用する。なお、クライアント端末２０に専用ツール２１（図２）がインストールされる形態とするが、これに限らず、顧客システム２内のサーバ等の装置に専用ツール２１がインストールされ、そのサーバ等の装置が外部にアクセスする形態でもよい。
【0021】
各外部システム３は、外部サービスを提供するサーバ３０等の設備を有する。サーバ３０は、例えばＷｅｂＡＰＩを備えるＡＰＩサーバである。外部システム３は、サーバ３０がＡＰＩを外部公開し、外部（外部事業者からみた事業者システム１等）からのＡＰＩ接続に応じて外部サービスを提供する。本例では、複数の外部システム３として、外部システム３Ａ，３Ｂ，……，３Ｎを有する。例えば、外部事業者Ａの外部システムＡは、サーバ３０Ａ（ＡＰＩサーバＡ）を有し、サーバ３０Ａは、ＷｅｂＡＰＩによって所定の外部サービスであるサービスＡを提供する。なお、外部システム３は、クラウドコンピューティングシステムであってもよい。
【0022】
外部サービスであるアプリケーションサービスの例は、Ｗｅｂによる情報提供、決済代行、文書作成、ＳＮＳ・チャットサービス等の各種がある。ＳＮＳ・チャットサービスは、グループウェアやメッセンジャーアプリの概念を含み、一対一または所定のグループのユーザ間で、インターネット電話またはテキストチャット等に基づいて、双方向のコミュニケーションを可能とするサービスである。ＳＮＳ・チャットサービス上では、作業等の主題毎に、ユーザ間で、コメントやメッセージ等のやり取りが、時系列上での履歴として可視化および記録される。このようなＳＮＳ・チャットサービスの具体例は、ＬＩＮＥ株式会社によるＬＩＮＥ（登録商標）等が挙げられる。
【0023】
事業者のサーバ１０と外部事業者のサーバ３０との間では、後述するが各種のＡＰＩ接続方式での接続が行われ得る。各実施の形態で扱うＡＰＩ接続方式は、少なくとも、ＷｅｂＳｏｃｋｅｔ方式、およびコールバック方式を有する。
【0024】
なお、各コンピュータシステムは、１つ以上のサーバやＰＣ等のコンピュータ、およびコンピュータで動作する回路またはプログラム等によって構成される。各コンピュータは、プロセッサ、メモリ、通信インタフェース、入出力インタフェース、およびそれらを相互に接続するバス等を備える。プロセッサは、ＣＰＵ、ＲＯＭ、ＲＡＭ等で構成される。各コンピュータは、プロセッサによってメモリ上でプログラムに従った処理を実行することで、各機能や処理部を実現する。なお、各プログラムは、処理主体となるコンピュータに保持されていてもよいし、そのコンピュータの外部の装置、例えば通信網上のサーバ等の装置に保持されているプログラムを利用する形態でもよい。また、非一過性のコンピュータ読み取り可能な記録媒体に格納されているプログラムを利用する形態でもよい。クラウドコンピューティングの場合には、特に複数のコンピュータによって機能等が実現される。複数のコンピュータによって冗長構成や負荷分散等が実現されてもよい。
【0025】
［１－２．事業者システム］
図２は、実施の形態１で、事業者システム１等の構成を示し、特に図１のサーバ１０の詳細構成例を示す。インターネットを含む広域網である通信網５００には、事業者システム１等が接続されている。図２では、事業者システム１に接続されるシステムとしては、簡略的に、顧客Ａの顧客システム２Ａおよび外部事業者Ａの外部システム３Ａのみ示す。顧客システム２である基幹システムは、ＬＡＮ２００上にクライアント端末２０や、サーバやＤＢ、他の通信機器等の設備を有する。クライアント端末２０には、契約に基づいて、専用ツール２１がインストールされている。専用ツール２１は、例えば、アプリとして、事業者システム１からクライアント端末２０へ配信されインストールされる。外部システム３ＡのＡＰＩサーバＡであるサーバ３０Ａは、ＷｅｂＡＰＩ３００を備え、サービスＡを提供する。
図２は、実施の形態１で、事業者システム１等の構成を示し、特に図１のサーバ１０の詳細構成例を示す。インターネットを含む広域網である通信網５００には、事業者システム１等が接続されている。図２では、事業者システム１に接続されるシステムとしては、簡略的に、顧客Ａの顧客システム２Ａおよび外部事業者Ａの外部システム３Ａのみ示す。顧客システム２である基幹システムは、ＬＡＮ２００上にクライアント端末２０や、サーバやＤＢ、他の通信機器等の設備を有する。クライアント端末２０には、契約に基づいて、専用ツール２１がインストールされている。専用ツール２１は、例えば、アプリとして、事業者システム１からクライアント端末２０へ配信されインストールされる。外部システム３ＡのＡＰＩサーバＡであるサーバ３０Ａは、ＷｅｂＡＰＩ３００を備え、サービスＡを提供する。
【0026】
図１のサーバ１０は、図２では、主に、Ｗｅｂサーバ１１、アプリケーション（ＡＰ）サーバ１２、およびＤＢサーバ１３で構成される。また、図２では、事業者システム１は、ファイアウォールサーバＦＷ１，ＦＷ２，ＦＷ３を有する。事業者システム１は、通信網５００に近い順に、ファイアウォールサーバＦＷ１、Ｗｅｂサーバ１１、ファイアウォールサーバＦＷ２、ＡＰサーバ１２、ファイアウォールサーバＦＷ３、およびＤＢサーバ１３を有する。各ファイアウォールサーバＦＷ１，ＦＷ２，ＦＷ３は、不正な通信を発見・防止する機能を有する。
【0027】
Ｗｅｂサーバ１１は、リバースプロキシ１１０およびプロキシ１１１を有する第１サーバである。Ｗｅｂサーバ１１は、外部公開部分１０１，１０２を有する。外部公開部分１０１，１０２は、ＩＰアドレス（対応するＵＲＬ）等の情報が外部公開される部分である。顧客システム２のクライアント端末２０は、Ｗｅｂサーバ１１の外部公開部分１０１のＩＰアドレスに対しＨＴＴＰＳプロトコルでアクセスする。外部システム３のサーバ３０は、Ｗｅｂサーバ１１の外部公開部分１０２のＩＰアドレスに対しＨＴＴＰＳプロトコルでアクセスする。なお、外部公開部分１０１，１０２として２つに分けて図示しているが、これは、ＡＰＩのＵＲＬが異なることに対応しており、顧客システム２から見た外部公開部分１０１は一方のＵＲＬ、外部システム３から見た外部公開部分１０２はもう一方のＵＲＬに対応している。これらのＵＲＬは、ＩＰアドレスとしては同一となる。リバースプロキシ１１０およびプロキシ１１１は、プログラム等により実装される。リバースプロキシ１１０は、不特定多数のクライアントからのアクセスを受け付け、負荷の制限や分散とともに、特定のサーバ、すなわち本例でのＡＰサーバ１２への要求を透過させる部分である。リバースプロキシ１１０は、サーバ１０の外から内への通信制御を担う部分であり、プロキシ１１１は、内から外への通信制御を担う部分である。Ｗｅｂサーバ１１は、例えばクライアント端末２０からのＨＴＴＰＳ要求を受けると、ＡＰサーバ１２へのＵＲＬ（対応する要求）に変換してＡＰサーバ１２へ転送する。なお、事業者システム１は、Ｗｅｂサーバ１１等において、クライアント等の認証の機能を設けてもよい。その場合、セキュリティを高め、シングルサインオンが実現できる。
【0028】
ＡＰサーバ１２は、接続制御を実現するためのＷｅｂＡＰＩ１２０を有し、顧客システム２や外部システム３からの要求や応答を、設定に基づいて処理し、処理結果の応答をＷｅｂサーバ１１に返す。ＡＰサーバ１２は、適宜にＤＢサーバ１３にアクセスしてＤＢ１３０のデータを読み書きする。
【0029】
また、事業者システム１は、管理者ＡＤが操作する管理端末１５０から、サーバ１０（例えばＷｅｂサーバ１１やＡＰサーバ１２）の設定や保守が可能である。
【0030】
［１－３．顧客との契約・設定］
図３は、実施の形態１で、顧客と事業者との契約・設定に係わる構成例を示す。図３の例では、複数の顧客の複数の顧客システム２として、顧客Ａ，Ｂ，Ｃ等の顧客システム２Ａ，２Ｂ，２Ｃ等を有する。顧客の担当者は、事業者の担当者との間で、事業者システム１の利用に係わる契約および設定を行う。顧客の担当者は、事業者が提示する情報に基づいて、顧客システム２から利用したい外部事業者の外部サービスを候補範囲から選択し、事業者の担当者に対し、契約・設定依頼をする。設定依頼は、事業者システム１が提供するサービスの機能の選択や機能の詳細に関する設定依頼や、利用する外部サービスの機能の詳細に関する設定依頼を含む。事業者の担当者は、契約・設定依頼に応じて、顧客との契約を行う。事業者の管理者ＡＤは、設定依頼に応じて、管理サーバ１４に対し、顧客毎の設定を行う。
図３は、実施の形態１で、顧客と事業者との契約・設定に係わる構成例を示す。図３の例では、複数の顧客の複数の顧客システム２として、顧客Ａ，Ｂ，Ｃ等の顧客システム２Ａ，２Ｂ，２Ｃ等を有する。顧客の担当者は、事業者の担当者との間で、事業者システム１の利用に係わる契約および設定を行う。顧客の担当者は、事業者が提示する情報に基づいて、顧客システム２から利用したい外部事業者の外部サービスを候補範囲から選択し、事業者の担当者に対し、契約・設定依頼をする。設定依頼は、事業者システム１が提供するサービスの機能の選択や機能の詳細に関する設定依頼や、利用する外部サービスの機能の詳細に関する設定依頼を含む。事業者の担当者は、契約・設定依頼に応じて、顧客との契約を行う。事業者の管理者ＡＤは、設定依頼に応じて、管理サーバ１４に対し、顧客毎の設定を行う。
【0031】
図３の事業者システム１は、契約・設定管理に係わる管理サーバ１４と、管理者ＡＤの操作する管理端末１５０とを有する。管理サーバ１４は、サーバ１０と接続される。管理サーバ１４は、機能として契約・設定管理機能１４０を有し、契約・設定管理機能１４０によって契約・設定情報１４１を記憶・管理する。管理者ＡＤは、管理端末１５０から管理サーバ１４にアクセスし、管理サーバ１４が提供する画面（Ｗｅｂページ等）で、顧客毎の契約・設定の情報を入力する。管理サーバ１４は、契約・設定管理機能１４０によって、入力情報を契約・設定情報１４１に格納して登録する。管理サーバ１４は、契約・設定情報１４１での設定に基づいて、サーバ１０のプログラムに接続制御のための情報を設定する。もしくは、サーバ１０は、必要に応じて管理サーバ１４の契約・設定情報１４１を参照するようにしてもよい。
【0032】
また、事業者システム１は、管理サーバ１４の契約・設定情報１４１に基づいて、各顧客システム２のクライアント端末２０に対し、その顧客の契約・設定の確認のための画面である契約・設定確認画面２２を提供する。顧客の担当者は、顧客システム２の契約・設定の状態を確認したい場合、クライアント端末２０から、専用ツール２１を通じて、事業者システム１のサーバ１０にアクセスする。サーバ１０は、管理サーバ１４の契約・設定情報１４１に基づいて、契約・設定確認画面２２のデータ（例えばＷｅｂページ）を応答する。クライアント端末２０は、そのデータに基づいて、表示デバイス画面に契約・設定確認画面２２を表示する。顧客の担当者は、その契約・設定確認画面２２で、顧客システム２の契約・設定の状態を確認できる。また、顧客の担当者は、その契約・設定確認画面２２で、顧客システム２の契約・設定の変更に係わる依頼の情報を入力して、事業者システム１にデータとして送信することもできる。
【0033】
顧客と事業者との間での契約および初期設定については、基本的には、顧客の担当者と事業者の担当者との間での対面、書面、あるいは有人オペレータによる作業等によって成立させ、一部についてはオンラインで可能とする。事業者の担当者は、顧客の担当者からの契約・設定依頼や指示等の情報に基づいて、例えば管理サーバ１４に契約および初期設定の情報を入力し登録する。契約および初期設定の後、顧客は、顧客システム２から事業者システム１を介して外部サービスの利用が可能となる。一旦、顧客毎の契約および初期設定がされた後では、顧客は、自分の契約および設定の状態について、クライアント端末２０の契約・設定確認画面２２を通じて、オンラインで確認可能である。契約・設定確認画面２２では、顧客が利用する外部サービスや機能の変更についての要望を受け付ける。事業者の担当者、例えば管理者ＡＤは、顧客システム２から契約・設定確認画面２２等を通じてその変更の要望を受けた場合、管理サーバ１４に対し設定変更を行う。これにより、契約・設定情報１４１が更新され、その後、契約・設定確認画面２２の表示内容も更新される。
【0034】
なお、変形例としては、顧客と事業者との間でオンラインでの契約および設定を行う機能を設けてもよい。
【0035】
［１－４．外部事業者との契約・設定］
事業者と外部事業者との間では、予め、外部サービスの利用に係わる契約および設定が行われる。その結果、事業者システム１に登録された外部サービスは、顧客が選択できる外部サービスの選択肢となる。
事業者と外部事業者との間では、予め、外部サービスの利用に係わる契約および設定が行われる。その結果、事業者システム１に登録された外部サービスは、顧客が選択できる外部サービスの選択肢となる。
【0036】
図４は、実施の形態１で、事業者と外部事業者との契約・設定に係わる構成例を示す。予め、事業者の担当者は、各外部事業者の担当者との間で、事業者システム１の機能、すなわち顧客システム２からの外部サービスの利用および接続制御に係わる契約・設定を行う。事業者の管理者ＡＤは、例えば図３と同様に、管理端末１５０から管理サーバ１４に、各外部サービスの契約・設定に係わる情報を入力して登録する。管理サーバ１４は、契約・設定管理機能１４０によって、契約・設定情報１４１に、外部サービスに関する設定情報を格納する。管理サーバ１４は、サーバ１０に、契約・設定情報１４１を反映する。
【0037】
図４中では、複数の外部サービスおよびＡＰＩ接続方式の例も示している。外部事業者の外部システム３として、例えば外部システム３－１，３－２，３－３等を有する。例えば、外部事業者＃１の外部システム３－１は、ＷｅｂＡＰＩによって外部サービスを提供するサーバ３０として、サービス＃１を提供するＡＰＩサーバ＃１（３０－１）を有する。サービス＃１は、例えばＷｅｂによる所定の情報の提供である。各ＡＰＩサーバ＃１，＃２，＃３は、外部公開部分３０１を有する。ＡＰＩサーバ＃１は、第１ＡＰＩ接続方式として、一般的なＨＴＴＰまたはＨＴＴＰＳによる方式で、サービス＃１を提供する。
【0038】
また、例えば、外部事業者＃２の外部システム３－２は、ＷｅｂＡＰＩによって外部サービスを提供するサーバ３０として、サービス＃２を提供するＡＰＩサーバ＃２（３０－２）を有する。サービス＃２は、例えば決済代行サービスである。ＡＰＩサーバ＃２は、第２ＡＰＩ接続方式として、ＷｅｂＳｏｃｋｅｔ方式で、サービス＃２を提供する。
【0039】
また、例えば、外部事業者＃３の外部システム３－３は、ＷｅｂＡＰＩによって外部サービスを提供するサーバ３０として、サービス＃３を提供するＡＰＩサーバ＃３（３０－３）を有する。サービス＃３は、例えばＳＮＳ・チャットサービスである。ＡＰＩサーバ＃３は、第３ＡＰＩ接続方式として、コールバック方式で、サービス＃３を提供する。
【0040】
［１－５．契約設定確認画面および契約設定情報］
図５の（Ａ）は、契約・設定確認画面２２の例を示し、（Ｂ）は契約・設定情報１４１の例を示す。（Ａ）の契約・設定確認画面２２は、顧客や顧客システム２の情報、事業者システム１の情報（例えば外部公開のＩＰアドレス／ＵＲＬ）、利用する外部サービスの情報等が表示される。「利用する外部サービス」欄には、利用する複数の外部サービス（例えば外部サービスＡ，Ｂ）の情報が表示されている。また、顧客の担当者は、利用する外部サービスの詳細設定を確認または変更したい場合、詳細ボタンを押し、外部サービス毎の設定画面で詳細を確認または変更できる。また、顧客の担当者は、利用する外部サービスを変更したい場合、外部サービス項目のリストボックス等に表示される選択肢から選択できる。顧客の担当者は、変更依頼ボタンを押すことで、変更依頼を事業者システム１に送信できる。
図５の（Ａ）は、契約・設定確認画面２２の例を示し、（Ｂ）は契約・設定情報１４１の例を示す。（Ａ）の契約・設定確認画面２２は、顧客や顧客システム２の情報、事業者システム１の情報（例えば外部公開のＩＰアドレス／ＵＲＬ）、利用する外部サービスの情報等が表示される。「利用する外部サービス」欄には、利用する複数の外部サービス（例えば外部サービスＡ，Ｂ）の情報が表示されている。また、顧客の担当者は、利用する外部サービスの詳細設定を確認または変更したい場合、詳細ボタンを押し、外部サービス毎の設定画面で詳細を確認または変更できる。また、顧客の担当者は、利用する外部サービスを変更したい場合、外部サービス項目のリストボックス等に表示される選択肢から選択できる。顧客の担当者は、変更依頼ボタンを押すことで、変更依頼を事業者システム１に送信できる。
【0041】
なお、顧客システム２における基幹システムは、予め業務処理機能が実装されており、業務処理のための画面は別に存在する。オペレータＯＰは、クライアント端末２０のその画面で、業務処理に係わる例えば作業依頼や作業完了報告等の情報を確認や入力できる。なお、業務処理機能を備える基幹システムに、専用ツール２１が一体として実装された形態としてもよい。
【0042】
（Ｂ）の契約・設定情報１４１の表は、データ項目として、顧客、ログイン（認証）、利用する外部事業者、利用する外部サービス（ＡＰＩ）、およびＡＰＩ接続方式等を有する。顧客システム２毎に、１つ以上の行での設定情報を有する。「顧客」項目は、顧客システム２の識別情報等が格納されている。「ログイン（認証）」項目は、顧客システム２からサーバ１０にアクセスする際に、ログインや認証を必要とする場合の、ＩＤ等の認証情報が格納されている。顧客システム２毎に認証情報は例えば１つとすることができる。「利用する外部事業者」項目は、その顧客システム２が利用する外部事業者の識別情報等が格納されている。「利用する外部サービス（ＡＰＩ）」項目は、その顧客システム２が利用する外部事業者の外部サービスの識別情報等が格納されている。本例では、選択肢となる外部サービスは、１．決済代行サービス、２．ＳＮＳ・チャットサービス（種別Ａ）、３．ＳＮＳ・チャットサービス（種別Ｂ）、４．情報提供、５．文書作成、……等がある。また、本例では、ＳＮＳ・チャットサービスのカテゴリでも、さらに、複数の種別（Ａ，Ｂ）がある。例えば、ある外部事業者はＳＮＳ・チャットサービスＡを提供し、別の外部事業者はＳＮＳ・チャットサービスＢを提供している。顧客は、それらから選択して利用できる。
【0043】
「ＡＰＩ接続方式」項目は、対応する外部サービスのＡＰＩ接続方式の識別情報が格納されている。ＡＰＩ接続方式は、例えば、１．一般的なＨＴＴＰＳ、２．ＷｅｂＳｏｃｋｅｔ、３．コールバック、等がある。例えば、１の決済代行サービスのＡＰＩ接続方式は、２のＷｅｂＳｏｃｋｅｔ方式である。２のＳＮＳ・チャットサービス（種別Ａ）のＡＰＩ接続方式は、３のコールバック方式である。
【0044】
この契約・設定情報１４１の例では、複数の顧客システム２と複数の外部システム３との間での外部サービスの利用に関する設定例が示されている。１，２行目では、顧客システム２Ａは、外部システム３Ａの外部サービス（１．決済代行）、および外部システム３Ｂの外部サービス（２．ＳＮＳ・チャット（種別Ａ））を利用する設定となっている。３，４行目では、顧客システム２Ｂは、外部システム３Ａの外部サービス（１．決済代行）、および外部システム３Ｃの外部サービス（３．ＳＮＳ・チャット（種別Ｂ））を利用する設定となっている。５行目では、顧客システム２Ｃは、外部システム３Ｄの外部サービス（４．情報提供）を利用する設定となっている。６行目では、顧客システム２Ｄは、外部システム３Ｅの外部サービス（５．文書作成）を利用する設定となっている。
【0045】
［１－６．ＡＰＩ接続方式］
図１５は、従来から存在するＡＰＩ接続方式や利用形態の例として、（Ａ）第１ＡＰＩ接続方式、（Ｂ）第２ＡＰＩ接続方式、および（Ｃ）第３ＡＰＩ接続方式を示す。実施の形態１のコンピュータシステムは、これらのＡＰＩ接続方式に対応する実装を有する。
図１５は、従来から存在するＡＰＩ接続方式や利用形態の例として、（Ａ）第１ＡＰＩ接続方式、（Ｂ）第２ＡＰＩ接続方式、および（Ｃ）第３ＡＰＩ接続方式を示す。実施の形態１のコンピュータシステムは、これらのＡＰＩ接続方式に対応する実装を有する。
【0046】
図１５を用いて、前述の課題等について補足説明する。第１の課題として、顧客の業種に依らずに、セキュリティリスクや保守運用コスト等の点がある。一般に、クラウドサービス間の連携においては、ＷｅｂＡＰＩ（Web Application Programing Interface）として仕様が統一された仕組みで、サーバ同士の間、またはサーバとクライアントとの間で通信する。この通信で、インターネットである広域網、もしくは閉域網を介したオンラインで、データ交換等が行われる。なお、一般的なクライアント・サーバ・システムの文脈において、サーバとは、サーバ装置やサーバプログラム等を指し、クライアントとは、クライアント装置やクライアントプログラム等を指す。
【0047】
図１５の（Ａ）で、第１ＡＰＩ接続方式として、一般的なＨＴＴＰＳ方式を示す。本例では、クライアント端末Ａ１１からＡＰＩサーバであるサーバＡ１２のＷｅｂＡＰＩを一方的に利用する場合を示す。この場合、クライアント端末Ａ１１ではＵＲＬ等の情報が外部公開されている必要は無く、サーバＡ１２でＵＲＬやＩＰアドレスやＷｅｂＡＰＩ等の情報が外部公開されていればよい。破線で示す外部公開部分Ａ１４は、ＵＲＬやＩＰアドレスやＷｅｂＡＰＩ等の情報が外部公開されていることを表す。クライアント端末Ａ１１からサーバＡ１２へのアクセスは、ＨＴＴＰもしくはＨＴＴＰＳプロトコルによる通信である。例えば、クライアント端末Ａ１１は、ＷｅｂＡＰＩを利用するためのＨＴＴＰＳ要求をサーバＡ１２へ送信し、サーバＡ１２は、その要求に応じてＷｅｂＡＰＩの処理を行い、結果をＨＴＴＰＳ応答としてクライアント端末Ａ１１へ送信する。これは、一般的にＰＣやスマートフォン等の端末からインターネット上のサービス（例えばＷｅｂページ閲覧）を利用する形態と同じである。
【0048】
しかし、従来、下記ＡＰＩ接続方式を利用する場合には、ＡＰＩサーバからクライアント端末へアクセスする必要があり、この場合には、クライアント端末でＩＰアドレス等の情報の外部公開が必須条件となる。これにより、前述のように、顧客システムでのセキュリティリスク等の課題がある。この種のＡＰＩ接続形態として、下記の２つの方式が挙げられる。
【0049】
図１５の（Ｂ）は、第２ＡＰＩ接続方式として、ＷｅｂＳｏｃｋｅｔ方式の場合を示す。ＷｅｂＳｏｃｋｅｔは、コンピュータネットワークの通信規格の１つである。本例では、クライアント端末Ｂ２１と、ＷｅｂＡＰＩを提供するＡＰＩサーバであるサーバＢ２２との間で、ＷｅｂＳｏｃｋｅｔ接続として、双方向通信用トンネル接続を行う。クライアント端末Ｂ２１は、固定ＩＰアドレスを有し、外部公開部分Ｂ２３を有する。サーバＢ２２は、外部公開部分Ｂ２４を有する。クライアント端末Ｂ２１は、サーバＢ２２との間で、確立されたＷｅｂＳｏｃｋｅｔを通じて双方向通信する。
【0050】
図１５の（Ｃ）は、第３ＡＰＩ接続方式として、コールバック方式、言い換えると、外部サービスのコールバックＡＰＩの利用方式の場合を示す。本例では、クライアント端末Ｃ３１は、ＷｅｂＡＰＩを備え、固定ＩＰアドレスを有し、外部公開部分Ｃ３３を有する。ＷｅｂＡＰＩを備えるＡＰＩサーバであるサーバＣ３２は、外部公開部分Ｃ３４を有する。この方式では、クライアント端末Ｃ３１から例えばデータ要求のためにＨＴＴＰＳ等に基づいてサーバＣ３２のＷｅｂＡＰＩを呼び出し、その後、サーバＣ３２から例えばデータ応答のためにクライアント端末Ｃ３１のＷｅｂＡＰＩを呼び出す。このような動作はコールバックと呼ばれる。
【0051】
上記（Ｂ），（Ｃ）の２つのＡＰＩ接続方式の例では、クライアントに対応する顧客システム２のクライアント端末２０（図１）において、固定ＩＰアドレスと外部公開部分（Ｂ２３，Ｃ３３）、および２４時間稼働が前提の機器や設備等が必要である。これにより、前述のように、顧客システムの実装や保守運用のコストの課題がある。また、上記２つの例のいずれの場合でも、クライアント端末を外部公開するための契約や機器等は、顧客が管理や用意する必要があり、管理コストが高い。
【0052】
また、複数の顧客システムに対しクラウドサービスを提供する事業者から上記課題をみた場合、事業者は、図１５のような各種のＡＰＩ接続方式で外部サービスにアクセスするクライアントの数に応じて、それぞれに実装や運用保守が必要であることから、事業者システムの管理等のコストが高くなる。
【0053】
例えば、第１顧客の第１顧客システムは、第１外部事業者の第１外部サービス（対応するＷｅｂＡＰＩ）をＷｅｂＳｏｃｋｅｔ方式で利用し、第２顧客の第２顧客システムは、第２外部事業者の第２外部サービス（対応するＷｅｂＡＰＩ）をコールバック方式で利用する。また例えば、第３顧客の第３顧客システムは、第３外部事業者の第３外部サービスをＷｅｂＳｏｃｋｅｔ方式で利用するとともに、第４外部事業者の第４外部サービスをコールバック方式で利用する。このように、複数の顧客と複数の外部事業者の外部サービスとの間では、多様な対応関係で接続が行われ得る。事業者がそれらのすべてに対応できるためには、顧客の要望毎に個別に対応する実装、あるいは、それらの実装を合わせた複雑で煩雑な実装が必要であり、多大なコストや手間が必要である。
【0054】
上記課題に対し、図１等に示す実施の形態１のコンピュータシステムは、事業者システム１における特有のサーバ１０を設ける。サーバ１０は、複数の顧客システム２からの複数の外部サービスへの利用のアクセスの要求に対し、契約・設定情報に基づいて、各ＡＰＩ接続方式に対応して接続を制御する。
【0055】
［１－７．接続制御シーケンス］
図６は、図１等に示す実施の形態１のコンピュータシステムで、例えば顧客Ａの顧客システム２Ａから外部事業者Ａの外部システム３Ａの外部サービス（サービスＡ）を利用する場合の通信等のシーケンスを示す。ステップＳ０として、予め、サーバ１０（特にＷｅｂサーバ１１およびＡＰサーバ１２）には、前述の契約・設定に基づいて、各顧客システム２と各外部システム３の外部サービスとの間での利用・接続に関する設定情報が反映されている。例えば、顧客システム２Ａが外部システム３Ａの外部サービス（サービスＡ）を所定のＡＰＩ接続方式で利用する設定がされている。
図６は、図１等に示す実施の形態１のコンピュータシステムで、例えば顧客Ａの顧客システム２Ａから外部事業者Ａの外部システム３Ａの外部サービス（サービスＡ）を利用する場合の通信等のシーケンスを示す。ステップＳ０として、予め、サーバ１０（特にＷｅｂサーバ１１およびＡＰサーバ１２）には、前述の契約・設定に基づいて、各顧客システム２と各外部システム３の外部サービスとの間での利用・接続に関する設定情報が反映されている。例えば、顧客システム２Ａが外部システム３Ａの外部サービス（サービスＡ）を所定のＡＰＩ接続方式で利用する設定がされている。
【0056】
例えば、顧客システム２ＡのオペレータＯＰは、業務処理のために、クライアント端末２０Ａを操作する。ステップＳ１で、クライアント端末２０Ａは、専用ツール２１を通じて、例えば業務に係わるデータの取得等のために、まず、事業者システム１のサーバ１０、特にＷｅｂサーバ１１の外部公開部分１０１のＵＲＬ等に対し、ＨＴＴＰＳ要求でアクセスする。
【0057】
ステップＳ２で、Ｗｅｂサーバ１１は、クライアント端末２Ａからのアクセスを受けると、認証等の後、設定情報に基づいて、その要求を、ＡＰサーバ１２に転送する。ステップＳ３で、ＡＰサーバ１２は、設定情報に基づいて、その要求を解釈し、外部サービス（サービスＡ）へのデータ取得等の要求であるため、その要求をＷｅｂサーバ１１に返す。
【0058】
ステップＳ４で、Ｗｅｂサーバ１１は、その要求を、外部システム３Ａのサーバ３０Ａの外部公開部分３０１のＵＲＬ等に宛ててＨＴＴＰＳ要求で送信する。ステップＳ５で、外部システム３Ａのサーバ３０Ａは、その要求を受けると、ＷｅｂＡＰＩ３００によってサービスＡの処理を行い、例えば取得要求されているデータを含む応答を、事業者システム１のＷｅｂサーバ１１の外部公開部分１０２に宛ててＨＴＴＰＳ応答で送信する。
【0059】
ステップＳ６で、事業者システム１のＷｅｂサーバ１１は、サーバ３０Ａからの応答を受けると、設定情報に基づいて、その応答をＡＰサーバ１２へ転送する。ステップＳ７で、ＡＰサーバ１２は、その応答を解釈し、その応答に含まれるデータを取り出し、ＤＢサーバ１３のＤＢ１３０に格納する。
【0060】
一方、ステップＳ８で、顧客システム２Ａのクライアント端末２０Ａは、ステップＳ１でのデータ取得要求に対するデータ取得応答を待っており、例えば、定期的に確認のアクセスを行う。ステップＳ９で、Ｗｅｂサーバ１１は、クライアント端末２０Ａからの確認のアクセスを受けると、対応する要求をＡＰサーバ１２へ転送する。ステップＳ１０で、ＡＰサーバ１２は、確認の要求を受けると、応答のデータがあるかどうか、ＤＢサーバ１３のＤＢ１３０を調べ、応答のデータがある場合には、その応答のデータをＷｅｂサーバ１１に返す。ステップＳ１１で、Ｗｅｂサーバ１１は、その応答のデータを含むＨＴＴＰＳ応答を、クライアント端末２０Ａに送信する。クライアント端末２０Ａは、その応答のデータを取得する。
【0061】
上記シーケンスで、サーバ１０とサーバ３０との間の通信（ステップＳ４～Ｓ５）は、設定情報に基づいて、サーバ３０のＷｅｂＡＰＩ３００のＡＰＩ接続方式に応じた通信として、サーバ１０によって制御される。
【0062】
［１－８．効果等］
上記のように、実施の形態１のコンピュータシステム等によれば、主な効果として以下を有する。実施の形態１によれば、各顧客システム２が各外部事業者の外部サービスを利用する場合に、事業者システム１のサーバ１０が各ＡＰＩ接続方式での接続を制御するので、顧客システム２のセキュリティの確保とともにコストや手間を低減できる。顧客システム２は、固定ＩＰアドレス等の外部公開や、ＡＰＩ接続のためのソフトウェアやハードウェアの保有や実装が不要であり、実装や運用保守等のコストや手間が低減できる。顧客は、外部公開によるセキュリティリスクを低減・回避できる。また、顧客は、各種の外部サービスの利用のための各外部事業者との契約や設定とその管理が不要であり、コストや手間が低減できる。顧客は、利用する外部サービスや詳細機能の変更等も容易となる。顧客システム２は、インターネット接続環境さえあれば、事業者システム１を経由して、各種の外部サービスを効率的に利用できる。
上記のように、実施の形態１のコンピュータシステム等によれば、主な効果として以下を有する。実施の形態１によれば、各顧客システム２が各外部事業者の外部サービスを利用する場合に、事業者システム１のサーバ１０が各ＡＰＩ接続方式での接続を制御するので、顧客システム２のセキュリティの確保とともにコストや手間を低減できる。顧客システム２は、固定ＩＰアドレス等の外部公開や、ＡＰＩ接続のためのソフトウェアやハードウェアの保有や実装が不要であり、実装や運用保守等のコストや手間が低減できる。顧客は、外部公開によるセキュリティリスクを低減・回避できる。また、顧客は、各種の外部サービスの利用のための各外部事業者との契約や設定とその管理が不要であり、コストや手間が低減できる。顧客は、利用する外部サービスや詳細機能の変更等も容易となる。顧客システム２は、インターネット接続環境さえあれば、事業者システム１を経由して、各種の外部サービスを効率的に利用できる。
【0063】
また、実施の形態１によれば、顧客が複数の外部事業者の外部サービスを利用する場合に、それらの複数の外部サービスの仕様の差異（特にＡＰＩ接続方式の差異）が大きい場合にも、事業者システム１によってその差異を吸収し、顧客システム２に対し統合的なサービスとして提供することができる。顧客システム２側は、複数の外部サービスの仕様の差異を気にする必要が無く、事業者システム１に対する統一化されたインタフェースや手続きのみで、複数の外部サービスを容易に利用できる。これにより、顧客は、業務や管理に係わるコストを低減できる。顧客は、低いコストで外部サービスを利用できるので、業務処理効率化等のために、各種の外部サービスを積極的に利用しやすくなる。
【0064】
＜実施の形態２＞
図７～図９等を用いて、本発明の実施の形態２のコンピュータシステム等について説明する。実施の形態２等の基本的な構成は実施の形態１と同様であり、以下では実施の形態２等における実施の形態１とは異なる構成部分について説明する。実施の形態２では、エネルギーインフラ事業者である顧客システムと顧客システムが利用する外部事業者の外部サービスの具体例、およびその具体例に対応した事業者システム１の実装例を示す。実施の形態２では、顧客の業務としてコールセンタ業務を含む場合の例を示し、コールセンタ業務効率向上を実現する。また、実施の形態２等の例では、事業者システム１は、顧客であるガス事業者の業務処理を支援する。このガス事業者の業務は、需要家のガス使用量の把握や料金請求、ガスメータの自動検針や点検・保守等がある。ガスメータの自動検針は、ガス事業者からみた外部事業者である例えばガスメータ事業者によって行われる場合もある。
図７～図９等を用いて、本発明の実施の形態２のコンピュータシステム等について説明する。実施の形態２等の基本的な構成は実施の形態１と同様であり、以下では実施の形態２等における実施の形態１とは異なる構成部分について説明する。実施の形態２では、エネルギーインフラ事業者である顧客システムと顧客システムが利用する外部事業者の外部サービスの具体例、およびその具体例に対応した事業者システム１の実装例を示す。実施の形態２では、顧客の業務としてコールセンタ業務を含む場合の例を示し、コールセンタ業務効率向上を実現する。また、実施の形態２等の例では、事業者システム１は、顧客であるガス事業者の業務処理を支援する。このガス事業者の業務は、需要家のガス使用量の把握や料金請求、ガスメータの自動検針や点検・保守等がある。ガスメータの自動検針は、ガス事業者からみた外部事業者である例えばガスメータ事業者によって行われる場合もある。
【0065】
［２－１．コールセンタ業務］
図７は、実施の形態２に関して、前提となるコールセンタ業務の構成例を示す。図７の上部は、顧客の例としてガス事業者におけるコールセンタ業務の構成例を示す。ガス事業者は、業務の一部としてコールセンタ業務を有する。このコールセンタ業務は、業務担当者であるオペレータＯＰと、作業者である例えば保守員Ｈとの間で、作業依頼および作業完了報告等のやり取りを行う業務である。作業者である保守員Ｈは、ガス事業者の社員でもよいし、協力会社社員でもよい。本例では、ガス事業者のコールセンタ業務の例を説明するが、これに限らず、コールセンタ業務を有する任意の顧客や業種に適用可能である。
図７は、実施の形態２に関して、前提となるコールセンタ業務の構成例を示す。図７の上部は、顧客の例としてガス事業者におけるコールセンタ業務の構成例を示す。ガス事業者は、業務の一部としてコールセンタ業務を有する。このコールセンタ業務は、業務担当者であるオペレータＯＰと、作業者である例えば保守員Ｈとの間で、作業依頼および作業完了報告等のやり取りを行う業務である。作業者である保守員Ｈは、ガス事業者の社員でもよいし、協力会社社員でもよい。本例では、ガス事業者のコールセンタ業務の例を説明するが、これに限らず、コールセンタ業務を有する任意の顧客や業種に適用可能である。
【0066】
本例では、顧客システム２は、ガス事業者の基幹システムである。顧客システム２は、ガス事業者と提携するコールセンタシステム等でもよい。顧客システム２は、ＬＡＮ上のクライアント端末等の他に、電話業務に対応できるＣＴＩ（Computer Telephony Integration）サーバ等を備えるシステムである。
【0067】
ガス事業者に対しての顧客ないしエンドユーザであるガス利用者ＥＵは、例えば自宅または近隣のガスの状態等に関する問合せを電話等で顧客システムに対し行う。ガス利用者ＥＵは、スマートフォン等の端末４０を所持している。顧客システム２で、オペレータＯＰは、ガス利用者ＥＵからの問合せを電話で受けて対応する。オペレータＯＰが使用するＰＣ等のクライアント端末には、業務処理機能を持つＯＳ等が搭載されている。オペレータＯＰによる対応は、例えば、保守員Ｈに対する、ガス利用者ＥＵの自宅または近隣のお宅のガスメータの点検等の作業依頼である。なお、ガス利用者ＥＵとの応対と、保守員Ｈとの応対とは、別の人によって行われる場合もある。その場合、それらの人の間で連携が行われる。
【0068】
オペレータＯＰは、上記問合せ等の案件毎に、保守員Ｈに対する作業依頼を、電話やメール等を利用して行う。保守員Ｈは、自分の端末６０で電話やメールで作業依頼を受けて、指定された需要家のガスメータの点検等の作業を行い、作業完了報告をオペレータＯＰに対し電話やメール等で行う。オペレータＯＰは、例えば、地域の複数の保守員のうち候補となる保守員Ｈとの間で、スケジュール確認や調整、作業依頼、確定、作業完了報告等の取りまとめを行う。このような作業は、業務上、複数の人に対し複数回繰り返し行われる。そのため、従来、オペレータＯＰや保守員Ｈ等の人の作業負荷等が大きい。また、場合によっては、顧客からの問合せに対し迅速には対応できない可能性もある。
【0069】
一方、図７の下部には、上記ガス事業者のコールセンタ業務について、事業者システム１および外部システム３の外部サービス等を適用して効率化を図る場合の例として、実施の形態２のコンピュータシステムの構成概要を示す。ここでは、特に、オペレータＯＰと複数の保守員Ｈとの間での作業依頼と作業完了報告とのやり取りの部分について示す。この部分の途中に、事業者システム１が介在する。予め、顧客、事業者、および外部事業者との間で契約・設定が済んでいる。
【0070】
顧客システム２のオペレータＯＰは、保守員Ｈの端末６０に対し、作業依頼等を通知する。この際、クライアント端末２０は、オペレータＯＰの操作に基づいて、事業者システム１のサーバ１０にアクセスする。サーバ１０は、アクセスを受けると、ＷｅｂＡＰＩによって、顧客毎の設定に基づいて、外部システム３の外部サービスにアクセスする。オペレータＯＰから保守員Ｈへの作業依頼等は、この外部サービス上で実現される。本例では、この外部サービスは、スマートフォン上でのＳＮＳ・チャットサービスである。すなわち、作業依頼等は、ＳＮＳ・チャットサービス上でのメッセージ等のやり取りとして実現される。なお、保守員Ｈの端末６０には、そのＳＮＳ・チャットサービスを受けるためのアプリがインストールされる。ＳＮＳ・チャットサービス上でのユーザグループとして、オペレータＯＰと一人以上の保守員Ｈとがグループとして設定される。地域等に応じて複数のグループが設定可能である。
【0071】
サーバ３０のＷｅｂＡＰＩは、サーバ１０のＷｅｂＡＰＩからのアクセスを受けると、そのアクセスに応じた例えば作業依頼を、外部サービスであるＳＮＳ・チャットサービス上で、指定された保守員Ｈの端末６０に対しチャットのメッセージとして送信する。保守員Ｈは、端末６０の画面でその作業依頼を確認し、指定された需要家のガスメータの確認等の作業を実施する。その後、保守員Ｈは、端末６０の画面で、該当する主題（対応するタイムライン等）における作業依頼のメッセージに対し、作業完了報告のメッセージを返信する。保守員Ｈの端末６０からの返信のメッセージは、外部システム３のサーバ３０のＷｅｂＡＰＩに送信される。サーバ３０のＷｅｂＡＰＩは、その返信に対応する応答を、サーバ１０のＷｅｂＡＰＩへ送信する。サーバ１０のＷｅｂＡＰＩは、その応答のデータ（例えば作業完了報告）をＤＢに格納する。クライアント端末２０は、サーバ１０への確認の問合せに応じて、サーバ１０からその応答のデータを取得する。オペレータＯＰは、クライアント端末２０の画面で、その応答のデータとして例えば作業完了報告を確認できる。上記構成によって、コールセンタ業務におけるオペレータＯＰや保守員Ｈの作業負荷を低減できる。
【0072】
［２－２．コールセンタ業務－比較例］
図８は、実施の形態２に対する比較例を示す。この比較例は、図７のコールセンタ業務について、従来技術での実装構成例として、顧客システム２と外部事業者の外部システム３とを有し、事業者システムを介在しない場合を示す。また、この比較例では、外部サービスの例としてのＳＮＳ・チャットサービスの利用に関して、前述の図１５の（Ｃ）の第３ＡＰＩ接続方式としてコールバック方式を適用する場合を示す。図８の外部システム３のサーバ３０のＷｅｂＡＰＩは、コールバック方式を適用している。
図８は、実施の形態２に対する比較例を示す。この比較例は、図７のコールセンタ業務について、従来技術での実装構成例として、顧客システム２と外部事業者の外部システム３とを有し、事業者システムを介在しない場合を示す。また、この比較例では、外部サービスの例としてのＳＮＳ・チャットサービスの利用に関して、前述の図１５の（Ｃ）の第３ＡＰＩ接続方式としてコールバック方式を適用する場合を示す。図８の外部システム３のサーバ３０のＷｅｂＡＰＩは、コールバック方式を適用している。
【0073】
顧客システム２は、業務処理上、例えばオペレータＯＰからの作業依頼に対し、保守員Ｈからの作業完了報告等のデータを戻すことが必要である。そのため、顧客システム２のクライアント端末２０は、外部システム３のサーバ３０の外部サービス（対応するＷｅｂＡＰＩ）からのコールバックを受けることが可能な実装が必要である。そのために、クライアント端末２０は、外部公開部分８１０として、外部のインターネットに対し固定ＩＰアドレスをコールバック先として外部公開する。また、クライアント端末２０は、外部サービスからのコールバックを受け取ることができるＷｅｂＡＰＩ８２０を設ける。
【0074】
クライアント端末２０のＷｅｂＡＰＩ８２０は、外部サービスのＷｅｂＡＰＩ８３０に対し、ステップ８０１で、ＨＴＴＰＳ要求および応答によって、作業依頼（言い換えるとデータ取得要求）等の情報を送信する。外部サービスのＷｅｂＡＰＩ８３０は、その要求を受けて、ステップ８０２で、保守員Ｈの端末６０に対し、ＳＮＳ・チャットサービス上でのプッシュ通知によって、作業依頼等のメッセージを送信する。保守員Ｈの端末６０からは、ステップ８０３で、外部サービスのＷｅｂＡＰＩ８３０へ、作業完了報告等のメッセージを送信する。外部サービスのＷｅｂＡＰＩ８３０は、そのような応答を受けると、ステップ８０４で、顧客システム２のクライアント端末２０へ、ＨＴＴＰＳ要求および応答によって、コールバックとして、作業完了報告等のデータを送信する。
【0075】
このような比較例の構成は、前述のように、顧客システム２での外部公開等を要するので、セキュリティリスクが高く、保守運用コスト等が高い。顧客システム２は、利用する外部サービスを変更する場合や、外部サービスのＷｅｂＡＰＩの仕様変更がある場合には、それに合わせて実装や改修、例えばクライアント端末２０のＷｅｂＡＰＩの変更等が必要である。
【0076】
［２－３．コンピュータシステム－実装例］
図９は、実施の形態２のコンピュータシステムを含む、システム１００の構成を示す。この実施の形態２のコンピュータシステムの構成は、図７のコールセンタ業務について、顧客システム２と外部システム３との間に事業者システム１を介在する実装構成例を示す。顧客システム２のクライアント端末２０は、図８の比較例のようなＷｅｂＡＰＩ８２０の実装や、固定ＩＰアドレスの外部公開は不要である。
図９は、実施の形態２のコンピュータシステムを含む、システム１００の構成を示す。この実施の形態２のコンピュータシステムの構成は、図７のコールセンタ業務について、顧客システム２と外部システム３との間に事業者システム１を介在する実装構成例を示す。顧客システム２のクライアント端末２０は、図８の比較例のようなＷｅｂＡＰＩ８２０の実装や、固定ＩＰアドレスの外部公開は不要である。
【0077】
顧客システム２では、業務処理上、オペレータＯＰからの作業依頼に対し、保守員Ｈからの作業完了報告を取得する。オペレータＯＰは、クライアント端末２０の画面で、作業依頼等の情報を入力する。ステップ９０１で、クライアント端末２０は、オペレータＯＰの操作に基づいて、専用ツール２１を通じて、事業者システム１のサーバ１０にアクセスし、作業依頼に対応するデータ取得要求を行う。この顧客システム２と事業者システム１との間のアクセスは、基本的にＨＴＴＰＳ要求・応答として可能であり、詳しくは後述する安全な通信の仕組みで実現される。
【0078】
サーバ１０のＷｅｂＡＰＩ１２０は、図２のＷｅｂサーバ１１等の構成で、クライアント端末２０からのアクセスを受けて処理を行う。ステップ９０２で、サーバ１０のＷｅｂＡＰＩ１２０は、サーバ３０の外部サービスのＷｅｂＡＰＩとの間で、設定情報に基づいて、コールバック方式での通信を行う。サーバ１０のＷｅｂＡＰＩ１２０は、外部サービスのＷｅｂＡＰＩに対し、ＨＴＴＰＳ要求・応答によって、作業依頼等のための外部サービスの呼び出しを行う。外部サービスは、ＳＮＳ・チャットサービスである。外部サービスのＷｅｂＡＰＩは、その呼び出しを受けると、ステップ９０３で、指定された保守員Ｈの端末６０へ、ＳＮＳ・チャットサービス上のプッシュ通知によって、作業依頼のメッセージを送信する。保守員Ｈは、端末６０の画面で、そのプッシュ通知の作業依頼等のメッセージを確認し、作業を実施する。その後、保守員Ｈは、端末６０の画面で、チャットサービス上の作業依頼のメッセージに対する返信として作業完了報告を入力する。ステップ９０４で、保守員Ｈの端末６０は、作業完了報告のメッセージを、サーバ３０の外部サービスのＷｅｂＡＰＩへ送信する。外部サービスのＷｅｂＡＰＩは、その返信を受けると、ステップ９０２の呼び出しに対するコールバックとして、ステップ９０５で、サーバ１０のＷｅｂＡＰＩ１２０へ、作業完了報告のデータを、ＨＴＴＰＳ要求・応答によって送信する。
【0079】
サーバ１０のＷｅｂＡＰＩ１２０は、サーバ３０からのコールバックを受けると、作業完了報告のデータをＤＢ（図２のＤＢ１３０）に格納する。
【0080】
一方、ステップ９０６で、顧客システム２のクライアント端末２０は、ステップ９０１のデータ取得要求に関して、サーバ１０への問合せを、ＨＴＴＰＳ要求および応答によって行う。サーバ１０のＷｅｂＡＰＩ１２０は、問合せに対し、ＤＢを調べ、作業完了報告のデータがある場合には、読み出して、ＨＴＴＰＳ応答によってクライアント端末２０へ送信する。これにより、クライアント端末２０は、作業完了報告のデータを取得し、オペレータＯＰは画面で作業完了報告を確認できる。
【0081】
上記のように、実施の形態２の構成では、外部サービスへのＡＰＩ接続、例えば外部サービスの呼び出しおよびコールバック受信の処理を、事業者システム１が担う。これにより、顧客システム２のセキュリティリスクおよび保守運用コスト等が低減される。この効果は、顧客システム２が利用する外部サービスが変更される場合や、多数に増える場合、より大きくなる。
【0082】
［２－４．安全な通信の仕組み］
図１０および図１１は、図９の実施の形態２のコンピュータシステムにおける、安全な通信の仕組みについての説明図であり、図１０は第１説明図、図１１は第２説明図を示す。図９の顧客システム２のクライアント端末２０には、事業者システム１のサーバ１０と安全に通信するための機能を有する専用ツール２１が配置・起動される。これにより、顧客システム２のクライアント端末２０は、固定ＩＰアドレスの外部公開が不要であり、基本的なインターネット接続機能のみで、事業者システム１に対し安全に通信して、外部サービスを利用できる。専用ツール２１は、言い換えると、顧客システム２での業務処理を支援するためのアプリケーションプログラム等であり、事業者システム１を通じて外部サービスを利用する機能に係わるプログラムである。クライアント端末２０は、この通信上で、例えば図９のようにコールバック方式に基づいて作業完了報告等のデータを安全に取得することができる。この通信の仕組みでは、特に、クライアント端末２０からサーバ１０（図２のＷｅｂサーバ１１）に対し、定期的に、データ有無を問い合わせる。この問合せの定期のタイミングは、例えば顧客毎の設定において時間間隔等を指定可能である。
図１０および図１１は、図９の実施の形態２のコンピュータシステムにおける、安全な通信の仕組みについての説明図であり、図１０は第１説明図、図１１は第２説明図を示す。図９の顧客システム２のクライアント端末２０には、事業者システム１のサーバ１０と安全に通信するための機能を有する専用ツール２１が配置・起動される。これにより、顧客システム２のクライアント端末２０は、固定ＩＰアドレスの外部公開が不要であり、基本的なインターネット接続機能のみで、事業者システム１に対し安全に通信して、外部サービスを利用できる。専用ツール２１は、言い換えると、顧客システム２での業務処理を支援するためのアプリケーションプログラム等であり、事業者システム１を通じて外部サービスを利用する機能に係わるプログラムである。クライアント端末２０は、この通信上で、例えば図９のようにコールバック方式に基づいて作業完了報告等のデータを安全に取得することができる。この通信の仕組みでは、特に、クライアント端末２０からサーバ１０（図２のＷｅｂサーバ１１）に対し、定期的に、データ有無を問い合わせる。この問合せの定期のタイミングは、例えば顧客毎の設定において時間間隔等を指定可能である。
【0083】
図１０および図１１の例は、図９のステップ９０４からステップ９０６までのシーケンスに相当し、保守員Ｈの端末６０からの作業完了報告のデータを、外部システム３のサーバ３０のＷｅｂＡＰＩ、および事業者システム１のサーバ１０のＷｅｂＡＰＩ１２０を介して、顧客システム２のクライアント端末２０へ応答し取得する部分を示す。なお、図９のステップ９０１からステップ９０３までのシーケンス、すなわち顧客システム２のクライアント端末２０から事業者システム１および外部サービスを介して保守員Ｈの端末６０へ作業依頼を行う部分については、基本的に顧客システム２から事業者システム１に対しＨＴＴＰＳでアクセスするだけで済むので、顧客システム２側の通信のリスクは小さい。そのため、このシーケンス部分の詳細説明を省略する。
【0084】
図１０は、保守員Ｈの端末６０から事業者システム１のサーバ１０までの応答の部分を示し、主にステップ１００１～１００４を有する。図１１は、続いて、事業者システム１のサーバ１０から顧客システム２のクライアント端末２０までの応答の部分を示し、ステップ１１０１～１１０５を有する。以下、図１０および図１１で、保守員Ｈの端末６０から顧客システム２のオペレータＯＰのクライアント端末２０へ作業完了報告を応答する際の通信等を説明する。
【0085】
ステップ１００１（図１０）： 作業者である保守員Ｈは、端末６０の画面において、ＳＮＳ・チャットサービス上での作業依頼のメッセージを確認する。作業依頼は、ＳＮＳ・チャットサービス上で、ある作業依頼に対応する主題のタイムライン上の一部として表示されている。保守員Ｈは、作業依頼に従って、指定された需要家のガスメータの点検等の作業を行う。保守員Ｈは、作業完了後、端末６０の画面で、該当の主題の作業依頼のメッセージに対し、ＧＵＩ上の「作業完了」ボタンを押すことで返信を行う。
【0086】
ステップ１００２： 保守員Ｈの端末６０は「作業完了」ボタン押下を契機として、ユーザーコード(userCode)と担当者コード(workerCode)を判別し、外部システム３（サーバ３０）に予め設定しておいたコールバック先ＷｅｂＡＰＩを呼び出す。設定されたコールバック先ＷｅｂＡＰＩとは、事業者システム１のサーバ１０のＷｅｂＡＰＩ１２０へのＩＰアドレスであり、具体的にはＷｅｂサーバ１１の外部公開部分１０２のＩＰアドレスである。この呼び出し（対応するＰＯＳＴ）の具体例は以下である。https://api.example.jp/api/2005/sns/Work{"userCode": "0001", "workerCode": "789", "time": "202005220833", "kubun": "1" }。
【0087】
ステップ１００３： 事業者システム１内で、まずＷｅｂサーバ１１は、そのコールバックを受信する。Ｗｅｂサーバ１１のリバースプロキシ１１０は、そのコールバックに対応する要求を、ＡＰサーバ１２のＷｅｂＡＰＩ１２０へ転送する。なお、ここではファイアウォールサーバ等の経由の詳細は省略する。
【0088】
ステップ１００４： ＡＰサーバ１２のＷｅｂＡＰＩ１２０は、その要求を受け、その要求に伴う作業完了報告のデータを受け取り、その作業完了報告のデータを、ＤＢサーバ１３にコールバックデータとして格納する。図１０中には、ＤＢ１３０に格納されるデータ例として表も示している。この表は、データ項目として、ユーザーコード、担当者コード、時間、完了区分、および取得済を有する。例えば、表の３行目にそのデータが格納されている。「取得済」項目は、取得済フラグとして、作業依頼に対する作業完了報告を顧客システム２のクライアント端末２０が未取得である場合には値０、取得済みである場合には値１が格納される。
【0089】
ステップ１１０１（図１１）： 次に、顧客システム２のクライアント端末２０は、専用ツール２１を通じて、定期的に、すなわち指定された時間間隔で、インターネット経由で、事業者システム１に対し、データ有無等の問合せを行う。時間間隔は、顧客の業務の特性等に合わせて、例えば、１分、１０分、６０分等と設定可能である。このステップでは、具体的に、クライアント端末２０は、サーバ１０のＷｅｂＡＰＩ１２０を、ＨＴＴＰＳプロトコルのＧＥＴメソッドを用いて呼び出す。この呼び出しの具体例は以下である。https://api.example.jp/api/2005/sns/Work?uc=0001&timefr=202005220830&timeto=202005220835&flag=0。本例では、この呼び出しは、パラメータとして、ユーザコードが「0001」、時間が「2020/5/22の8:30～8:35」、取得済フラグが「0」を持つ取得要求となる。
【0090】
ステップ１１０２： 事業者システム１で、まずＷｅｂサーバ１１は、上記問合せに対応する取得要求を受けると、対応する取得要求をＡＰサーバ１２のＷｅｂＡＰＩ１２０へ転送する。
【0091】
ステップ１１０３： ＡＰサーバ１２のＷｅｂＡＰＩ１２０は、その取得要求に応じて、ＤＢサーバ１３のＤＢ１３０を検索し、該当する作業完了報告のデータを読み出す。言い換えると、ＡＰサーバ１２のＷｅｂＡＰＩ１２０は、ＤＢ１３０から、先にコールバックデータとして格納されている作業完了報告のデータを読み出す。本例では、この取得要求の条件を満たすデータとしては、図１０の表の２行目および３行目のデータが該当する。すなわち、顧客システム２は、定期的なタイミング毎に、該当データをまとめて取得可能である。ＡＰサーバ１２のＷｅｂＡＰＩ１２０は、ＤＢ１３０から読み出した該当データ（２行目および３行目）を含んだ、作業完了報告のデータを作成する。このデータは、例えばＪＳＯＮ（JavaScript Object Notation）形式で作成される。ＪＳＯＮは、各種プログラム言語で利用できる、テキストベースのデータ形式であり、JavaScript内でオブジェクトが記述される。また、ＷｅｂＡＰＩ１２０は、要求されているデータがＤＢ１３０内に無い場合には、空白データを応答として作成する。
【0092】
ステップ１１０４： ＡＰサーバ１２のＷｅｂＡＰＩ１２０は、上記作成した応答のデータをＷｅｂサーバ１１に渡す。
【0093】
ステップ１１０５： Ｗｅｂサーバ１１は、上記ＧＥＴメソッドでの取得要求に対するＨＴＴＰＳ応答として、上記作業完了報告のデータまたは空白データを含んだＨＴＴＰＳ応答を、クライアント端末２０に送信する。このＨＴＴＰＳ応答のステータスコードは、取得要求が成功の場合には、「200 OK」となる。
【0094】
このＨＴＴＰＳ応答のメッセージ本文に含まれる作業完了報告のデータ（ＪＳＯＮ形式）の具体例は以下である。要求されたデータが有る場合の例は、{ "workerCode": "456", "time": "202005220830", "kubun": "1" }, { "workerCode": "789", "time": "202005220833", "kubun": "1" }である。この場合、ＡＰサーバ１２のＷｅｂＡＰＩ１２０は、これらのデータが取得済みとなったので、図１０の表の２行目および３行目の取得済フラグを値１に更新する。要求されたデータが無い場合、すなわち空白データを返す場合の例は、{ "workerCode": "", "time": "", "kubun": "" }である。
【0095】
上記のような安全な通信の仕組みを通じて、顧客システム２のクライアント端末２０は、事業者システム１を介して、保守員Ｈの端末６０からの作業完了報告等のデータを取得できる。特に、上記例では、顧客システム２は、コールバック方式でのデータを安全に取得することができる。上記では、事業者システム１を介して取得するデータや情報、および業務処理上の機能の例として、作業依頼と作業完了報告の場合を説明したが、これに限らず同様に適用可能である。
【0096】
［２－５．効果等］
上記のように、実施の形態２によれば、特に顧客システム２のコールセンタ業務に関して、実施の形態１の効果を実現できる。顧客システム２は、設備をインターネットに外部公開する必要無く、事業者のクラウドへの接続のみで、安全かつ容易に外部サービスを利用できる。顧客は、外部サービスの利用によって、コールセンタ業務を含む業務の効率や品質を高めることができる。例えばガス事業者は、多数の需要家およびガスメータに係わる点検等の業務に関して、複数の作業依頼および作業完了報告等のやり取りを、ＳＮＳ・チャットサービス上で効率的に実現できる。
上記のように、実施の形態２によれば、特に顧客システム２のコールセンタ業務に関して、実施の形態１の効果を実現できる。顧客システム２は、設備をインターネットに外部公開する必要無く、事業者のクラウドへの接続のみで、安全かつ容易に外部サービスを利用できる。顧客は、外部サービスの利用によって、コールセンタ業務を含む業務の効率や品質を高めることができる。例えばガス事業者は、多数の需要家およびガスメータに係わる点検等の業務に関して、複数の作業依頼および作業完了報告等のやり取りを、ＳＮＳ・チャットサービス上で効率的に実現できる。
【0097】
外部サービスの１つとしてＳＮＳ・チャットサービスを適用する場合の効果としては以下がある。従来の業務では、オペレータＯＰが複数の保守員の各人に対し、個別に電話等で連絡し、作業依頼等をやり取りする必要があり煩雑である。この業務をＳＮＳ・チャットサービス上で実現することで、オペレータＯＰと各保守員との間で、作業依頼等の主題毎に、双方向コミュニケーションとしてのメッセージ等のやり取りが、時系列上での履歴として可視化および記録される。例えば、オペレータＯＰがクライアント端末２０から作業依頼のメッセージを第１保守員の端末に送付し、第１保守員がそれに対し返信（例えば確認や質問等）し、オペレータＯＰがそれに対しさらに返信し、第１保守員がそれに対し作業完了報告等を返信する。このように、ユーザ間のやり取りを少ない手間で明確にできるので、コールセンタ業務を効率化できる。
【0098】
＜実施の形態３＞
図１２～図１４等を用いて、本発明の実施の形態３のコンピュータシステム等について説明する。実施の形態３では、顧客システムと顧客システムが利用する外部事業者の外部サービスの他の具体例、およびその具体例に対応した事業者システム１の実装例を示す。実施の形態３では、顧客としてＬＰガス事業者であり、ＬＰガス事業者の業務として、外部事業者であるガスメータ事業者のガスメータサービスを用いたガスメータ業務を含む場合の例を示し、ガスメータ業務効率向上を実現する。ガスメータサービスは、例えば自動検針を含む。あるガス事業者の業務は、提携するあるガスメータ事業者のガスメータサービスを利用して行われる。
図１２～図１４等を用いて、本発明の実施の形態３のコンピュータシステム等について説明する。実施の形態３では、顧客システムと顧客システムが利用する外部事業者の外部サービスの他の具体例、およびその具体例に対応した事業者システム１の実装例を示す。実施の形態３では、顧客としてＬＰガス事業者であり、ＬＰガス事業者の業務として、外部事業者であるガスメータ事業者のガスメータサービスを用いたガスメータ業務を含む場合の例を示し、ガスメータ業務効率向上を実現する。ガスメータサービスは、例えば自動検針を含む。あるガス事業者の業務は、提携するあるガスメータ事業者のガスメータサービスを利用して行われる。
【0099】
［３－１．ガスメータ業務］
図１２は、実施の形態３に関して、前提となるガスメータ業務の構成例を示す。本例では、システムは、事業者に対する顧客であるガス事業者Ａおよびガス事業者Ｂと、外部事業者であるガスメータ事業者としてガスメータ事業者Ａおよびガスメータ事業者Ｂとを有する。ガス事業者Ａは顧客システムＡを有し、ガス事業者Ｂは顧客システムＢを有する。ガスメータ事業者Ａは、外部システムＡのサーバ３０Ａを有し、ガスメータ事業者Ｂは、外部システムＢのサーバ３０Ｂを有する。サーバ３０Ａは、ＷｅｂＡＰＩを用いてガスメータサービスＡを提供し、サーバ３０Ｂは、ＷｅｂＡＰＩを用いてガスメータサービスＢを提供する。ガスメータ事業者の外部システム３は、クラウドコンピューティングシステムである場合がある。例えばガスメータ事業者Ａの外部システム３Ａは、自社専用のクラウドコンピューティングシステムである。ガス事業者の顧客システム２と、ガスメータ事業者の外部システム３とは、広域網を介して接続される。
図１２は、実施の形態３に関して、前提となるガスメータ業務の構成例を示す。本例では、システムは、事業者に対する顧客であるガス事業者Ａおよびガス事業者Ｂと、外部事業者であるガスメータ事業者としてガスメータ事業者Ａおよびガスメータ事業者Ｂとを有する。ガス事業者Ａは顧客システムＡを有し、ガス事業者Ｂは顧客システムＢを有する。ガスメータ事業者Ａは、外部システムＡのサーバ３０Ａを有し、ガスメータ事業者Ｂは、外部システムＢのサーバ３０Ｂを有する。サーバ３０Ａは、ＷｅｂＡＰＩを用いてガスメータサービスＡを提供し、サーバ３０Ｂは、ＷｅｂＡＰＩを用いてガスメータサービスＢを提供する。ガスメータ事業者の外部システム３は、クラウドコンピューティングシステムである場合がある。例えばガスメータ事業者Ａの外部システム３Ａは、自社専用のクラウドコンピューティングシステムである。ガス事業者の顧客システム２と、ガスメータ事業者の外部システム３とは、広域網を介して接続される。
【0100】
例えば、ガス事業者Ａは、ガスメータ事業者ＡおよびＢと提携しており、ガス事業者Ｂは、ガスメータ事業者Ｂおよび他のガスメータ事業者と提携している。各ガス事業者の顧客システム２である基幹システムは、提携するガスメータ事業者の外部システム３のサーバ３０にアクセスし、ガスメータサービスに係わるデータを取得する。例えば、顧客システムＡは、外部システムＡのサーバ３０ＡからガスメータサービスＡに係わるデータを取得し、外部システムＢのサーバ３０ＢからガスメータサービスＢに係わるデータを取得する。
【0101】
各ガスメータ事業者は、対応する複数の需要家のガス利用者ＥＵに対しガスメータ７０を提供している。例えば、ガスメータ事業者Ａは、ガス利用者ＥＵ１のガスメータＡ１やガス利用者ＥＵ２のガスメータＡ２等を管轄している。サーバ３０ＡのガスメータサービスＡは、ガスメータＡ１，Ａ２等と通信して自動検針や状態監視を行い、検針データを作成し、ガス事業者に提供する機能に対応する外部サービスである。例えば、サーバ３０Ａは、通信インタフェースとしてＬＰＷＡでガスメータ７０（Ａ１，Ａ２等）と通信し、検針データを取得し、ＤＢに格納する。自動検針は、言い換えると遠隔検針である。ガスメータサービスの機能の他の例としては、遠隔開閉栓がある。
【0102】
例えば、ガス事業者Ａの顧客システム２Ａのクライアント端末２０Ａは、外部システム３Ａのサーバ３０Ａにアクセスし、ガスメータサービスに係わるデータとして、検針データを取得し、ＬＡＮのＤＢに格納する。検針データは、例えばＣＳＶ形式のデータである。顧客システム２は、対象の外部システム３のサーバ３０との接続の際には、サーバ３０のＡＰＩ接続方式に応じた接続が必要である。そのため、前述と同様の課題がある。
【0103】
需要家の住宅等にはガスメータ７０が設置されている。ガスメータ７０は、ガス器具に供給されるガスの量を計測する機能を少なくとも備える。ガスメータ７０は、例えばマイコン、圧力センサ、振動センサ、ガス漏れセンサ、遮断弁等を備える。ガスメータ７０は、ガス使用状態を監視し、ガスの流量や圧力等を把握する。ガスメータ７０は、異常を検知した場合、ガスの一時停止・遮断、アラート出力等を行う。ガス事業者の保守員Ｈは、ガスメータ７０の点検・保守等の作業を行う。
【0104】
ガスメータ７０は、スマートメータ（ＬＰガススマートメータ）であってもよい。ガスメータ７０は、スマートメータである場合、例えばガスメータ事業者のサーバ３０と通信する。あるガスメータ事業者の外部システム３は、スマートメータであるガスメータ７０と通信し、遠隔での自動検針等を実現する。なお、需要家において、ガスメータ７０と通信接続される他の機器、例えばホームネットワーク機器や携帯端末等があってもよい。ガスメータ７０は、保守員Ｈの端末６０や専用機器と通信接続される機器であってもよい。
【0105】
ガスメータ７０は、ガス使用量を測定し、測定値を含むデータを得る。また、ガスメータ７０は、ガス使用量に限らず、ガス状態の監視や検知、制御等に係わるデータを得る。これらのデータを「検針データ」と総称する。スマートメータであるガスメータ７０は、検針データを、ＬＰＷＡでの通信で、外部システム３のサーバ３０へ自動的に送信する。サーバ３０は、その検針データを受信・取得し、ＤＢに格納する。
【0106】
ガスメータ７０との通信インタフェースとしては、ＬＰＷＡ（Low Power Wide Area）またはＬＰＷＡＮという通信方式がある。ＬＰＷＡは、低消費電力で長距離データ通信を実現する方式であり、ＩｏＴの要素として注目されている。
【0107】
ガス事業者（またはガスメータ事業者）は、取得した検針データに基づいて、業務として、各需要家のガス使用状態を把握し、各ガス利用者に対するガス使用量の通知やガス料金請求を行う。ガス料金請求は、外部サービスとして決済代行サービスを用いて行われる場合もある。また、ガス事業者（またはガスメータ事業者）は、実施の形態２の例のように、各需要家のガス使用状態に応じて、保守員Ｈに対し、ガスメータ７０の点検・保守等の作業を依頼する。
【0108】
なお、ガス事業者またはガスメータ事業者は、ガス利用者ＥＵのスマートフォン等の端末４０に対し、ガスメータ７０に係わる機能を提供してもよい。例えば、ガス利用者が自分の端末４０からインターネットにアクセスし、自分のガス使用量や料金、ガス状態等を確認できる機能が挙げられる。
【0109】
ガスメータ事業者毎に、ガスメータ７０の仕様が異なり、外部システム３のガスメータサービスの仕様が異なる。ガスメータ７０の基本的な機能や仕様は業界団体によって統一されているが、詳細はメーカによって異なる。各ガスメータサービスは、ＡＰＩ接続方式が異なる場合がある。あるガス事業者が対象とするガスメータ７０は、１つのガスメータ事業者の１種類のガスメータに限定されることは稀であり、上記例のように、複数のガスメータ事業者の複数種類のガスメータの混在が一般的である。
【0110】
ガス事業者の顧客システム２は、複数のガスメータ事業者のガスメータサービスを利用する場合には、それらの仕様の違いに対応する必要がある。顧客システム２は、利用する各ガスメータサービスに応じた実装や、契約・設定等が必要である。
【0111】
［３－２．ガスメータ業務－比較例］
図１３は、実施の形態３に対する比較例として、図１２のガスメータ業務に関する実装例を示し、事業者システム１を介在しない場合を示す。図１３の比較例は、ガス事業者Ａの顧客システム２Ａと、ガスメータ事業者ＡのガスメータサービスＡを提供する外部システム３Ａと、ガス利用者ＥＵ１のガスメータ７０（Ａ１）との間で、自動検針に係わる通信を行う場合を示す。ガス利用者ＥＵ１のガスメータＡ１は、スマートメータであり、サーバ３０Ａと通信して自動検針等を行う機能を有する。
図１３は、実施の形態３に対する比較例として、図１２のガスメータ業務に関する実装例を示し、事業者システム１を介在しない場合を示す。図１３の比較例は、ガス事業者Ａの顧客システム２Ａと、ガスメータ事業者ＡのガスメータサービスＡを提供する外部システム３Ａと、ガス利用者ＥＵ１のガスメータ７０（Ａ１）との間で、自動検針に係わる通信を行う場合を示す。ガス利用者ＥＵ１のガスメータＡ１は、スマートメータであり、サーバ３０Ａと通信して自動検針等を行う機能を有する。
【0112】
サーバ３０ＡのＷｅｂＡＰＩは、ガスメータサービスＡを提供する。ガスメータサービスＡは、ガスメータ７０に関する自動検針や状態監視やアラーム通知等を行うサービスを含む。サーバ３０ＡのＷｅｂＡＰＩは、例えばガスメータＡ１に対し、ＬＰＷＡの通信で、ＬＰガス使用量に関する自動検針の検針値の要求を送信する（ステップ１３０１）。ガスメータＡ１は、その要求を受信すると、検針値の応答をサーバ３０Ａへ送信する（ステップ１３０２）。また、ガスメータＡは、定期的な状態確認を行う。その結果、ガスメータＡは、ガスメータＡの状態を表す情報を、サーバ３０Ａへ送信する。この状態を表す情報は、異常を検知した場合の警告である場合もある。ガスメータ７０の状態は、例えば、ＬＰガス残量警告、流量オーバー、微小漏洩等が挙げられる。
【0113】
サーバ３０ＡのＷｅｂＡＰＩは、ガスメータＡ１から、上記自動検針等に係わるデータ・情報を受信し、検針データとしてＤＢに格納し、ガスメータＡの状態を把握する。サーバ３０Ａは、ガスメータＡの状態に応じて、対処を行う。
【0114】
ガスメータ事業者Ａの外部システム３Ａは、例えば、需要家のガス利用者ＥＵの個人情報については保持していない。ガス利用者ＥＵの個人情報については、ガス事業者の顧客システム２がＤＢに保持し管理している。顧客システム２は、需要家のガス利用者ＥＵのガス使用量を把握してガス料金請求書を作成するために、ガスメータ事業者の外部システム３にアクセスして、検針データを取得する。
【0115】
クライアント端末２０は、オペレータＯＰの操作に基づいて、例えばガスメータ事業者Ａのサーバ３０Ａにアクセスし、ガス利用者ＥＵ１のガスメータＡ１等に関する検針データ（特に検針値）の要求を送信する（ステップ１３０３）。このアクセスは、ＡＰＩ接続方式に応じたＨＴＴＰＳ要求である。サーバ３０Ａは、要求に対し、ＤＢから要求されている検針データを読み出し、検針データの応答を作成してクライアント端末２０Ａに送信する（ステップ１３０４）。クライアント端末２０Ａは、受信・取得した検針データをＤＢに格納する。
【0116】
上記のアクセス（ステップ１３０３，１３０４）は、オペレータＯＰによる手動操作に基づいてインターネット経由で行われるため、作業の手間やコストが大きい。また、顧客システム２Ａは、利用する外部サービス（例えばガスメータサービスＡ，Ｂ）に応じたＡＰＩ接続のための実装等が必要である。
【0117】
また、ガスメータ事業者の外部システム３、またはガス事業者の顧客システム２からは、保守員Ｈの端末６０に対し、通知等が送信される場合がある。例えば、ガス利用者ＥＵ１のガスメータＡ１の状態監視の結果、警告等が検知されたとする。この場合、例えば、ガス事業者Ａの顧客システム２Ａは、オペレータＯＰの作業として、前述のコールセンタ業務と同様に、点検等の作業依頼を、電話やメールで保守員Ｈの端末６０へ送信する。また、例えば、ガスメータサービスＡは、保守員Ｈへのアラーム通知サービスを含む場合がある。外部システム３Ａのサーバ３０Ａは、ガスメータサービスＡによって、ガスメータＡ１から警告等の情報を受信した場合に、予め設定された保守員Ｈの端末６０へ、メールでアラーム通知１３１０を送信する。保守員Ｈの端末６０は、アラーム通知１３１０を受信し、画面に表示する。保守員Ｈ１は、画面でアラーム通知１３１０の内容を見て確認する。アラーム通知１３１０の例は図示の通りである。アラーム通知１３０１のメールは、送信元としてガスメータ事業者の「アラーム通知サービス」、送信日時、送信先としてガス事業者の保守員Ｈ、主題として「残量警告（残１５％）」、ＩＭＥＩ、発生時刻、他のメッセージ等が記載されている。
【0118】
本例では、このアラーム通知１３１０には、需要家のガス利用者ＥＵ１の個人情報（例えば名前や住所）の記載は無い。そのため、このアラーム通知１３１０のみでは、どの需要家のガスメータ７０に関するアラーム通知であるかが不明である。保守員ＨまたはオペレータＯＰは、作業のためには、どの需要家のガスメータ７０に関するアラーム通知であるかを確認する必要がある。このアラーム通知１３１０には、例えばＩＭＥＩ（International Mobile Equipment Identifier）で示す識別情報は記載されている。ＩＭＥＩは、携帯端末等が保有する識別番号である。保守員ＨまたはオペレータＯＰは、そのＩＭＥＩから、顧客システム２のＤＢ（特に需要家の個人情報）を検索する（ステップ１３２０）。これにより、保守員ＨまたはオペレータＯＰは、どの需要家（名前、住所等）のガスメータ７０に関するアラーム通知であるかを確認する。確認後、保守員Ｈは、指定された需要家のガス利用者ＥＵ１のガスメータＡ１に関する点検・保守等の作業を行い、作業完了報告をオペレータＯＰへ送信する。
【0119】
上記のように、比較例では、需要家の個人情報に配慮しているが、ガス事業者がガスメータ事業者のガスメータサービスのデータを利用する場合に、作業の手間やコストが大きい。例えば上記のようにＤＢを検索する作業（ステップ１３２０）を経ないと、アラーム通知１３１０に対応する需要家を特定できないので、その分作業効率が良くない。
【0120】
［３－３．コンピュータシステム－実装例］
図１４は、実施の形態３のコンピュータシステムを含む、システム１００の構成を示す。このコンピュータシステムは、図１２のガスメータ業務に関する実装構成例である。図１４の構成は、図１３の比較例の構成に対し、顧客システム２Ａとガスメータ事業者Ａの外部システム３Ａとの間に、事業者システム１が介在する。また、この構成では、外部サービスＸとしてＳＮＳ・チャットサービスを提供する外部事業者Ｘの外部システム３Ｘを有する。図１４の例では、顧客Ａであるガス事業者Ａの顧客システム２Ａと、外部事業者Ａであるガスメータ事業者Ａの外部システム３Ａと、外部事業者Ｘの外部システム３Ｘと、需要家のガス利用者ＥＵ１のガスメータＡ１とを示すが、これに限らず、複数が存在する。本例では、顧客システム２Ａは、外部サービスＡおよび外部サービスＸを利用する。
図１４は、実施の形態３のコンピュータシステムを含む、システム１００の構成を示す。このコンピュータシステムは、図１２のガスメータ業務に関する実装構成例である。図１４の構成は、図１３の比較例の構成に対し、顧客システム２Ａとガスメータ事業者Ａの外部システム３Ａとの間に、事業者システム１が介在する。また、この構成では、外部サービスＸとしてＳＮＳ・チャットサービスを提供する外部事業者Ｘの外部システム３Ｘを有する。図１４の例では、顧客Ａであるガス事業者Ａの顧客システム２Ａと、外部事業者Ａであるガスメータ事業者Ａの外部システム３Ａと、外部事業者Ｘの外部システム３Ｘと、需要家のガス利用者ＥＵ１のガスメータＡ１とを示すが、これに限らず、複数が存在する。本例では、顧客システム２Ａは、外部サービスＡおよび外部サービスＸを利用する。
【0121】
本実装例でも、比較例と同様に、ガスメータ事業者Ａは、ガスメータサービスＡとして、需要家のスマートメータであるガスメータ７０との間で自動検針等を行い、検針データをＤＢに格納する。ガスメータ事業者Ａは、需要家の個人情報を保持しておらず、顧客システム２ＡがＤＢに需要家の個人情報を保持している。ガスメータサービスＡは、比較例と同様に、自動検針、状態監視、アラーム通知等を含む。例えばアラーム通知には需要家の個人情報が含まれない。
【0122】
図１４の例では、ガス事業者Ａは、保守員Ｈへのアラーム通知および作業依頼の際に、外部サービスＸとしてＳＮＳ・チャットサービスを利用する。これにより、ガスメータ業務を効率化する。
【0123】
図１４中のステップ１４０１～１４０６のシーケンスは、顧客システム２Ａが、事業者システム１を介して、外部システム３ＡのガスメータサービスＡから、ガスメータ７０の自動検針や状態監視に係わるデータを取得する流れを示す。なお、予め事業者システム１に設定しておくことで、ステップ１４０１を省略可能である。このシーケンスは、前述と同様に、外部サービスＡとのＡＰＩ接続方式に応じた接続制御がされる。このシーケンスは、前述の図１０および図１１のような安全な通信の仕組みを同様に適用できる。
【0124】
ステップ１４０７は、顧客システム２Ａにおけるクライアント端末２０ＡとＤＢとの間でのデータの格納や読み出しである。ＤＢには、需要家の個人情報（名前や住所等）がセキュアに保持されている。例えば、クライアント端末２０Ａは、ステップ１４０６で、事業者システム１のサーバ１０を通じて、ガスメータサービスＡからの検針データまたはアラーム通知等のデータを受信・取得し、そのデータをＤＢに格納する。本例では、ガスメータサービスＡは、ガス利用者ＥＵ１のガスメータＡ１に関する警告等の検知に基づいて、個人情報を含まないアラーム通知を、顧客システム２Ａへ送信する（ステップ１４０６）。この場合、クライアント端末２０ＡのオペレータＯＰは、そのアラーム通知に含まれるＩＤ（例えば図１３と同様のＩＭＥＩ）等の情報を用いて、ＤＢを検索する（ステップ１４０７）。これにより、そのＩＤとＤＢ内の需要家の個人情報とをマッチングする。この結果、クライアント端末２０Ａは、そのアラーム通知に関して該当する需要家の情報（名前、住所等）や、対応する保守員Ｈの情報を得る。すなわち、オペレータＯＰが保守員Ｈへ需要家のガスメータ７０の点検・保守の作業を依頼するために必要な情報が得られる。このステップ１４０７の処理は、予めクライアント端末２０Ａでのプログラム処理として設定しておくことで、オペレータＯＰの操作を最低限として自動化することができる。
【0125】
ステップ１４０８で、クライアント端末２０Ａは、上記ＤＢから得た諸情報を用いて、需要家のガスメータ７０の状態に関するアラーム通知、ならびにオペレータＯＰから保守員Ｈへの作業依頼のための情報を作成する。具体的には、クライアント端末２０Ａは、その情報として、事業者システム１のサーバ１０のＷｅｂＡＰＩ１２０へのＨＴＴＰＳ要求を作成し、そのＨＴＴＰＳ要求をサーバ１０の外部公開部分へ宛てて送信する。このＨＴＴＰＳ要求は、ガス利用者の個人情報等を含むが、セキュア通信で保護される。
【0126】
ステップ１４０９で、事業者システム１のサーバ１０（詳細には図２のＷｅｂサーバ１１およびＡＰサーバ１２）のＷｅｂＡＰＩ１２０は、上記ＨＴＴＰＳ要求を受け取り、その要求の内容がアラーム通知および作業依頼であるため、設定情報に基づいて、外部システム３Ｘの外部サービスＸの利用のためのＨＴＴＰＳ要求を作成する。サーバ１０のＷｅｂＡＰＩ１２０は、そのＨＴＴＰＳ要求を、外部システム３Ｘのサーバ３０ＸのＷｅｂＡＰＩへ送信する。このＨＴＴＰＳ要求は、ガス利用者等の個人情報を含むが、セキュア通信で保護される。ステップ１４０９のアクセスについても、サーバ３０ＸとのＡＰＩ接続方式（例えばコールバック方式）に応じた接続制御が行われる。
【0127】
ステップ１４１０で、外部システム３Ｘのサーバ３０ＸのＷｅｂＡＰＩは、上記ＨＴＴＰＳ要求を受け取り、その要求の内容として含まれている情報に基づいて、指定された保守員Ｈの端末６０へのアラーム通知および作業依頼の情報を、ＳＮＳ・チャットサービス上のメッセージとして作成する。サーバ３０ＸのＷｅｂＡＰＩは、そのアラーム通知・作業依頼のメッセージを、保守員Ｈ１の端末６０へプッシュ通知として送信する。
【0128】
外部サービスＸのＳＮＳ・チャットサービスでの画面例は図示の通りである。ステップ１４１０のプッシュ通知の情報は、主題、発生時刻、お客様番号、住所、氏名、電話番号等を含む。このプッシュ通知の送信元は、例えば所定の「ｂｏｔ」（ＳＮＳ・チャットサービス上で自動的に働くアカウントを指す）とされる。主題は例えば「残量警告（残１５％）」である。お客様番号は、ガス事業者が管理している該当するガス利用者ＥＵ（ＥＵ１）の識別情報である。住所、氏名、電話番号は、そのガス利用者の個人情報である。
【0129】
ステップ１４１１で、保守員Ｈ１は、端末６０の画面で、ステップ１４１０のプッシュ通知の情報を確認し、このプッシュ通知に記載のアラーム通知・作業依頼の情報に従って、指定された需要家に訪問してガスメータ７０の点検・保守等の作業を行う。保守員Ｈ１は、作業後、端末６０の画面で、ステップ１４１０のプッシュ通知に対する返信として作業完了報告等を入力し、送信する。この際、端末６０は、図１０と同様に、ＨＴＴＰＳのＰＯＳＴメソッドを用いてデータを送信する。
【0130】
ステップ１４１２で、外部システム３Ｘのサーバ３０ＸのＷｅｂＡＰＩは、ＳＮＳ・チャットサービス上で、ステップ１４１１の保守員Ｈ１の端末６０からの作業完了報告の返信を受け取る。サーバ３０Ｘは、その作業完了報告のデータを含むＨＴＴＰＳ応答を、事業者システム１のサーバ１０へ例えばコールバックとして送信する。
【0131】
ステップ１４１３で、事業者システム１のサーバ１０は、上記外部サービス３ＸからのＨＴＴＰＳ応答をコールバックとして受け取る。サーバ１０は、図１０および図１１と同様の仕組みで、顧客システム２Ａのクライアント端末２０Ａへ、作業完了報告のデータを含むＨＴＴＰＳ応答を送信する。そして、クライアント端末２０Ａは、サーバ１０から問合せに応じて受け取った作業完了報告のデータをＤＢに格納する。オペレータＯＰは、クライアント端末２０Ａの画面で、作業完了報告等を確認できる。
【0132】
［３－４．効果等］
図１４の実施の形態３での実装例でも、実施の形態２と同様に、顧客システム２は、事業者システム１との間で、安全な通信の仕組みで、外部サービスを容易に利用することができる。特に、この実装例では、ガス事業者の顧客システム２は、種類が異なる外部サービスＡおよび外部サービスＸを、事業者システム１を介して統合的に利用できる。その結果、ガス事業者は、ガスメータ業務の効率化ができる。
図１４の実施の形態３での実装例でも、実施の形態２と同様に、顧客システム２は、事業者システム１との間で、安全な通信の仕組みで、外部サービスを容易に利用することができる。特に、この実装例では、ガス事業者の顧客システム２は、種類が異なる外部サービスＡおよび外部サービスＸを、事業者システム１を介して統合的に利用できる。その結果、ガス事業者は、ガスメータ業務の効率化ができる。
【0133】
上記例では、需要家のガスメータ７０からは不定的に警告等の状態を表す情報が発生・発報する。顧客システム２Ａは、外部のガスメータ事業者ＡのガスメータサービスＡからのアラーム通知を取得し、ＤＢの需要家の情報を自動的に検索して、保守員Ｈへのアラーム通知・作業依頼に必要な情報を得る。顧客システム２Ａは、その情報を、事業者システム１を介して外部システム３Ｘへ送信し、外部サービスＸとしてＳＮＳ・チャットサービス上でのアラーム通知・作業依頼として、保守員Ｈの端末６０へ通知できる。そして、顧客システム２Ａは、保守員Ｈからの作業完了報告を、外部サービスＸおよび事業者システム１を介して取得することができる。これにより、オペレータＯＰおよび保守員Ｈの手間等が低減できる。
【0134】
上記例では、ガス事業者に対する外部事業者として、ガスメータ事業者Ａと、ＳＮＳ・チャットサービスを提供する外部事業者Ｘとの、直接的には全く関連性が無い２種類の外部事業者を有する。事業者システム１は、これらの２種類の外部事業者のＷｅｂＡＰＩを伴う外部サービスを仲介し、つなぎ合わせて、顧客であるガス事業者に対し、統合的なサービスとして提供できる。これにより、ガス事業者は、業務に、複数の外部サービスをシームレスで統一感がある形で統合したサービスとして享受することができる。ガス事業者は、このような特有の形態での外部サービス利用を、前述と同様に、契約や設定の手間も少なく、低いコストで実現できる。
【0135】
顧客が利用する複数の外部サービスの組合せは、上記例に限らず、顧客の選択に応じて多様な組合せが可能である。例えば、顧客システム２Ａは、さらに、他の外部サービスとして決済代行サービスを組み合わせて利用してもよい。
【0136】
実施の形態３の例のように、顧客がガス事業者である場合で、１つの顧客システムからみて複数のガスメータ事業者の外部システム（例えばクラウドコンピューティングシステム）があり、ガスメータ事業者毎に外部サービス等の仕様が異なる場合がある。この場合にも、事業者システム１が介在し、それらの仕様の差異を吸収または低減し、顧客システム２に対し、インタフェースを共通化した形でサービスとして提供できる。例えば図１２の顧客システム２Ａは、外部システムＡの外部サービスＡと外部システムＢの外部サービスＢとからそれぞれ検針データを取得する場合に、実施の形態３では、事業者システム１を介して、それぞれの検針データを容易に取得できる。顧客システム２Ａは、それぞれの外部サービスに対するログインやＡＰＩ接続が不要である。したがって、顧客システム２Ａは、それらの検針データを統合してガス使用量通知等の業務を行う場合にも、効率化が実現できる。
【0137】
以上、本発明を実施の形態に基づいて具体的に説明したが、本発明は前述の実施の形態に限定されず、要旨を逸脱しない範囲で種々変更可能である。実施の形態では顧客の具体例としてガス事業者の場合を説明したが、これに限らず、例えば水道事業者や電気事業者等のインフラ事業者に関しても、同様に適用可能である。
【符号の説明】
【0138】
１…事業者システム（クラウドコンピューティングシステム／コンピュータシステム）、２…顧客システム（基幹システム）、３…外部事業者システム（外部システム）、４…、５…、６…、７…、８…、９…、１０…サーバ（クラウドサーバ）、１１…Ｗｅｂサーバ（第１サーバ）、１２…アプリケーションサーバ（第２サーバ）、１３…ＤＢサーバ（第３サーバ）、１４…管理サーバ、２０…クライアント端末、２１…専用ツール、２２…画面（契約設定確認画面）、３０…サーバ、１００…システム、１０１，１０２，３０１…外部公開部分、１２０…ＷｅｂＡＰＩ，１３０…ＤＢ、１４０…契約・設定管理機能、１４１…契約設定情報、１５０…管理端末、ＯＰ…オペレータ、ＡＤ…管理者。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】