(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2023163502
(43)【公開日】2023-11-10
(54)【発明の名称】情報共有システム、処理実行方法、及びプログラム
(51)【国際特許分類】
G06F 9/445 20180101AFI20231102BHJP
G06F 16/903 20190101ALI20231102BHJP
【ＦＩ】
G06F9/445
G06F16/903
【審査請求】未請求
【請求項の数】14
【出願形態】ＯＬ
(21)【出願番号】P 2022074452
(22)【出願日】2022-04-28
(71)【出願人】
【識別番号】500022557
【氏名又は名称】サイボウズ株式会社
(74)【代理人】
【識別番号】110000154
【氏名又は名称】弁理士法人はるか国際特許事務所
(72)【発明者】
【氏名】川畑 稔
(72)【発明者】
【氏名】川畑 裕也
(72)【発明者】
【氏名】杉山 祐一
(72)【発明者】
【氏名】二ノ宮 将吾
(72)【発明者】
【氏名】福西 隆宏
(72)【発明者】
【氏名】山田 高大
(72)【発明者】
【氏名】中島 薫
【テーマコード（参考）】
5B175
5B376
【Ｆターム（参考）】
5B175FB04
5B175HA01
5B175HA02
5B376AC11
5B376AE51
5B376AE67
5B376DA20
5B376FA15
(57)【要約】
【課題】情報共有サービスにおけるユーザの利便性を高める。
【解決手段】情報共有システム（１）は、情報を共有するための情報共有サービスに関する複数の機能を有する。利用状況取得部（１０２）は、機能ごとに、複数のユーザの各々による利用状況を取得する。処理実行部（１０３）は、機能ごとに、当該機能の利用状況に基づいて、当該機能に関する所定の処理を実行する。
【選択図】図３
【解決手段】情報共有システム（１）は、情報を共有するための情報共有サービスに関する複数の機能を有する。利用状況取得部（１０２）は、機能ごとに、複数のユーザの各々による利用状況を取得する。処理実行部（１０３）は、機能ごとに、当該機能の利用状況に基づいて、当該機能に関する所定の処理を実行する。
【選択図】図３
【特許請求の範囲】
【請求項1】
情報を共有するための情報共有サービスに関する複数の機能を有する情報共有システムであって、
前記機能ごとに、複数のユーザの各々による利用状況を取得する利用状況取得部と、
前記機能ごとに、当該機能の前記利用状況に基づいて、当該機能に関する所定の処理を実行する処理実行部と、
を含む情報共有システム。
前記機能ごとに、複数のユーザの各々による利用状況を取得する利用状況取得部と、
前記機能ごとに、当該機能の前記利用状況に基づいて、当該機能に関する所定の処理を実行する処理実行部と、
を含む情報共有システム。
【請求項2】
前記処理実行部は、前記所定の処理として、前記機能の前記利用状況をユーザ端末に表示させるための利用状況表示処理を実行する、
請求項１に記載の情報共有システム。
請求項１に記載の情報共有システム。
【請求項3】
前記処理実行部は、前記所定の処理として、前記複数の機能のうち、前記複数のユーザの各々による利用が第１の基準を満たす前記機能を停止するための機能停止処理を実行する、
請求項１又は２に記載の情報共有システム。
請求項１又は２に記載の情報共有システム。
【請求項4】
前記情報共有システムでは、前記機能ごとの契約が可能であり、
前記処理実行部は、前記所定の処理として、前記機能の前記利用状況に応じた前記契約をするための契約処理を実行する、
請求項１又は２に記載の情報共有システム。
前記処理実行部は、前記所定の処理として、前記機能の前記利用状況に応じた前記契約をするための契約処理を実行する、
請求項１又は２に記載の情報共有システム。
【請求項5】
前記利用状況取得部は、前記利用状況として、前記複数のユーザのうち、前記機能で提供される情報にアクセスした前記ユーザを識別可能なユーザ識別情報を取得し、
前記処理実行部は、前記機能の前記ユーザ識別情報に基づいて、前記所定の処理を実行する、
請求項１又は２に記載の情報共有システム。
前記処理実行部は、前記機能の前記ユーザ識別情報に基づいて、前記所定の処理を実行する、
請求項１又は２に記載の情報共有システム。
【請求項6】
前記処理実行部は、前記所定の処理として、前記機能で提供される複数の情報のうち、前記複数のユーザの各々による利用が第２の基準を満たす前記情報を表示するための情報表示処理を実行する、
請求項１又は２に記載の情報共有システム。
請求項１又は２に記載の情報共有システム。
【請求項7】
前記処理実行部は、前記所定の処理として、前記機能で提供される複数の情報のうち、前記複数のユーザの各々による利用が第３の基準を満たす前記情報に関する権限を変更するための権限変更処理を実行する、
請求項１又は２に記載の情報共有システム。
請求項１又は２に記載の情報共有システム。
【請求項8】
前記情報共有システムは、前記複数のユーザの各々により入力された検索条件に基づいて、前記複数の機能の各々で提供される情報を検索する検索部を更に含み、
前記処理実行部は、前記所定の処理として、前記複数の機能のうち、よく利用されている前記機能で提供される情報が検索でヒットしやすくなるためのヒット処理を実行する、
請求項１又は２に記載の情報共有システム。
前記処理実行部は、前記所定の処理として、前記複数の機能のうち、よく利用されている前記機能で提供される情報が検索でヒットしやすくなるためのヒット処理を実行する、
請求項１又は２に記載の情報共有システム。
【請求項9】
前記複数の機能の各々は、当該機能に関するＡＰＩを利用して、前記複数のユーザの各々に提供され、
前記利用状況取得部は、前記機能の前記利用状況を、当該機能の前記ＡＰＩを利用して取得する、
請求項１又は２に記載の情報共有システム。
前記利用状況取得部は、前記機能の前記利用状況を、当該機能の前記ＡＰＩを利用して取得する、
請求項１又は２に記載の情報共有システム。
【請求項10】
前記利用状況取得部は、前記機能の前記利用状況として、当該機能に対するアクセス数を取得し、
前記処理実行部は、前記機能の前記アクセス数に基づいて、前記所定の処理を実行する、
請求項１又は２に記載の情報共有システム。
前記処理実行部は、前記機能の前記アクセス数に基づいて、前記所定の処理を実行する、
請求項１又は２に記載の情報共有システム。
【請求項11】
前記利用状況取得部は、前記機能の前記利用状況として、当該機能に関する画面を表示させている表示時間を取得し、
前記処理実行部は、前記機能の前記表示時間に基づいて、前記所定の処理を実行する、
請求項１又は２に記載の情報共有システム。
前記処理実行部は、前記機能の前記表示時間に基づいて、前記所定の処理を実行する、
請求項１又は２に記載の情報共有システム。
【請求項12】
前記複数の機能の各々は、前記複数のユーザの何れかにより追加され、
前記利用状況取得部は、前記複数のユーザの何れかにより追加された前記機能の前記利用状況を取得し、
前記処理実行部は、前記複数のユーザの何れかにより追加された前記機能の前記利用状況に基づいて、前記所定の処理を実行する、
請求項１又は２に記載の情報共有システム。
前記利用状況取得部は、前記複数のユーザの何れかにより追加された前記機能の前記利用状況を取得し、
前記処理実行部は、前記複数のユーザの何れかにより追加された前記機能の前記利用状況に基づいて、前記所定の処理を実行する、
請求項１又は２に記載の情報共有システム。
【請求項13】
情報を共有するための情報共有サービスに関する複数の機能を有する情報共有システムにおける処理実行方法であって、
前記機能ごとに、複数のユーザの各々による利用状況を取得する利用状況取得ステップと、
前記機能ごとに、当該機能の前記利用状況に基づいて、当該機能に関する所定の処理を実行する処理実行ステップと、
を含む処理実行方法。
前記機能ごとに、複数のユーザの各々による利用状況を取得する利用状況取得ステップと、
前記機能ごとに、当該機能の前記利用状況に基づいて、当該機能に関する所定の処理を実行する処理実行ステップと、
を含む処理実行方法。
【請求項14】
情報を共有するための情報共有サービスに関する複数の機能を有する情報共有システムにおけるコンピュータを、
前記機能ごとに、複数のユーザの各々による利用状況を取得する利用状況取得部、
前記機能ごとに、当該機能の前記利用状況に基づいて、当該機能に関する所定の処理を実行する処理実行部、
として機能させるためのプログラム。
前記機能ごとに、複数のユーザの各々による利用状況を取得する利用状況取得部、
前記機能ごとに、当該機能の前記利用状況に基づいて、当該機能に関する所定の処理を実行する処理実行部、
として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、情報共有システム、処理実行方法、及びプログラムに関する。
【背景技術】
【0002】
従来、複数のユーザで情報を共有するための情報共有サービスが知られている。例えば、情報共有サービスでは、スケジュール共有機能、ファイル共有機能、データベース共有機能、又はコミュニケーション機能といった種々の機能が提供される。情報共有サービスで提供される機能ごとに、ユーザによる利用状況を取得することができれば、例えば機能の削除又は改修を検討しやすくなるので、ユーザの利便性が高まると考えられる。機能ごとの利用状況は、他の種々の目的でも活用できると考えられる。
【0003】
例えば、特許文献１には、ユーザ端末にインストールされたアプリの利用頻度又は利用時間帯といった利用状況を収集する技術が記載されている。例えば、特許文献２には、ユーザ端末にインストールされたアプリの利用状況として、アプリの起動時刻、終了時刻、又は起動場所といった情報を取得し、どのアプリが良く利用されているかを分析する技術が記載されている。
【先行技術文献】
【特許文献】
【0004】
【特許文献1】特開２０１２－１７４１７４号公報
【特許文献2】特開２０１３－２２８８２０号公報
【発明の概要】
【発明が解決しようとする課題】
【0005】
しかしながら、特許文献１及び特許文献２の技術は、１つのアプリが１つのサービスに相当するので、サービス全体の利用状況を収集するものにすぎない。特許文献１及び特許文献２には、ある１つのサービスで提供される機能ごとの利用状況を収集することは何ら記載されていない。このため、特許文献１及び特許文献２の技術を情報共有サービスに適用したとしても、情報共有サービス全体の利用状況を収集することはできても、情報共有サービスで提供される機能ごとの利用状況を収集することはできない。
【0006】
本開示の目的の１つは、情報共有サービスにおけるユーザの利便性を高めることである。
【課題を解決するための手段】
【0007】
本開示の一側面に係る情報共有システムは、情報を共有するための情報共有サービスに関する複数の機能を有する情報共有システムであって、前記機能ごとに、複数のユーザの各々による利用状況を取得する利用状況取得部と、前記機能ごとに、当該機能の前記利用状況に基づいて、当該機能に関する所定の処理を実行する処理実行部と、を含む。
【発明の効果】
【0008】
本開示によれば、情報共有サービスにおけるユーザの利便性が高まる。
【図面の簡単な説明】
【0009】
【図1】情報共有システムの全体構成の一例を示す図である。
【図2】ポータル画面の一例を示す図である。
【図3】情報共有システムで実現される機能ブロックを示す図である。
【図4】ユーザデータベースの一例を示す図である。
【図5】利用状況データベースの一例を示す図である。
【図6】利用状況画面の一例を示す図である。
【図7】情報共有システムで実行される処理の一例を示す図である。
【図8】変形例における機能ブロックを示す図である。
【図9】変形例２の利用状況画面の一例を示す図である。
【図10】アプリデータベースの一例を示す図である。
【図11】変形例４のポータル画面の一例を示す図である。
【発明を実施するための形態】
【0010】
［１．情報共有システムの全体構成］
本開示に係る情報共有システムの実施形態の一例を説明する。図１は、情報共有システムの全体構成の一例を示す図である。例えば、情報共有システム１は、サーバ１０及びユーザ端末２０を含む。サーバ１０及びユーザ端末２０の各々は、インターネット又はＬＡＮ等のネットワークＮに接続される。
本開示に係る情報共有システムの実施形態の一例を説明する。図１は、情報共有システムの全体構成の一例を示す図である。例えば、情報共有システム１は、サーバ１０及びユーザ端末２０を含む。サーバ１０及びユーザ端末２０の各々は、インターネット又はＬＡＮ等のネットワークＮに接続される。
【0011】
サーバ１０は、サーバコンピュータである。制御部１１は、少なくとも１つのプロセッサを含む。記憶部１２は、ＲＡＭ等の揮発性メモリと、フラッシュメモリ等の不揮発性メモリと、を含む。通信部１３は、有線通信用の通信インタフェースと、無線通信用の通信インタフェースと、の少なくとも一方を含む。
【0012】
ユーザ端末２０は、ユーザのコンピュータである。例えば、ユーザ端末２０は、パーソナルコンピュータ、タブレット端末、スマートフォン、又はウェアラブル端末である。制御部２１、記憶部２２、及び通信部２３の各々のハードウェア構成は、それぞれ制御部１１、記憶部１２、及び通信部１３と同様であってよい。操作部２４は、マウス、タッチパネル、又はキーボード等の入力デバイスである。表示部２５は、液晶ディスプレイ又は有機ＥＬディスプレイである。
【0013】
なお、記憶部１２，２２に記憶されるプログラムは、ネットワークＮを介して供給されてもよい。サーバ１０及びユーザ端末２０の各々のハードウェア構成は、図１の例に限られない。例えば、コンピュータ読み取り可能な情報記憶媒体を読み取る読取部（例えば、光ディスクドライブやメモリカードスロット）、又は、外部機器と直接的に接続するための入出力部（例えば、ＵＳＢ端子）が含まれてもよい。この場合、情報記憶媒体に記憶されたプログラムが読取部又は入出力部を介して供給されてもよい。
【0014】
また、情報共有システム１は、少なくとも１つのコンピュータを含めばよく、図１の例に限られない。例えば、実際には、多数のユーザが存在するので、多数のユーザ端末２０が情報共有システム１に含まれてもよい。例えば、ユーザ端末２０は、情報共有システム１の外部に存在してもよい。この場合、情報共有システム１は、ユーザ端末２０を含まずに、サーバ１０だけを含んでもよい。情報共有システム１は、サーバ１０と、ユーザ端末２０以外の他のコンピュータと、を含んでもよい。
【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】
例えば、アプリが追加されると、アプリに相当するデータが生成されてデータ記憶部１００に記録される。アプリに必要なプログラムも生成されてデータ記憶部１００に記録される。アプリの追加は、情報共有サービスにログインした状態で行われなくてもよく、ユーザは、ユーザ端末２０にインストールされたアプリ追加ツールを利用したオフラインの作業によって、事前にアプリを追加してもよい。この場合、ユーザは、ユーザ端末２０に記憶されたアプリをサーバ１０にアップロードしてもよい。
【0047】
例えば、利用状況取得部１０２は、複数のユーザの何れかにより追加されたアプリの利用状況を取得する。アプリを追加可能なユーザは、グループの管理権限を有するユーザであってもよいし、特に管理権限のないユーザであってもよい。アプリの管理権限は、アプリを追加したユーザに与えられるものとする。利用状況データベースＤＢ２には、ユーザが自身で追加したアプリの利用状況だけではなく、情報共有サービスで予め用意されたアプリの利用状況も格納されているので、利用状況取得部１０２は、これらのアプリの利用状況を取得する。
【0048】
なお、アプリ以外の他の機能も、ユーザによって追加可能であってもよい。例えば、ユーザは、自身でスケジュール共有機能を追加可能であってもよい。この場合、ユーザは、スケジュール共有のための画面のレイアウトを指定したり、スケジュール共有のために実行されるマクロを追加したりする。ユーザにより追加されたスケジュール共有機能のデータは、データ記憶部１００に記録される。他の機能も同様に、ユーザ自身で追加可能であってもよい。機能は、プラグインを利用して追加されてもよい。
【0049】
［処理実行部］
処理実行部１０３は、機能ごとに、当該機能の利用状況に基づいて、当該機能に関する所定の処理を実行する。本実施形態では、アクセス数が利用状況に相当するので、処理実行部１０３は、機能のアクセス数に基づいて、所定の処理を実行する。本実施形態では、機能の一例であるアプリをユーザ自身で追加可能なので、処理実行部１０３は、複数のユーザの何れかにより追加されたアプリのアクセス数に基づいて、所定の処理を実行する。
処理実行部１０３は、機能ごとに、当該機能の利用状況に基づいて、当該機能に関する所定の処理を実行する。本実施形態では、アクセス数が利用状況に相当するので、処理実行部１０３は、機能のアクセス数に基づいて、所定の処理を実行する。本実施形態では、機能の一例であるアプリをユーザ自身で追加可能なので、処理実行部１０３は、複数のユーザの何れかにより追加されたアプリのアクセス数に基づいて、所定の処理を実行する。
【0050】
所定の処理は、利用状況取得部１０２が取得した利用状況に基づいて実行される処理である。所定の処理は、予め定められた処理であればよく、利用状況を取得した目的に応じた処理であればよい。本実施形態では、処理実行部１０３は、所定の処理として、機能の利用状況をユーザ端末２０に表示させるための利用状況表示処理を実行する。このため、利用状況表示処理について説明している箇所は、所定の処理と読み替えることができる。所定の処理の他の例は、後述の変形例１～６で説明する。
【0051】
利用状況表示処理は、機能の利用状況を示す利用状況画面を表示させるための画像処理である。本実施形態では、処理実行部１０３がサーバ１０により実現されるので、利用状況表示処理は、利用状況画面の表示データを生成してユーザ端末２０に送信する処理である。表示データは、任意の形式であってよく、本実施形態のようにブラウザが利用される場合には、表示データは、ＨＴＭＬ形式であってもよい。表示データは、画面全体ではなく、画像又は動画といった画面の一部のパーツのデータであってもよい。
【0052】
図６は、利用状況画面の一例を示す図である。本実施形態では、管理権限を有する管理ユーザのユーザ端末２０に、管理ユーザによる管理対象となるアプリの利用状況画面ＳＣ２が表示される場合を説明する。例えば、管理ユーザが、ポータル画面ＳＣ１又は他の画面から利用状況画面ＳＣ２を表示させるための操作を行うと、処理実行部１０３は、図６の利用状況画面ＳＣ２を、管理ユーザのユーザ端末２０に表示させる。
【0053】
例えば、利用状況画面ＳＣ２には、機能の一例であるアプリの機能ＩＤ、アプリの名前、及び利用状況の一例であるアクセス数が表示される。利用状況画面ＳＣ２には、管理対象となる全てのアプリのアクセス数が表示されてもよいし、一部のアプリのアクセス数だけが表示されてもよい。処理実行部１０３は、利用状況画面ＳＣ２における表示対象となるアプリのアクセス数に基づいて、利用状況画面ＳＣ２の表示データを生成してユーザ端末２０に送信することによって、利用状況表示処理を実行する。
【0054】
例えば、処理実行部１０３は、あるアプリに対するグループ全体のアクセス数ではなく、部署ごとのアクセス数、又は、ユーザごとのアクセス数を示す利用状況画面ＳＣ２を、ユーザ端末２０に表示させてもよい。利用状況画面ＳＣ２では、図６のような表形式ではなく、棒グラフ又は円グラフといった他の形式でアクセス数が表示されてもよい。例えば、管理ユーザの操作によって、アクセス数を表示するためのグラフ又は表の形式が切り替えられてもよい。
【0055】
なお、本実施形態では、管理ユーザのユーザ端末２０に利用状況画面ＳＣ２が表示される場合を説明するが、処理実行部１０３は、アプリの利用状況を、一般ユーザのユーザ端末２０に表示させるための利用状況表示処理を実行してもよい。即ち、利用状況画面ＳＣ２は、管理ユーザのユーザ端末２０だけではなく、一般ユーザのユーザ端末２０にも表示可能であってもよい。
【0056】
例えば、処理実行部１０３は、一般ユーザのユーザ端末２０から、利用状況画面ＳＣ２の表示要求を受信した場合に、表示対象となるアプリのアクセス数を含む利用状況画面ＳＣ２の表示データを生成して当該ユーザ端末２０に送信する。アクセス数以外の他の利用状況の表示が要求された場合も同様にして、処理実行部１０３は、他の利用状況を含む利用状況画面ＳＣ２の表示データを生成すればよい。アプリ以外の他の機能の表示が要求された場合も同様である。
【0057】
なお、一般ユーザの利用状況画面ＳＣ２と、管理ユーザの利用状況画面ＳＣ２と、は同じであってもよいし、一部又は全部が異なってもよい。例えば、管理ユーザの利用状況画面ＳＣ２にしかアクセス数を表示できないアプリが定められている場合には、一般ユーザの利用状況画面ＳＣ２には、このアプリのアクセス数が表示されなくてもよい。例えば、管理ユーザの利用状況画面ＳＣ２には、任意の期間におけるアプリのアクセス数を表示可能であり、一般ユーザの利用状況画面ＳＣ２には、特定の期間におけるアプリのアクセス数しか表示できないといったような制限が設けられていてもよい。例えば、一般ユーザの利用状況画面ＳＣ２には、グループ全体の利用状況ではなく、自身の利用状況だけが表示されてもよい。一方で、管理ユーザの利用状況画面ＳＣ２には、グループ全体の利用状況、部署ごとの利用状況、及び個々の一般ユーザの利用状況といった各利用状況の表示を切り替えることができるようにしてもよい。
【0058】
また、処理実行部１０３は、アプリ以外の他の機能も同様に、利用状況表示処理を実行可能である。例えば、処理実行部１０３は、利用状況画面ＳＣ２に、スケジュール共有機能のアクセス数と、ファイル共有機能のアクセス数と、を表示するための利用状況表示処理を実行してもよい。利用状況表示処理は、アクセス数以外の他の利用状況として、ユーザの具体的な操作内容を表示させる処理であってもよい。利用状況表示処理は、利用状況取得部１０２が取得した利用状況を表示させるための処理であればよい。
【0059】
［３－２．ユーザ端末で実現されるアプリ］
データ記憶部２００は、記憶部２２により実現される。表示制御部２０１及び操作受付部２０２は、制御部１１により実現される。
データ記憶部２００は、記憶部２２により実現される。表示制御部２０１及び操作受付部２０２は、制御部１１により実現される。
【0060】
［データ記憶部］
データ記憶部２００は、ユーザに情報共有サービスを提供するために必要なデータを記憶する。例えば、データ記憶部２００は、情報共有サービスに関する種々の画面を表示するためのブラウザを記憶する。例えば、データ記憶部２００は、情報共有サービス専用のプログラムを記憶する。
データ記憶部２００は、ユーザに情報共有サービスを提供するために必要なデータを記憶する。例えば、データ記憶部２００は、情報共有サービスに関する種々の画面を表示するためのブラウザを記憶する。例えば、データ記憶部２００は、情報共有サービス専用のプログラムを記憶する。
【0061】
［表示制御部］
表示制御部２０１は、情報共有サービスにおける各種画面を、表示部２５に表示させる。例えば、表示制御部２０１は、サーバ１０から受信した表示データに基づいて、ポータル画面ＳＣ１、利用状況画面ＳＣ２、又は他の画面を、表示部２５に表示させる。
表示制御部２０１は、情報共有サービスにおける各種画面を、表示部２５に表示させる。例えば、表示制御部２０１は、サーバ１０から受信した表示データに基づいて、ポータル画面ＳＣ１、利用状況画面ＳＣ２、又は他の画面を、表示部２５に表示させる。
【0062】
［操作受付部］
操作受付部２０２は、情報共有サービスにおける各種操作を受け付ける。例えば、操作受付部２０２は、アプリにアクセスするための操作、アプリ内のレコードを編集する操作、又はアプリ内の詳細な情報を表示させるための操作を受け付ける。これらの操作内容は、サーバ１０に適宜送信される。
操作受付部２０２は、情報共有サービスにおける各種操作を受け付ける。例えば、操作受付部２０２は、アプリにアクセスするための操作、アプリ内のレコードを編集する操作、又はアプリ内の詳細な情報を表示させるための操作を受け付ける。これらの操作内容は、サーバ１０に適宜送信される。
【0063】
［４．情報共有システムで実行される処理］
図７は、情報共有システム１で実行される処理の一例を示す図である。図７では、情報共有システム１で実行される処理のうち、主に、管理ユーザのユーザ端末２０に利用状況画面ＳＣ２を表示させるための利用状況表示処理について説明する。アプリ等の機能を利用するための処理の詳細は、図７では省略する。
図７は、情報共有システム１で実行される処理の一例を示す図である。図７では、情報共有システム１で実行される処理のうち、主に、管理ユーザのユーザ端末２０に利用状況画面ＳＣ２を表示させるための利用状況表示処理について説明する。アプリ等の機能を利用するための処理の詳細は、図７では省略する。
【0064】
図７に示すように、サーバ１０は、ユーザ端末２０から受信した情報に基づいて、複数の機能の何れかが利用されたか否かを判定する（Ｓ１）。何れかの機能が利用されたと判定された場合（Ｓ１：Ｙ）、サーバ１０は、利用状況データベースＤＢ２に格納された、Ｓ１で利用されたと判定された機能の利用状況を更新する（Ｓ２）。例えば、アプリが利用されるたびに、Ｓ２の処理が実行され、そのたびにアプリのアクセス数が増加する。アクセス数以外の他の利用状況も更新される。アプリ以外の他の機能が利用された場合も、Ｓ２の処理で利用状況が更新される。
【0065】
管理ユーザのユーザ端末２０は、サーバ１０との間で、管理ユーザが情報共有サービスにログインするためのログイン処理を実行する（Ｓ３）。ログイン処理が成功すると、ユーザ端末２０は、サーバ１０との間で、ポータル画面ＳＣ１を表示させるための処理を実行する（Ｓ４）。ユーザ端末２０は、ポータル画面ＳＣ１又は他の画面から、管理ユーザが利用状況画面ＳＣ２を表示させるための操作を行うと、サーバ１０に対し、利用状況画面ＳＣ２の表示要求を送信する（Ｓ５）。
【0066】
サーバ１０は、利用状況画面ＳＣ２の表示要求を受信すると（Ｓ６）、利用状況データベースＤＢ２を参照し、管理対象となる機能の利用状況を取得する（Ｓ７）。本実施形態では、管理ユーザが属するグループの全てのアプリが管理対象になる場合を説明するが、アプリごとに管理権限が設定されており、管理ユーザが管理権限を有するアプリだけが管理対象になってもよい。アプリのアクセス数以外の他の利用状況の表示が要求された場合には、Ｓ７で他の利用状況が取得される。アプリ以外の他の機能の利用状況の表示が要求された場合も、Ｓ７で他の機能の利用状況が取得される。
【0067】
サーバ１０は、Ｓ７で取得した管理対象となるアプリのアクセス数に基づいて、利用状況画面ＳＣ２の表示データを生成してユーザ端末２０に送信する（Ｓ８）。ユーザ端末２０は、利用状況画面ＳＣ２の表示データを受信すると（Ｓ９）、表示データに基づいて、利用状況画面ＳＣ２を表示部２５に表示させ（Ｓ１０）、本処理は終了する。以降、管理ユーザは、利用状況画面ＳＣ２を確認し、あまり利用されていないアプリを削除するか否かを検討したり、最近よく利用されているアプリを改修するか否かを検討したりする。
【0068】
本実施形態の情報共有システム１は、機能ごとに、当該機能の利用状況に基づいて、当該機能に関する所定の処理を実行する。情報共有サービス全体の利用状況ではなく、個々の機能の利用状況を取得して所定の処理を実行することによって、個々の機能がどの程度又はどのように利用されているかを詳細に解析できるので、情報共有サービスにおけるユーザの利便性が高まる。
【0069】
また、情報共有システム１は、所定の処理として、利用状況表示処理を実行する。これにより、個々の機能の利用状況をユーザが確認しやすくなる。例えば、管理ユーザは、あまり利用していない機能を停止するか否かを検討したり、最近よく利用されている機能を改修するか否かを検討したりできるようになる。例えば、機能の利用状況を、一般ユーザのユーザ端末２０に表示させるための利用状況表示処理を実行する場合には、個々の機能の利用状況を一般ユーザが確認しやすくなる。
【0070】
また、情報共有システム１は、機能の利用状況として、当該機能に対するアクセス数を取得する。アクセス数といった分かりやすい指標を取得することにより、個々の機能がどの程度利用されているかを解析しやすくなる。
【0071】
また、情報共有システム１は、ユーザが追加した機能の利用状況を取得する。ユーザが自分で機能を追加できるようにすると、情報共有サービスに多数の機能が追加され、機能の管理が煩雑になる可能性がある。例えば、よく利用されている機能と、あまり利用されていない機能と、の区別がつかない可能性がある。この点、機能ごとの利用状況を取得することによって、多数存在する機能の管理が容易になる。
【0072】
［５．変形例］
なお、本開示は、以上説明した実施形態に限定されるものではない。本開示の趣旨を逸脱しない範囲で、適宜変更可能である。
なお、本開示は、以上説明した実施形態に限定されるものではない。本開示の趣旨を逸脱しない範囲で、適宜変更可能である。
【0073】
図８は、変形例における機能ブロックを示す図である。検索部１０４は、制御部１１により実現される。
【0074】
［５－１．変形例１］
例えば、処理実行部１０３が実行する所定の処理は、実施形態で説明した利用状況表示処理に限られない。所定の処理は、利用状況を取得した目的に応じた処理であればよい。変形例１～６では、所定の処理の他の例を説明する。処理実行部１０３は、実施形態及び変形例１～６で説明した所定の処理の全部又は一部を実行可能であればよい。なお、変形例１でも、機能の一例としてアプリを説明する。
例えば、処理実行部１０３が実行する所定の処理は、実施形態で説明した利用状況表示処理に限られない。所定の処理は、利用状況を取得した目的に応じた処理であればよい。変形例１～６では、所定の処理の他の例を説明する。処理実行部１０３は、実施形態及び変形例１～６で説明した所定の処理の全部又は一部を実行可能であればよい。なお、変形例１でも、機能の一例としてアプリを説明する。
【0075】
例えば、処理実行部１０３は、所定の処理として、複数のアプリのうち、複数のユーザの各々による利用が第１の基準を満たすアプリを停止するための機能停止処理を実行してもよい。第１の基準は、機能停止処理を実行するか否かの条件である。変形例１では、機能の利用が相対的に少ないことが第１の基準に相当する場合を例に挙げるが、第１の基準は、他の基準であってもよい。例えば、第１の基準は、利用が相対的に少ないのではなく、ユーザが一切利用しないこと、ユーザの利用回数が閾値未満であること、又は最後に利用されてからの経過時間が所定時間以上であることであってもよい。アプリの利用が相対的に少ないとは、アプリの利用回数（例えば、アクセス数）が他のアプリよりも少ないことである。例えば、アプリの利用回数の降順でアプリを順位付けした場合に、所定の順位よりも下の順位のアプリは、アプリの利用が相対的に少ないアプリに相当する。
【0076】
変形例１の機能停止処理は、アプリ自体の利用を停止するための処理である。機能停止処理が実行された場合には、全てのユーザは、アプリを利用できなくなる。例えば、処理実行部１０３は、アプリごとに、当該アプリを利用可能な全てのユーザの利用が少なくなったか否かを判定する。利用が少ないとは、アプリの利用回数（例えば、アクセス数）が所定の閾値未満であることに相当する。例えば、ある第１期間における利用回数が閾値以上であったが、第１期間よりも後の第２期間における利用回数が閾値未満になることは、アプリの利用回数が少なくなることに相当する。処理実行部１０３は、停止対象となるアプリの機能ＩＤに関連付けられた全てのユーザＩＤの関連付けを解除することによって、機能停止処理を実行する。
【0077】
なお、機能停止処理は、他の処理であってもよく、上記の例に限られない。例えば、処理実行部１０３は、停止対象となるアプリのレコード自体をアプリデータベースＤＢ３から削除することによって、当該アプリの利用を停止してもよい。例えば、ユーザデータベースＤＢ１に、あるユーザのユーザＩＤと、このユーザの利用が許可されたアプリの機能ＩＤと、が関連付けられている場合には、処理実行部１０３は、ユーザデータベースＤＢ１におけるこれらの関連付けを全て解除することによって、機能停止処理を実行してもよい。他にも例えば、利用が相対的に少ないアプリの一覧を管理ユーザのユーザ端末２０に表示させ、管理ユーザの操作に応じて利用を停止する処理が機能停止処理に相当してもよい。アプリ以外の他の機能についても、同様の機能停止処理が実行されてよい。
【0078】
変形例１の情報共有システム１は、所定の処理として、機能停止処理を実行する。これにより、第１の基準を満たす機能を停止し、管理ユーザが機能を手動で停止する操作をしなくて済むようになるので、管理ユーザの負担を軽減できる。
【0079】
［５－２．変形例２］
例えば、ユーザが自分で追加したアプリは、原則として無料であるが、情報共有システムで予め用意されたアプリやアプリ以外の他の機能については、有料のことがある。例えば、有料の機能については、継続して契約するか否かをユーザが任意で決定したり、契約プランを変更したりできるようにしてもよい。変形例２の情報共有サービスでは、機能ごとの契約が可能である。機能ごとの契約自体は、公知の種々の契約の仕組みを利用可能である。
例えば、ユーザが自分で追加したアプリは、原則として無料であるが、情報共有システムで予め用意されたアプリやアプリ以外の他の機能については、有料のことがある。例えば、有料の機能については、継続して契約するか否かをユーザが任意で決定したり、契約プランを変更したりできるようにしてもよい。変形例２の情報共有サービスでは、機能ごとの契約が可能である。機能ごとの契約自体は、公知の種々の契約の仕組みを利用可能である。
【0080】
変形例２の処理実行部１０３は、所定の処理として、機能の利用状況に応じた契約をするための契約処理を実行する。契約処理は、継続して契約するか否かを自動的に決定したり、契約プランを自動的に変更したりする処理であってもよいが、変形例２では、継続して契約するか否かをユーザに提案したり、契約プランの変更をユーザに促したりする処理が契約処理に相当する場合を説明する。例えば、処理実行部１０３は、利用状況画面に契約に関する情報を表示させることによって、契約処理を実行する。変形例２でも、機能の一例としてアプリを説明する。
【0081】
図９は、変形例２の利用状況画面ＳＣ２の一例を示す図である。例えば、処理実行部１０３は、利用が相対的に少ないアプリの契約を終了することを促すメッセージを利用状況画面ＳＣ２に表示させることによって、契約処理を実行する。例えば、処理実行部１０３は、利用が相対的に少ないアプリの契約プランを今よりも安い契約プランに変更したり、継続利用自体を停止することを促したりするメッセージを利用状況画面ＳＣ２に表示させることによって、契約処理を実行する。利用が相対的に少ないか否かを判定する方法は、変形例２と同様であってよい。
【0082】
図９の例では、アクセス数が閾値未満のアプリが、利用が相対的に少ないアプリに相当する。例えば、雑談アプリのアクセス数が閾値未満なので、利用状況画面ＳＣ２には、雑談アプリを削除して継続利用を停止することを促すメッセージが表示される。処理実行部１０３は、雑談アプリの継続利用を自動的に停止したり、現在よりも安い契約プランに自動的に変更したりしてもよい。
【0083】
逆に、処理実行部１０３は、利用が増えているアプリの契約プランを今よりも高い契約プランに変更することを促すメッセージを利用状況画面ＳＣ２に表示させることによって、契約処理を実行してもよい。図１０の例では、請求管理アプリのアクセス数が増加傾向にあるので、利用状況画面ＳＣ２には、契約プランの変更を促すメッセージが表示される。処理実行部１０３は、請求管理アプリを、今よりも高くて便利な契約プランに自動的に変更してもよい。アプリ以外の他の機能についても同様に、他の機能の利用状況に応じた契約処理が実行されるようにすればよい。
【0084】
変形例２の情報共有システム１は、所定の処理として、契約処理を実行する。これにより、ユーザは、現在利用している機能の契約を検討しやすくなるので、ユーザの利便性が高まる。
【0085】
［５－３．変形例３］
例えば、利用状況取得部１０２は、利用状況として、複数のユーザのうち、機能で提供される情報にアクセスしたユーザのユーザＩＤを取得してもよい。機能で提供される情報は、機能を利用して共有される情報である。例えば、アプリであれば、アプリで表示可能な表に含まれるレコードの情報、又は、レコード以外の部分に含まれる情報は、アプリで提供される情報に相当する。例えば、スケジュール共有機能であれば、スケジュールの画面で表示可能な予定やコメントは、スケジュール共有機能で提供される情報に相当する。変形例３では、利用状況データベースＤＢ２に、個々の機能で提供される情報ごとに、当該情報にアクセスしたユーザのユーザＩＤが格納されているものとする。
例えば、利用状況取得部１０２は、利用状況として、複数のユーザのうち、機能で提供される情報にアクセスしたユーザのユーザＩＤを取得してもよい。機能で提供される情報は、機能を利用して共有される情報である。例えば、アプリであれば、アプリで表示可能な表に含まれるレコードの情報、又は、レコード以外の部分に含まれる情報は、アプリで提供される情報に相当する。例えば、スケジュール共有機能であれば、スケジュールの画面で表示可能な予定やコメントは、スケジュール共有機能で提供される情報に相当する。変形例３では、利用状況データベースＤＢ２に、個々の機能で提供される情報ごとに、当該情報にアクセスしたユーザのユーザＩＤが格納されているものとする。
【0086】
ユーザＩＤは、ユーザ識別情報の一例である。このため、ユーザＩＤについて説明している箇所は、ユーザ識別情報と読み替えることができる。ユーザ識別情報は、ユーザを識別可能な情報であればよく、ユーザＩＤに限られない。例えば、ユーザ識別情報は、メールアドレス又は電話番号であってもよいし、ユーザＩＤではなくユーザアカウントと呼ばれる情報であってもよい。
【0087】
変形例３の処理実行部１０３は、アプリのユーザＩＤに基づいて、所定の処理を実行する。このため、変形例３の所定の処理は、アプリで提供される情報にアクセスしたユーザのユーザＩＤに基づいて実行される処理である。実施形態で説明した利用状況表示処理であれば、処理実行部１０３は、機能で提供される情報にアクセスしたユーザのユーザＩＤを示す利用状況画面ＳＣ２を表示させるための利用状況表示処理を実行する。
【0088】
例えば、アプリ内の特定のレコードにアクセス可能なユーザを制限したい場合、管理ユーザは、このレコードに対してアクセス権を設定できるようにしてもよい。管理ユーザは、特定のレコードに対し、このレコードにアクセス可能なユーザを指定することによって、アクセス権の設定作業をする。管理ユーザが設定作業を間違えてしまうと、本来はアクセスさせたくないユーザがこのレコードにアクセスできることがある。この場合に、処理実行部１０３は、このレコードにアクセスしたユーザのユーザＩＤを、管理ユーザに通知することによって、所定の処理を実行してもよい。
【0089】
例えば、処理実行部１０３は、あるアプリで提供される情報にあまりアクセスしていないユーザのアクセス権を変更することによって、所定の処理を実行してもよい。処理実行部１０３は、あるアプリのレコードにあまりアクセスしないユーザに対し、このレコードにアクセスできないようにアクセス権を変更してもよい。他にも例えば、処理実行部１０３は、あるアプリをあまり利用しないユーザに対し、アプリを利用するように促す通知を送信してもよい。アプリ以外の他の機能についても同様に、上記説明した所定の処理が実行されてもよい。
【0090】
なお、アプリは、特定のユーザしか利用できないようにアクセス権を設定することができるようにしてもよい。例えば、あるグループのアプリは、このグループに属する複数のユーザのうちの一部しか利用できないように、アクセス権が設定される。アプリのアクセス権は、アプリの管理権限を有する管理ユーザにより指定される。変形例３のデータ記憶部１００は、アプリのアクセス権が定義されたアプリデータベースＤＢ３を記憶する。データ記憶部１００は、アプリ以外の他の機能のアクセス権が定義されたデータベースを記憶してもよい。
【0091】
図１０は、アプリデータベースＤＢ３の一例を示す図である。例えば、アプリデータベースＤＢ３には、グループＩＤ、複数のアプリの各々の機能ＩＤと、当該アプリのアクセス権を有するユーザのユーザＩＤと、が関連付けられている。サービス提供部１０１は、あるユーザのユーザ端末２０から、あるアプリの利用要求が送信された場合に、アプリデータベースＤＢ３を参照し、このユーザのユーザＩＤが、このアプリの機能ＩＤに関連付けられているか否かを判定する。サービス提供部１０１は、これらが関連付けられていない場合には、アプリの利用を許可せず、これらが関連付けられている場合に、このアプリの利用を許可する。
【0092】
例えば、サービス提供部１０１は、あるユーザのユーザ端末２０にポータル画面ＳＣ１を表示させる場合に、アプリデータベースＤＢ３を参照し、このユーザがアクセス権を有するアプリを特定し、当該特定されたアプリだけを表示領域Ａ１０に表示させてもよい。なお、アプリデータベースＤＢ３には、アプリのアクセス権を有するユーザＩＤではなく、アプリのアクセス権を有さないユーザのユーザＩＤが格納されてもよい。
【0093】
変形例３の処理実行部１０３は、ユーザ識別情報に基づく所定の処理として、複数のユーザのうち、アプリの利用が相対的に少ないユーザによる利用を停止するための利用停止処理を実行してもよい。アプリの利用が相対的に少ないユーザとは、アプリの利用回数（例えば、アクセス数）が他のユーザ又は所定の閾値よりも少ないユーザである。例えば、アプリの利用回数の降順でユーザを順位付けした場合に、所定の順位よりも下の順位のユーザは、アプリの利用が相対的に少ないユーザに相当する。例えば、アプリを一切利用していないユーザ、又は、アプリの利用回数が閾値未満のユーザは、アプリの利用が相対的に少ないユーザに相当する。閾値は、固定値であってもよいし、全ユーザの利用回数に応じて決定されてもよい。
【0094】
変形例３では、図５の利用状況データベースＤＢ２に格納された利用状況のうち、アプリにアクセスしたユーザのユーザＩＤと、アプリへのアクセス日時と、が参照される。利用状況取得部１０２は、これらの利用状況を取得する。アプリの利用が相対的に少ないか否かの集計対象となるのは、過去の全期間であってもよいし、直近の一部の期間であってもよい。変形例３では、直近の過去半年間にアプリを一切利用しないことがアプリの利用が相対的に少ないことに相当する場合を例に挙げる。
【0095】
処理実行部１０３は、アプリごとに、当該アプリの利用状況に基づいて、当該アプリの利用が相対的に少ないユーザを特定する。例えば、処理実行部１０３は、アプリごとに、当該アプリのアクセス権を有するユーザのうち、直近の過去半年間に当該アプリを一切利用していないユーザを、当該アプリの利用が相対的に少ないユーザとして特定する。例えば、処理実行部１０３は、アプリの利用が相対的に少ないユーザがアプリを利用できないようにアクセス権を設定することによって、利用停止処理を実行する。
【0096】
なお、利用停止処理は、他の処理であってもよく、上記の例に限られない。例えば、ユーザデータベースＤＢ１に、あるユーザのユーザＩＤと、このユーザがアクセス権を有するアプリの機能ＩＤと、が関連付けられている場合には、処理実行部１０３は、このユーザによるこのアプリの利用が少なくなった場合に、ユーザデータベースＤＢ１におけるアクセス権の設定を変更することによって、利用停止処理を実行してもよい。他にも例えば、アプリの利用が相対的に少ないユーザの一覧を管理ユーザのユーザ端末２０に表示させ、管理ユーザの操作に応じてアクセス権を設定する処理が利用停止処理に相当してもよい。アプリ以外の他の機能についても、同様の利用停止処理が実行されてよい。
【0097】
変形例３の情報共有システム１は、複数のユーザのうち、アプリで提供される情報にアクセスしたユーザのユーザＩＤに基づいて、所定の処理を実行する。これにより、例えば、どのユーザが情報にアクセスしたのかを詳細に分析したり、アクセス権を自動設定したりすることができるので、情報共有サービスにおける利便性が高まる。例えば、あるアプリの特定のレコードを、特定のユーザにしかアクセスできないように制限した場合に、本来はアクセスできないはずのユーザが、アクセス権の設定ミスによってアクセスできる状態であるかを、管理ユーザが確認しやすくなる。このようなアクセスが発生した場合に、管理ユーザに対して所定の通知が送信されてもよい。例えば、所定の処理として、利用停止処理を実行した場合、アプリを一例とする機能をあまり利用しないユーザの利用を停止し、管理ユーザがアクセス権を手動で変更する操作をしなくて済むようになるので、管理ユーザの負担を軽減できる。
【0098】
［５－４．変形例４］
変形例４では、機能の一例として、掲示板の一種であるスレッドを利用してコミュニケーションを取るためのスレッド機能を説明する。例えば、処理実行部１０３は、所定の処理として、スレッド機能で提供される複数の情報のうち、複数のユーザの各々による利用が第２の基準を満たす情報を表示するための情報表示処理を実行してもよい。
変形例４では、機能の一例として、掲示板の一種であるスレッドを利用してコミュニケーションを取るためのスレッド機能を説明する。例えば、処理実行部１０３は、所定の処理として、スレッド機能で提供される複数の情報のうち、複数のユーザの各々による利用が第２の基準を満たす情報を表示するための情報表示処理を実行してもよい。
【0099】
スレッド機能で提供される情報とは、スレッドに投稿されたコメント等の情報である。第２の基準とは、情報表示処理を実行するか否かの条件である。変形例４では、よく閲覧されていることが第２の基準に相当する場合を例に挙げるが、第２の基準は、他の基準であってもよい。例えば、第２の基準は、特定のユーザに閲覧されること、いいねの数が閾値以上であること、返信数が閾値以上であること、特定の文言を閾値以上含むこと、及び被リンク数が閾値以上であることであってもよい。よく閲覧される情報とは、アクセス数が閾値以上の情報である。変形例４では、利用状況データベースＤＢ２に、スレッド機能で提供される個々の情報ごとに、当該情報のアクセス数が格納されているものとする。
【0100】
図１１は、変形例４のポータル画面ＳＣ１の一例を示す図である。図１１の例では、ポータル画面ＳＣ１の表示領域Ａ１１に、よく閲覧されている情報が表示される場合が示されている。変形例４の利用状況は、スレッド機能で作成されたスレッドでやりとりされている情報ごとに取得されるものとする。スレッド内の個々の投稿ごとに利用状況が取得されてもよい。このため、利用状況取得部１０２は、スレッド内の情報ごとに、利用状況を取得する。処理実行部１０３は、スレッド内の情報ごとの利用状況に基づいて、よく閲覧されている情報を特定する。処理実行部１０３は、よく閲覧されている情報又はそのリンクを、ポータル画面ＳＣ１に表示させることによって、情報表示処理を実行する。
【0101】
なお、情報表示処理は、スレッド機能以外の他の機能にも適用可能である。例えば、アプリが機能に相当する場合には、アプリに登録された複数の情報のうち、よく閲覧されている情報を表示するための処理が情報表示処理に相当してもよい。例えば、スケジュール共有機能が機能に相当する場合には、スケジュール共有機能に登録された複数の情報のうち、よく閲覧されている情報を表示するための処理が情報表示処理に相当してもよい。他の機能についても同様に、よく閲覧されている情報が情報表示処理によって表示されるようにすればよい。
【0102】
変形例４の情報共有システム１は、所定の処理として、情報表示処理を実行する。これにより、情報共有サービスでよく閲覧されている情報にユーザが気付きやすくなるので、ユーザの利便性が高まる。
【0103】
［５－５．変形例５］
例えば、処理実行部１０３は、所定の処理として、機能で提供される複数の情報のうち、複数のユーザの各々による利用が第３の基準を満たす情報に関する権限を変更するための権限変更処理を実行してもよい。
例えば、処理実行部１０３は、所定の処理として、機能で提供される複数の情報のうち、複数のユーザの各々による利用が第３の基準を満たす情報に関する権限を変更するための権限変更処理を実行してもよい。
【0104】
第３の基準とは、権限変更処理を実行するか否かの条件である。変形例５では、アプリの利用回数が閾値未満であることが第３の基準に相当する場合を例に挙げるが、第３の基準は、他の基準であってもよい。例えば、第３の基準は、アプリが閲覧されるが更新されないこと、アプリに対してコメントが投稿されないこと、他のユーザのコメントに対するリアクションがされないこと、特定のユーザに閲覧されていないこと、特定のリアクションが閾値以上行われたこと、及び作成日時が閾値以上より前であることであってもよい。変形例３で説明したアプリのレコードのアクセス権を変更する処理は、権限変更処理の一種である。変形例５では、変形例３では説明しなかった処理も、権限変更処理として実行可能である。変形例５では、機能の一例として、再びアプリを説明する。
【0105】
例えば、権限変更処理は、アプリの情報を更新できないようにアーカイブ化する処理であってもよい。アーカイブ化により、アプリの情報はそれ以上更新できないようになる。アーカイブ化により、データ形式を変更してデータの圧縮が行われてもよい。例えば、表形式のデータだったアプリの情報をテキスト形式に変更することによって、アーカイブ化が実行されてもよい。例えば、ある情報を示す画面のスクリーンショットを示す画像データが保存されることによって、アーカイブ化が実行されてもよい。アーカイブ化の方法自体は、公知の種々の方法を利用可能である。処理実行部１０３は、閲覧されなくなったアプリをアーカイブ化してもよい。
【0106】
変形例５の情報共有システム１は、所定の処理として、権限変更処理を実行する。これにより、例えば、管理ユーザがアクセス権を手動で変更する操作をしなくて済むようになるので、管理ユーザの負担を軽減できる。例えば、ある情報をこれ以上更新できないようにアーカイブ化する場合も同様に、管理ユーザが手動でアーカイブ化する手間を軽減できる。アーカイブ化により、情報のサイズを圧縮できるので、メモリ消費量を削減できる。
【0107】
［５－６．変形例６］
例えば、所定の処理は、情報共有サービスにおける検索でヒットしやすくするための処理であってもよい。変形例６の情報共有システム１は、検索部１０４を含む。検索部１０４は、複数のユーザの各々により入力された検索条件に基づいて、複数の機能の各々で提供される情報を検索する。変形例６では、アプリ内の検索を例に挙げるが、検索の範囲は、アプリに限られない。例えば、スレッド等の他の機能の情報が検索の対象になってもよいし、複数の機能をまたがって検索が実行されてもよい。検索自体は、種々の検索エンジンで採用されている手法を利用可能である。
例えば、所定の処理は、情報共有サービスにおける検索でヒットしやすくするための処理であってもよい。変形例６の情報共有システム１は、検索部１０４を含む。検索部１０４は、複数のユーザの各々により入力された検索条件に基づいて、複数の機能の各々で提供される情報を検索する。変形例６では、アプリ内の検索を例に挙げるが、検索の範囲は、アプリに限られない。例えば、スレッド等の他の機能の情報が検索の対象になってもよいし、複数の機能をまたがって検索が実行されてもよい。検索自体は、種々の検索エンジンで採用されている手法を利用可能である。
【0108】
変形例６の処理実行部１０３は、所定の処理として、複数のアプリのうち、よく利用されているアプリで提供される情報が検索でヒットしやすくなるためのヒット処理を実行してもよい。例えば、処理実行部１０３は、あるアプリのアクセス数が多いほど、このアプリの情報の検索スコアが高くなるように検索スコアを調整することによって、ヒット処理を実行する。処理実行部１０３は、アクセス数が閾値以上のアプリだけを検索の対象にすることによって、ヒット処理を実行してもよい。
【0109】
なお、アプリ以外の他の機能も同様に、よく利用されている機能の情報が検索でヒットしやすくなるようにすればよい。例えば、ある機能において、その場で流れ去ってしまうフロー情報と、その場で流れ去らずに蓄積される情報であるストック情報と、が存在する場合に、フロー情報よりもストック情報の方が優先的に検索されることがある。この場合には、処理実行部１０３は、よく利用されている機能の情報を、フロー情報からストック情報に変更することによって、検索でヒットしやすくしてもよい。この場合、個々の情報には、フロー情報であるか、ストック情報であるか、を示す属性が設定されているものとする。処理実行部１０３は、情報の属性を変更することによって、フロー情報をストック情報に変更する。
【0110】
変形例６の情報共有システム１は、所定の処理として、ヒット処理を実行する。これにより、よく閲覧されている機能の情報を検索でヒットさせやすくなるので、検索の利便性を高めることができる。
【0111】
［５－７．変形例７］
例えば、複数の機能の各々は、当該機能に関するＡＰＩを利用して、複数のユーザの各々に提供されてもよい。変形例７のサービス提供部１０１は、ある機能のＡＰＩを利用して、この機能を提供する。例えば、サービス提供部１０１は、ユーザ端末２０から、ある機能のＡＰＩに対する要求を受信した場合に、このＡＰＩに対する要求に基づいて、ユーザに対し、この機能を提供する。ＡＰＩを利用した機能の提供方法自体は、種々の方法を利用可能である。例えば、スケジュール共有機能用のＡＰＩ、ファイル共有機能用のＡＰＩ、個々のアプリに対応するＡＰＩといったＡＰＩが存在してもよい。変形例７の利用状況取得部１０２は、機能の利用状況を、当該機能のＡＰＩを利用して取得する。
例えば、複数の機能の各々は、当該機能に関するＡＰＩを利用して、複数のユーザの各々に提供されてもよい。変形例７のサービス提供部１０１は、ある機能のＡＰＩを利用して、この機能を提供する。例えば、サービス提供部１０１は、ユーザ端末２０から、ある機能のＡＰＩに対する要求を受信した場合に、このＡＰＩに対する要求に基づいて、ユーザに対し、この機能を提供する。ＡＰＩを利用した機能の提供方法自体は、種々の方法を利用可能である。例えば、スケジュール共有機能用のＡＰＩ、ファイル共有機能用のＡＰＩ、個々のアプリに対応するＡＰＩといったＡＰＩが存在してもよい。変形例７の利用状況取得部１０２は、機能の利用状況を、当該機能のＡＰＩを利用して取得する。
【0112】
変形例７では、労務管理者である管理ユーザが、管理対象の社員である一般ユーザの出退勤や労働時間を管理する場合を例に挙げる。このため、変形例７の情報共有サービスは、出退勤管理機能を有する。出退勤管理機能は、ユーザの出社時間と退勤時間を管理するための機能である。例えば、サービス提供部１０１は、ユーザ端末２０から、ユーザが出社したことを示す通知を受信した場合に、出退勤管理機能を利用して、ユーザデータベースＤＢ１にユーザの出社時間を格納する。サービス提供部１０１は、ユーザ端末２０から、ユーザが退勤したことを示す通知を受信した場合に、出退勤管理機能を利用して、ユーザデータベースＤＢ１にユーザの退勤時間を格納する。
【0113】
例えば、出退勤管理機能は、スケジュール共有機能の一部であってもよい。この場合、スケジュール共有機能の利用状況に基づいて、管理ユーザが、一般ユーザ又は組織全体の会議、往来訪の実態を把握するための情報が、スケジュール共有機能のＡＰＩを利用して取得されてもよい。即ち、利用状況取得部１０２は、一般ユーザごとの予定情報の統計を取るために、スケジュール共有機能のＡＰＩを利用して、スケジュール共有機能の利用状況が取得されてもよい。この利用状況は、個々の一般ユーザがスケジュール共有機能を利用して登録したスケジュールそのものであってもよい。
【0114】
例えば、利用状況取得部１０２は、スケジュール共有機能のＡＰＩを利用して、一般ユーザの予定を示すメニューごとの予定の個数／合計時間（往来訪又は休み予定等）、個人の会議に関する負荷、定時内の予定の個数／合計時間数、定時外の予定の個数／合計時間数、ある一定の時間内における繰り返し予定の個数／合計時間数、組織／グループ単位の予定情報の統計、組織／グループの会議に関する負荷、組織の繰り返し予定の個数／時間、組織／グループ内で予定に多く参加しているユーザを、利用状況として取得する。
【0115】
変形例７で説明した利用状況は、労務管理の管理ユーザ向けの統計なので、利用状況取得部１０２は、労務管理者が必要な情報を取得できるようになる。例えば、利用状況取得部１０２は、スケジュール共有機能のＡＰＩを利用して、休暇又は中抜け等の時間、早出、残業時間(タイムカードとの組み合わせ）を取得してもよい。変形例７では、スケジュール共有機能を例に挙げたが、実施形態及び変形例１～６で説明した種々のアプリ及び他の各種機能についても同様に、利用状況取得部１０２は、個々の機能のＡＰＩを利用して、利用状況を取得してもよい。
【0116】
変形例７の情報共有システム１は、機能の利用状況を、当該機能のＡＰＩを利用して取得する。個々の機能がＡＰＩを利用して提供される場合には、必ずＡＰＩに対する要求が発生するので、ＡＰＩを利用して利用状況を取得することによって、機能の利用状況をより正確に取得できる。
【0117】
［５－８．変形例８］
例えば、利用状況取得部１０２は、機能の利用状況として、当該機能に関する画面を表示させている表示時間を取得してもよい。表示時間は、ある機能の画面の表示を開始してから終了するまでの時間である。例えば、アプリが機能に相当する場合、個々のアプリをユーザ端末２０に表示させている時間が表示時間に相当する。他の機能も同様である。例えば、スケジュール共有機能であれば、スケジュールの画面を表示させている時間が表示時間に相当する。スレッド機能であれば、個々のスレッドの画面を表示させている時間が表示時間に相当する。
例えば、利用状況取得部１０２は、機能の利用状況として、当該機能に関する画面を表示させている表示時間を取得してもよい。表示時間は、ある機能の画面の表示を開始してから終了するまでの時間である。例えば、アプリが機能に相当する場合、個々のアプリをユーザ端末２０に表示させている時間が表示時間に相当する。他の機能も同様である。例えば、スケジュール共有機能であれば、スケジュールの画面を表示させている時間が表示時間に相当する。スレッド機能であれば、個々のスレッドの画面を表示させている時間が表示時間に相当する。
【0118】
変形例８のサービス提供部１０１は、ある機能の画面をユーザ端末２０に表示させた場合に計時を開始し、他の画面に遷移するまでの時間を計測することによって、この機能の表示時間を計測する。サービス提供部１０１は、当該計測された表示時間を、利用状況として、利用状況データベースＤＢ２に格納する。利用状況取得部１０２は、利用状況データベースＤＢ２に格納された、個々の機能の表示時間を、利用状況として取得する。
【0119】
変形例８の処理実行部１０３は、機能の表示時間に基づいて、所定の処理を実行する。所定の処理は、実施形態又は変形例１～７で説明した何れの処理であってもよい。例えば、処理実行部１０３は、個々の機能の表示時間を、利用状況画面ＳＣ２に表示させるための利用状況表示処理を実行する。例えば、処理実行部１０３は、表示時間が相対的に少ないユーザによる機能の利用を停止するための利用停止処理を実行する。他の所定の処理についても同様に、表示時間に基づいて実行されてよい。
【0120】
変形例８の情報共有システム１は、機能に関する画面を表示させている表示時間に基づいて、所定の処理を実行する。これにより、ある機能の画面を、ユーザがどの程度しっかりと確認しているかを分析することができる。
【0121】
［５－９．その他の変形例］
例えば、上記変形例を組み合わせてもよい。
例えば、上記変形例を組み合わせてもよい。
【0122】
例えば、上記説明した各機能は、情報共有システム１における任意の装置で実現されるようにすればよい。例えば、サーバ１０で実現されるものとして説明した機能がユーザ端末２０によって実現されてもよい。この場合、サーバ１０が実行した処理と同様の処理が、ブラウザのスクリプトによって実行されたり、ユーザ端末２０にインストールされたプログラムによって実行されたりすればよい。例えば、各機能が複数のコンピュータによって分担されてもよい。
【符号の説明】
【0123】
１ 情報共有システム、１０ サーバ、１１，２１ 制御部、１２，２２ 記憶部、１３，２３ 通信部、２０ ユーザ端末、２４ 操作部、２５ 表示部、１００ データ記憶部、１０１ サービス提供部、１０２ 利用状況取得部、１０３ 処理実行部、１０４ 検索部、２００ データ記憶部、２０１ 表示制御部、２０２ 操作受付部、Ｎ ネットワーク、ＤＢ１ ユーザデータベース、ＤＢ２ 利用状況データベース、ＤＢ３ アプリデータベース、ＳＣ１ ポータル画面、ＳＣ２ 利用状況画面、Ａ１０ 表示領域。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】