説明

情報共有システム、情報共有方法及びプログラム

【課題】過去の記事に対する合理的なアクセスを可能にした上で、情報セキュリティを向上させることが可能な情報共有システム、情報共有方法及びプログラムを提供することにある。
【解決手段】記事入力手段は、第1のグループに投稿された記事を入力する。公開範囲決定手段は、入力された記事の投稿先である第1のグループに属するユーザが属する第2のグループを記事の公開範囲として決定する。アクセス要求入力手段は、記事に対するアクセス要求を入力する。アクセス可否決定手段は、グループ情報格納手段に格納されているグループ情報、ユーザ情報格納手段に格納されているユーザ情報及び記事の公開範囲に基づいて、入力されたアクセス要求の対象となる記事に対する当該アクセス要求の要求元であるユーザのアクセス可否を決定する。

【発明の詳細な説明】
【技術分野】
【0001】
本発明の実施形態は、グループに投稿された記事を当該グループに属する複数のユーザ間で共有する情報共有システム、情報共有方法及びプログラムに関する。
【背景技術】
【0002】
近年、例えば電子掲示板(BBS)やメーリングリストにおけるタスクやコミュニティ、文書管理システムにおけるカテゴリといった、ある「場」に参加(登録)しているユーザがその場に登録されたファイルや記事などの情報を閲覧・共有できる機能をもった情報共有システムが知られている。この「場」のことを、便宜上グループと呼ぶ。
【0003】
この情報共有システムが例えば企業等において用いられる場合、グループに参加しているユーザ(以下、グループのメンバと表記)は、当該グループにいつから登録したか、または、どの部署(部課)に所属しているか等にかかわらず、当該グループ内の記事を無制限に閲覧することができる。
【0004】
しかしながら、このようにグループのメンバが無制限に全ての記事を閲覧できることは、企業等における情報セキュリティ上の問題になる場合がある。このような場合には、各記事に対する閲覧(つまり、アクセス)の可否を考慮して、新たにメンバを登録し直した新規のグループを作成するか、または一部のメンバを除名する必要がある。
【先行技術文献】
【特許文献】
【0005】
【特許文献1】特開2006−127126号公報
【発明の概要】
【発明が解決しようとする課題】
【0006】
しかしながら、上記したように新規のグループを作成する場合、各種設定のやり直し(例えば、URLまたはメールアドレスの変更等)が必要であり、当該グループに登録される大多数のメンバに負担を強いることになる。したがって、このような事情から新規のグループの作成は面倒であり、リスクを知りつつもそのまま運用してしまうような場合が多い。
【0007】
一方、上記したようにメンバをグループから除名してしまうと、当該メンバが過去に投稿した記事(つまり、自分が投稿した記事)についてもアクセスできなくなる。また、グループから除名される前に閲覧等をしていた記事(つまり、既に知っている記事)についてもアクセスできなくなる。このような場合には、グループから除名されたメンバの業務に支障がでる場合がある。
【0008】
そこで、本発明が解決しようとする課題は、過去の記事に対する合理的なアクセスを可能にした上で、情報セキュリティを向上させることが可能な情報共有システム、情報共有方法及びプログラムを提供することにある。
【課題を解決するための手段】
【0009】
実施形態によれば、第1のグループに投稿された記事を当該第1のグループに属する複数のユーザ間で共有することができる情報共有システムが提供される。
【0010】
実施形態に係る情報共有システムは、グループ情報格納手段と、ユーザ情報格納手段と、記事入力手段と、記事格納手段と、公開範囲決定手段と、公開範囲格納手段と、アクセス要求入力手段と、アクセス可否決定手段とを具備する。
【0011】
グループ情報格納手段は、前記第1のグループに属するユーザを示すグループ情報を格納する。
【0012】
ユーザ情報格納手段は、前記ユーザが属する第1のグループとは異なる第2のグループを示すユーザ情報を格納する。
【0013】
記事入力手段は、前記第1のグループに属するユーザによって当該第1のグループに投稿された記事を入力する。
【0014】
記事格納手段は、前記入力された記事を格納する。
【0015】
公開範囲決定手段は、前記ユーザ情報格納手段に格納されているユーザ情報及び前記グループ情報格納手段に格納されているグループ情報に基づいて、前記記事格納手段に格納された記事の投稿先である第1のグループに属するユーザが属する第2のグループを、当該記事の公開範囲として決定する。
【0016】
アクセス要求入力手段は、ユーザが前記記事格納手段に格納された記事にアクセスする際に、当該記事に対するアクセス要求を入力する。
【0017】
アクセス可否決定手段は、前記グループ情報格納手段に格納されているグループ情報、前記ユーザ情報格納手段に格納されているユーザ情報及び前記決定された公開範囲に基づいて、前記入力されたアクセス要求の対象となる記事に対する当該アクセス要求の要求元であるユーザのアクセス可否を決定する。
【図面の簡単な説明】
【0018】
【図1】実施形態に係る情報共有システムのハードウェア構成を示すブロック図。
【図2】図1に示す情報共有システム30の主として機能構成を示すブロック図。
【図3】図2に示す格納部22に含まれるグループ情報格納部221のデータ構造の一例を示す図。
【図4】図2に示す格納部22に含まれるユーザ情報格納部222のデータ構造の一例を示す図。
【図5】図2に示す格納部22に含まれる部課情報格納部223のデータ構造の一例を示す図。
【図6】本実施形態に係る情報共有システム30において実行される記事登録処理の処理手順を示すフローチャート。
【図7】記事格納部224に登録される記事について具体的に説明するための図。
【図8】公開範囲格納部225に登録される公開範囲情報について具体的に説明するための図。
【図9】アクセス可否判定方法の中間的選択肢について概念的に示す図。
【図10】第1及び第2のアクセス可否判定方法の中間的選択肢について具体的に説明するための図。
【図11】本実施形態に係る情報共有システム30において実行されるアクセス可否判定処理の処理手順を示すフローチャート。
【図12】第2のアクセス可否決定処理の処理手順を示すフローチャート。
【図13】アクセス可否の決定処理について具体的に説明するための図。
【発明を実施するための形態】
【0019】
以下、図面を参照して、実施形態について説明する。
【0020】
図1は、本実施形態に係る情報共有システムのハードウェア構成を示すブロック図である。図1に示すように、コンピュータ10は、例えばハードディスクドライブ(HDD:Hard Disk Drive)のような外部記憶装置20と接続されている。この外部記憶装置20は、コンピュータ10によって実行されるプログラム21を格納する。コンピュータ10及び外部記憶装置20は、情報共有システム30を構成する。
【0021】
この情報共有システム30によれば、あるグループ(情報共有システム30におけるグループ)に投稿された記事を当該グループに属する複数のユーザ間で共有することができる。なお、図1においては省略されているが、情報共有システム30は、情報共有システム30を利用する複数のユーザの各々によって用いられる複数のユーザ端末と接続されている。
【0022】
ここでは、本実施形態に係る情報共有システム30は、例えば企業内において用いられるものとして説明する。この場合、情報共有システム30を利用するユーザ(以下、単にユーザと表記)には、企業における社員等が含まれる。また、ユーザは、上記した情報共有システム30におけるグループとは別に、異なる観点で分けられたグループ(企業におけるグループ)にも属しているものとする。この企業におけるグループには、当該企業において設置されている部または課等が含まれる。以下、情報共有システム30におけるグループを単にグループと称し、部または課等の企業におけるグループを単に部課と称する。
【0023】
図2は、図1に示す情報共有システム30の主として機能構成を示すブロック図である。図2に示すように、情報共有システム30は、記事投稿部31、記事登録部32、記事内容解析部33、公開範囲決定部34、公開範囲登録部35、記事閲覧・編集部36、記事取得部37、アクセス可否決定部38及びアクセス制御部39を含む。本実施形態において、これらの各部31〜39は、図1に示すコンピュータ10が外部記憶装置20に格納されているプログラム21を実行することにより実現されるものとする。このプログラム21は、コンピュータ読み取り可能な記憶媒体に予め格納して頒布可能である。また、このプログラム21が、例えばネットワークを介してコンピュータ10にダウンロードされても構わない。
【0024】
また、情報共有システム30は、格納部22を含む。本実施形態において、格納部22は、例えば図1に示す外部記憶装置20に格納される。なお、格納部22には、グループ情報格納部221、ユーザ情報格納部222、部課情報格納部223、記事格納部224及び公開範囲格納部225を含む。
【0025】
グループ情報格納部221には、グループ(第1のグループ)毎に、当該グループに属するユーザ(の各々)を示すグループ情報が格納される。
【0026】
ユーザ情報格納部222には、ユーザ毎に、当該ユーザが属する部課(第2のグループ)を示すユーザ情報が格納される。
【0027】
部課情報格納部223には、ユーザが属する部課に関する情報(以下、部課情報と表記)が格納される。
【0028】
記事投稿部31は、例えばユーザ端末に対するユーザの操作に応じて、当該ユーザによって投稿された記事を入力する。記事投稿部31によって入力された記事には、例えば当該記事が投稿されたグループ(以下、投稿先グループと表記)を示す情報等が含まれる。
【0029】
記事登録部32は、記事投稿部31によって入力された記事を記事格納部224に格納する。
【0030】
記事内容解析部33は、記事登録部32によって記事格納部224に格納された記事を、当該記事格納部224から取得する。記事内容解析部33は、記事格納部224から取得された記事を解析する。
【0031】
公開範囲決定部34は、記事内容解析部33による記事の解析結果に基づいて、当該記事に当該記事の公開範囲を意味する情報(例えば、文字列)が含まれているか否かを判定する。
【0032】
公開範囲決定部34は、記事の公開範囲を意味する情報が含まれていると判定された場合、当該記事の投稿先グループに属するユーザの各々が属する部課を、当該記事の公開範囲(アクセス可能範囲)として決定する。
【0033】
公開範囲登録部35は、公開範囲決定部34によって記事の公開範囲として決定された部課を示す公開範囲情報を、当該記事を識別するための記事ID(記事識別情報)に対応づけて公開範囲格納部225に登録(格納)する。
【0034】
記事閲覧・編集部36は、ユーザ端末に対するユーザの操作に応じて、記事格納部224に格納されている記事に対する閲覧または編集等の要求(以下、アクセス要求と表記)を入力する。なお、記事閲覧・編集部36によって入力されたアクセス要求には、当該アクセス要求の対象となる記事を識別するための記事ID(記事識別情報)及び当該アクセス要求の要求元であるユーザを識別するためのユーザID(ユーザ識別情報)が含まれる。
【0035】
記事取得部37は、記事閲覧・編集部36によって入力されたアクセス要求に含まれる記事IDによって識別される記事を、記事格納部224から取得する。
【0036】
アクセス可否決定部38は、グループ情報格納部221に格納されているグループ情報、ユーザ情報格納部222に格納されているユーザ情報、部課情報格納部223に格納されている部課情報、公開範囲格納部225に格納されている公開範囲情報及び記事取得部37によって取得された記事に基づいて、記事閲覧・編集部36によって入力されたアクセス要求に含まれる記事IDによって識別される記事に対する当該アクセス要求に含まれるユーザIDによって識別されるユーザのアクセス可否(つまり、許可または拒否)を決定する。なお、アクセス可否決定部38は、後述する予め定められた複数のアクセス権の引継ぎレベルのうち、設定されているアクセス権の引継ぎレベルに基づいてアクセスの可否を決定する。
【0037】
なお、アクセス可否として許可がアクセス可否決定部38によって決定された場合、アクセス要求に含まれるユーザIDによって識別されるユーザは、例えばユーザ端末を操作することによって、記事取得部37によって取得された記事(つまり、アクセス要求に含まれる記事IDによって識別される記事)に対する閲覧または編集等を行うことができる。一方、アクセス可否として拒否がアクセス可否決定部38によって決定された場合、アクセス要求に含まれるユーザIDによって識別されるユーザは、記事取得部37によって取得された記事に対する閲覧または編集を行うことができない。
【0038】
アクセス制御部39は、情報共有システム30(に含まれる各部31〜38)の処理を制御する機能を有する。
【0039】
図3は、図2に示す格納部22に含まれるグループ情報格納部221のデータ構造の一例を示す。グループ情報格納部221には、上述したようにグループ毎に、当該グループに属するユーザを示すグループ情報が格納される。
【0040】
図3に示すように、グループ情報格納部221に格納されているグループ情報は、グループ名、ユーザID、登録日及び登録停止日(を示す情報)を対応づけて含む。グループ名は、グループ(の名称)を表す。なお、本実施形態では、グループ名はグループを識別するための識別子に相当するものとする。ユーザID(ユーザ名)は、グループ名によって表されるグループに属するユーザを識別するための識別子である。登録日は、グループ名によって示されるグループにユーザIDによって識別されるユーザが登録(参加)した日を示す。登録解除日は、ユーザIDによって識別されるユーザのグループ名によって示されるグループへの登録が解除(停止)された日を示す。
【0041】
図3に示す例では、グループ情報格納部221には、グループ情報221a〜221fを含む複数のグループ情報が格納されている。
【0042】
グループ情報格納部221に格納されているグループ情報221aには、グループ名「製品Xプロジェクト」、ユーザID「A」、登録日「2008−10−01」及び登録解除日「2009−10−01」が対応づけて含まれている。このグループ情報221aによれば、グループ名「製品Xプロジェクト」によって表されるグループには、ユーザID「A」によって識別されるユーザが属しており、当該ユーザは、2008年10月1日に当該グループに登録し、2009年10月1日に当該グループへの登録を解除していることが示されている。
【0043】
また、グループ情報格納部221に格納されているグループ情報221bには、グループ名「製品Xプロジェクト」、ユーザID「B」及び登録日「2008−10−01」が対応づけて含まれている。このグループ情報221bによれば、グループ名「製品Xプロジェクト」によって表されるグループには、ユーザID「B」によって識別されるユーザが属しており、当該ユーザは、2008年10月1日に当該グループに登録したことが示されている。なお、グループ情報221bに含まれる登録解除日(の欄)は空欄(つまり、NULL値)であるが、これは、ユーザID「B」によって識別されるユーザがグループ名「製品Xプロジェクト」によって表されるグループに現在も継続して属していることを示している。
【0044】
ここでは、便宜的にグループ情報221a及び221bについてのみ説明したが、グループ情報221c〜221fを含む他のグループ情報についても同様であるため、その詳しい説明を省略する。
【0045】
グループ情報格納部221(に格納されているグループ情報)は、グループに新たなユーザが登録された場合、またはユーザのグループへの登録が解除された場合等に、適宜更新されるものとする。
【0046】
図4は、図2に示す格納部22に含まれるユーザ情報格納部222のデータ構造の一例を示す。ユーザ情報格納部222には、上述したようにユーザ毎に、当該ユーザが属する部課(所属部課)を示すユーザ情報が格納される。
【0047】
図4に示すように、ユーザ情報格納部222に格納されているユーザ情報は、ユーザID、部課名(所属部課名)、役職(名)、部課登録日及び部課終了日(を示す情報)を対応づけて含む。ユーザIDは、ユーザを識別するための識別子である。部課名は、ユーザIDによって識別されるユーザが属する部課(の名称)を表す。役職は、ユーザIDによって識別されるユーザの部課名によって示される部課(つまり、当該ユーザが属する部課)における役職(例えば、主任、課長または部長等)を示す。部課登録日は、ユーザIDによって識別されるユーザが部課名によって示される部課に登録された日を示す。部課終了日は、ユーザIDによって識別されるユーザの部課名によって示される部課への登録が解消された日(つまり、当該部課から他の部課に移った日)を示す。
【0048】
図4に示す例では、ユーザ情報格納部222には、ユーザ情報222a〜222gを含む複数のユーザ情報が格納されている。
【0049】
ユーザ情報格納部222に格納されているユーザ情報222aには、ユーザID「A」、部課名「第一開発部」、部課登録日「2008−04−01」及び部課終了日「2009−08−31」が対応づけて含まれている。このユーザ情報222aによれば、ユーザID「A」によって識別されるユーザが部課名「第一開発部」によって表される部課に2008年4月1日から2009年8月31日まで所属していたことが示されている。なお、ユーザID「A」によって識別されるユーザに特別な役職がない場合には、ユーザ情報222aのように役職(の欄)は空欄となる。
【0050】
また、ユーザ情報格納部222に格納されているユーザ情報221dには、ユーザID「C」、部課名「第二開発部」、役職「主任」及び部課登録日「2008−04−01」が対応づけて含まれている。このユーザ情報222dによれば、ユーザ「C」によって識別されるユーザが部課名「第二開発部」によって表される部課に2008年4月1日から属しており、当該ユーザの役職が主任であることが示されている。なお、ユーザ情報221dに含まれる部課終了日(の欄)は空欄であるが、これは、ユーザID「C」によって識別されるユーザが部課名「第二開発部」によって表される部課に現在も継続して属していることを示している。
【0051】
ここでは、便宜的にユーザ情報222a及び222dについてのみ説明したが、ユーザ情報222b、222c、222e〜222gを含む他のグループ情報についても同様であるため、その詳しい説明を省略する。
【0052】
ユーザ情報格納部221(に格納されているユーザ情報)は、ユーザが属する部課に変更が合った場合等に、適宜更新されるものとする。なお、ユーザ情報222d及び222fに示すように、ユーザが属する部課(つまり、部課名)が同じ場合であっても役職が変わった場合には異なるユーザ情報としてユーザ情報格納部222に格納される。
【0053】
図5は、図2に示す格納部22に含まれる部課情報格納部223のデータ構造の一例を示す。部課情報格納部223には、部課毎に、部課情報(当該部課に関する情報)が格納される。
【0054】
図5に示すように、部課情報格納部223に格納されている部課情報は、部課名、設置日、廃止日及び移行先(を示す情報)を対応づけて含む。部課名は、企業内に設置された部課(の名称)を表す。設置日は、部課名によって表される部課が設置された日を示す。廃止日は、部課名によって表される部課が廃止された日を示す。移行先は、部課名によって表される部課の改名または統廃合によって、当該部課が例えば廃止された後にどの部課として扱われるかを表す。
【0055】
図5に示す例では、部課情報格納部223には、部課情報223a〜223dを含む複数の部課情報が格納されている。
【0056】
部課情報格納部223に格納されている部課情報223aには、部課名「第一開発部」及び設置日「2006−04−01」が対応づけて含まれている。この部課情報223aによれば、部課名「第一開発部」によって表される部課が2006年4月1日に設置されたことが示されている。なお、部課名「第一開発部」によって表される部課が現在も存続している場合には、部課情報223aのように廃止日及び移行先(の欄)は空欄となる。
【0057】
また、部課情報格納部223に格納されている部課情報223bには、部課名「商品企画部」、設置日「2005−04−01」、廃止日「2006−03−31」及び移行先「第一商品企画部」が対応づけて含まれている。この部課情報223bによれば、部課名「第一商品企画部」によって表される部課が2005年4月1日に設置され、2006年3月31に廃止され、当該廃止後は第一商品企画部として扱われる(つまり、第一商品企画部に移行した)ことが示されている。
【0058】
ここでは、便宜的に部課情報223a及び223bについてのみ説明したが、部課情報223c及び223dを含む他の部課情報についても同様であるため、その詳しい説明を省略する。
【0059】
ここで、本実施形態に係る情報共有システム30の動作について説明する。情報共有システム30においては、ユーザによって投稿された記事を登録する際の処理(以下、記事登録処理と表記)及びユーザからのアクセス要求に応じて当該ユーザからのアクセス可否を判定する処理(以下、アクセス可否判定処理と表記)が実行される。以下、これらの各処理について説明する。
【0060】
まず、図6のフローチャートを参照して、本実施形態に係る情報共有システム30において実行される記事登録処理の処理手順について説明する。
【0061】
なお、記事登録処理は、情報共有システム30と接続されているユーザ端末(を用いるユーザ)から記事が投稿された場合に実行される。
【0062】
この場合、記事投稿部31は、ユーザ端末に対するユーザの操作に応じて、当該ユーザによって投稿された記事(以下、投稿記事と表記)を当該ユーザ端末から入力(受信)する(ステップS1)。記事投稿部31によって入力された投稿記事には、当該投稿記事が投稿された記事の投稿先グループを示す情報(例えば、投稿先グループ名)及び当該投稿記事を投稿したユーザを示す情報(例えば、投稿者ID)等が含まれる。なお、記事投稿部31は、入力された投稿記事を例えばアクセス制御部39を介して記事登録部32に渡す。
【0063】
記事登録部32は、記事投稿部31から渡された投稿記事を、記事格納部224に登録する(ステップS3)。このとき、記事登録部32は、記事投稿部31から渡された投稿記事を投稿したユーザが当該投稿記事の投稿先グループに属している場合にのみ、当該投稿記事を記事格納部224に登録する。つまり、投稿記事を投稿したユーザが当該投稿記事の投稿先グループに属していない場合には、当該投稿が拒否され、当該投稿記事は記事格納部224には登録されない。このように投稿記事が登録されない場合には、記事登録処理は終了される。なお、このようなステップS3の処理は、グループ情報格納部221に格納されているグループ情報、投稿記事に含まれる当該投稿記事の投稿先グループを示す情報及び投稿記事を投稿したユーザを示す情報に基づいて実行される。
【0064】
ここで、図7を参照して、記事格納部224に登録される記事について具体的に説明する。図7は、記事格納部224のデータ構造の一例を示す。記事格納部224には、ユーザによって投稿された記事が格納される。
【0065】
図7に示すように、記事格納部224に格納されている記事は、記事ID、投稿先グループ名、親記事ID、投稿日、投稿者、タイトル、本文及び添付資料(を示す情報)を対応づけて含む。
【0066】
記事IDは、記事を識別するための識別子である。投稿先グループ名は、記事IDによって識別される記事の投稿先グループ(の名称)を表す。投稿日は、記事IDによって識別される記事が投稿された日(記事格納部224に登録された日)を示す。投稿者IDは、記事IDによって識別される記事を投稿したユーザ(投稿者)を識別するための識別子(ユーザID)である。タイトルは、記事IDによって識別される記事のタイトルである。本文は、記事IDによって識別される記事の本文である。添付資料は、記事IDによって識別される記事に添付された添付資料(添付ファイル)である。
【0067】
なお、記事格納部224に格納されている記事に含まれる上記した各種情報のうち、投稿先グループ名、投稿日、投稿者ID、タイトル、本文及び添付資料は、記事投稿部31によって入力された記事に既に含まれている情報である。一方、記事に含まれる各種情報のうち、記事IDは、記事格納部224に投稿記事が登録される際に記事登録部32によって当該記事に付加される情報である。
【0068】
図7に示す例では、記事格納部224には、記事224a〜224iを含む複数の記事が格納(登録)されている。
【0069】
記事格納部224に格納されている記事224aには、記事ID「1001」、投稿先グループ名「製品Xプロジェクト」、投稿日「2009−01−10」、投稿者ID「B」、タイトル「タイトル1」及び本文「本文1」が対応づけて含まれている。この記事224aによれば、記事ID「1001」によって識別される記事が投稿先グループ「製品Xプロジェクト」に対してユーザ「B」によって2009年1月10日に投稿されたことが示されている。なお、投稿先グループ「製品Xプロジェクト」は投稿先グループ「製品Xプロジェクト」によって表されるグループであり、ユーザ「B」は投稿者ID「B」によって識別されるユーザであるものとする。他の場合においても同様であるものとする。また、記事224aによれば、記事ID「1001」によって識別される記事のタイトルが「タイトル1」であり、当該記事の本文が「本文1」であることが示されている。なお、記事ID「1001」によって識別される記事に添付資料が存在しない場合には、記事224aに示すように添付資料(の欄)は空欄となる。
【0070】
また、記事格納部224に格納されている記事224dには、記事ID「1004」、投稿先グループ名「製品Xプロジェクト」、投稿日「2009−02−10」、投稿者ID「B」、タイトル「タイトル4」、本文「本文4」及び添付資料「稟議書」が対応づけて含まれている。この記事224dによれば、記事ID「1004」によって識別される記事が投稿先グループ「製品Xプロジェクト」に対してユーザ「B」によって2009年2月10日に投稿されたことが示されている。また、記事ID「1004」によって識別される記事のタイトルが「タイトル4」であり、当該記事の本文が「本文4」であり、当該記事の添付資料が「稟議書」であることが示されている。
【0071】
ここでは、便宜的に記事224a及び224dについてのみ説明したが、記事224b、224c及び224e〜224iを含む他の記事についても同様であるため、その詳しい説明を省略する。
【0072】
再び図6に戻ると、記事内容解析部33は、記事登録部32によって記事格納部224に登録された投稿記事を、当該記事格納部224から取得する。記事内容解析部33は、取得された投稿記事を解析する(ステップS3)。この記事内容解析部33によって取得された投稿記事には、上記した図7において説明した各種情報が含まれている。記事内容解析部33は、投稿記事の解析結果を公開範囲決定部34に渡す。
【0073】
公開範囲決定部34は、記事内容解析部33から渡された投稿記事の解析結果を参照して、投稿記事に当該投稿記事の公開範囲を意味する情報(例えば、公開範囲を示す識別子等)が含まれているか否かを判定する。これにより、公開範囲決定部34は、投稿記事の公開範囲の指定があるか否かを判定する(ステップS4)。つまり、公開範囲決定部34は、投稿記事を記事格納部224に登録する際に、当該投稿記事の内容から公開範囲の設定の有無を判定する。
【0074】
なお、この判定アルゴリズムには、例えばレイアウト情報解析及び文字列マッチ等を利用することができる。具体的には、投稿記事の冒頭に例えば「(秘)」等の文字列が含まれている場合、または例えば投稿記事に添付された文書ファイル(添付資料)のフッダ情報等に「部外秘」等の文字列が含まれている場合には、投稿記事の公開範囲の指定があると判定される。
【0075】
投稿記事の公開範囲の指定があると判定された場合(ステップS4のYES)、公開範囲決定部34は、投稿記事に含まれる投稿先グループ名によって表されるグループ(投稿先グループ)に属するユーザ(以下、投稿先グループのメンバと表記)を特定する(ステップS5)。具体的には、公開範囲決定部34は、グループ情報格納部221に格納されているグループ情報に基づいて、投稿記事に含まれる投稿先グループ名(つまり、グループ名)に対応づけて当該グループ情報に含まれているユーザID(によって識別されるユーザ)を投稿先グループのメンバとして特定する。
【0076】
次に、公開範囲決定部34は、特定された投稿先グループのメンバを包含する最小の部課集合を特定する(ステップS6)。具体的には、公開範囲決定部34は、ユーザ情報格納部222に格納されているユーザ情報に基づいて、ステップS5において特定されたユーザIDに対応づけて当該ユーザ情報に含まれている部課名(つまり、投稿先グループのメンバが属する部課)の集合を、当該投稿先グループのメンバを包含する最小の部課集合として特定する。
【0077】
公開範囲決定部34は、ステップS6において特定された部課名(の集合)を、投稿記事の公開範囲として決定する(ステップS7)。このように、公開範囲決定部34は、投稿先グループのメンバの所属部課から公開範囲を判定する。
【0078】
なお、公開範囲決定部34は、投稿記事の公開範囲として決定された部課名を含む公開範囲情報を生成する。
【0079】
公開範囲登録部35は、公開範囲決定部34によって生成された公開範囲情報を、公開範囲格納部225に登録(格納)する(ステップS8)。ステップS8の処理が実行されると、記事登録処理は終了される。
【0080】
ここで、図8を参照して、公開範囲格納部225に登録される公開範囲情報について具体的に説明する。図8は、公開範囲格納部225のデータ構造の一例を示す。公開範囲格納部225には、記事(投稿記事)を識別するための記事IDに対応づけて当該記事の公開範囲を示す公開範囲情報が格納される。
【0081】
図8に示すように、公開範囲格納部225に格納されている公開範囲情報は、上記したように登録日及び部課名(を示す情報)を対応づけて含む。投稿日は、対応づけられている記事IDによって識別される記事が投稿された日(記事格納部224に登録された日)を示す。なお、この投稿日は、対応づけられている記事IDによって識別される記事に含まれる投稿日と同一である。部課名は、記事IDによって識別される記事の公開範囲として公開範囲決定部34によって決定された部課名である。
【0082】
図8に示す例では、公開範囲格納部225には、公開範囲情報225a〜225eを含む複数の公開範囲情報が格納(登録)されている。
【0083】
記事ID「1004」に対応づけて公開範囲格納部225に格納されている公開範囲情報225aには、投稿日「2009−02−10」及び部課名「第一開発部」が対応づけて含まれている。この公開範囲情報225aによれば、記事ID「1004」によって識別される記事が投稿された日が2009年2月10日であり、当該記事の公開範囲が部課「第一開発部」(に属するユーザ)であることが示されている。
【0084】
また、記事ID「1007」に対応づけて公開範囲格納部225に格納されている公開範囲情報225eには、投稿日「2009−10−10」及び部課名「第一営業部」が対応づけて含まれている。この公開範囲情報225eによれば、記事ID「1007」によって識別される記事が投稿された日が2009年10月10日であり、当該記事の公開範囲が部課「第一営業部」(に属するユーザ)であることが示されている。
【0085】
ここでは、便宜的に公開範囲情報225a及び225eについてのみ説明したが、公開範囲情報225b〜225dを含む他の公開範囲情報についても同様であるため、その詳しい説明を省略する。
【0086】
なお、図8に示す公開範囲情報225a〜225cは、記事ID「1004」によって識別される記事の公開範囲を示す。また、図8に示す公開範囲情報225d及び225eは、記事ID「1007」によって識別される記事の公開範囲を示す。
【0087】
再び図6に戻ると、ステップS4において投稿記事の公開範囲の指定がないと判定された場合、公開範囲決定部34は、投稿記事の公開範囲を全てとする(ステップS9)。この場合、投稿記事の公開範囲として全てを示す公開範囲情報が公開範囲決定部34によって生成され、上述したステップS8の処理が実行される。
【0088】
このように記事登録処理によれば、ユーザによって記事が投稿される度に、当該投稿された記事(投稿記事)が記事格納部224に登録され、更に、当該投稿記事の公開範囲を示す公開範囲情報が公開範囲格納部225に登録される。
【0089】
次に、本実施形態に係る情報共有システム30において実行されるアクセス可否判定処理について説明する。上述したようにアクセス可否判定処理においては、ユーザからのアクセス要求に応じて当該ユーザからのアクセス可否が判定される。
【0090】
このアクセス可否判定処理において行われるアクセス可否の判定については、複数の方法(以下、アクセス可否判定方法と表記)がある。例えばグループに対して記事が投稿されるようなシステムにおいては、一般的に、「どのグループに投稿された記事であっても誰でもアクセス可能」、「どのグループに投稿された記事であってもシステムを利用するユーザであればアクセス可能」及び「グループに投稿された記事は当該グループに登録されているメンバ(ユーザ)であればアクセス可能」等が考えられる。
【0091】
本実施形態に係る情報共有システム30においては、アクセス可否判定方法として「グループに投稿された記事は当該グループに登録されているメンバであればアクセス可能」が適用されるものとする。
【0092】
ここで、「グループに投稿された記事は当該グループに登録されているメンバであればアクセス可能」である場合に、グループに過去に登録されていたメンバに対して適用されるアクセス可否判定方法としては、例えば「グループへの登録が解除された後であっても、当該グループに登録されていた(つまり、属していた)期間内に投稿された記事であればアクセス可能」及び「グループへの登録が解除された後は、全ての記事についてアクセスできない」等が更に考えられる。
【0093】
本実施形態においては、この「グループへの登録が解除された後であっても、当該グループに登録されていた期間内に投稿された記事であればアクセス可能」及び「グループへの登録が解除された後は、全ての記事についてアクセスできない」の2つのアクセス可否判定方法のうち情報共有システム30の例えば管理者によって設定されたいずれか一方のアクセス可否判定方法がグループに過去に登録されたメンバに対して適用されるものとする。
【0094】
一方、「グループに投稿された記事は当該グループに登録されているメンバであればアクセス可能」である場合に、グループに現在登録されている(つまり、当該グループに現在属している)メンバに対して適用されるアクセス可否判定方法としては、例えば「グループへの登録期間に関係なく当該グループに投稿された記事であればアクセス可能(つまり、全ての期間の記事にアクセス可能)」及び「当該グループに登録されている期間内に投稿された記事であればアクセス可能(つまり、グループの登録期間内の記事のみアクセス可能)」等が更に考えられる。
【0095】
本実施形態においては、図9に示すように、この「グループへの登録期間(登録日)に関係なく当該グループに投稿された記事であればアクセス可能」及び「当該グループに登録されている期間内に投稿された記事であればアクセス可能」の2つのアクセス可否判定方法の中間的選択肢が情報共有システム30の利用者(例えば、管理者等)に対して与えられる。なお、図9に示すように、「グループへの登録期間に関係なく当該グループに投稿された記事であればアクセス可能」というアクセス可否判定方法は、この場合における最も易しいアクセス可否判定方法である。一方、「当該グループに登録されている期間内に投稿された記事であればアクセス可能」というアクセス可否判定方法は、この場合における最も厳しいアクセス可否判定方法である。
【0096】
以下、便宜的に、「グループへの登録期間に関係なく当該グループに投稿された記事であればアクセス可能」というアクセス可否判定方法を第1のアクセス可否判定方法、「当該グループに登録されている期間内に投稿された記事であればアクセス可能」というアクセス可否判定方法を第2のアクセス可否判定方法と称する。
【0097】
以下、図10を参照して、上記した第1及び第2のアクセス可否判定方法の中間的選択肢について具体的に説明する。
【0098】
図10は、例えばユーザA〜Cがあるグループに登録されている期間(ユーザA〜Cのグループ登録期間)を示す。図10に示す例では、ユーザAのグループ登録期間は、t1〜t2の期間である。また、ユーザBのグループ登録期間は、t3〜t4の期間である。また、ユーザCのグループ登録期間は、t5〜現在までの期間である。ここでは現在グループに登録されているユーザCが当該グループに投稿された記事にアクセスする場合を想定している。なお、ユーザA〜Cは、例えば部課Mに属しているものとする。
【0099】
ここで、第1及び第2のアクセス可否判定方法の中間的選択肢として、記事に対するユーザのアクセス可否を判定するための複数のアクセス権の引継ぎレベルが予め用意されているものとする。この複数のアクセス権の引継ぎレベルの各々は、例えば当該引継ぎレベルに応じたアクセス可能な記事の範囲を表す。ここでは、複数のアクセス権の引継ぎレベルには、第1〜第6の引継ぎレベルが含まれるものとする。
【0100】
第1の引継ぎレベルは、「全ての期間の記事をアクセス可能」であるものとする。図10に示す例において第1の引継ぎレベルが適用された場合には、ユーザCは、t0から現在までの全ての期間においてグループに投稿された記事に対してアクセスすることができる。この第1の引継ぎレベルは、上述した図9に示す最も易しいアクセス可否判定方法に相当する。
【0101】
第2の引継ぎレベルは、「部課M(ユーザCが属する部課)のユーザが最初に登録された時からアクセス可能」であるものとする。ここで、部課Mのユーザであってグループに最初に登録されたユーザは、ユーザAである。したがって、図10に示す例において第2の引継ぎレベルが適用された場合には、ユーザCは、部課Mに所属しているユーザAがグループに登録されたt1から現在までの期間においてグループに投稿された記事に対してアクセスすることができる。
【0102】
第3の引継ぎレベルは、「部課M(ユーザCが属する部課)のユーザが登録されている期間のみアクセス可能」であるものとする。図10に示す例において第3の引継ぎレベルが適用された場合には、ユーザCは、部課Mに所属しているユーザA〜Cがグループに登録されているt1からt2までの期間、t3からt4までの期間及びt5から現在までの期間においてグループに投稿された記事に対してアクセスすることができる。
【0103】
第4の引継ぎレベルは、「基本的に第3の引継ぎレベルと同様であるが、役職(ユーザCの部課Mにおける役職)が一定以上(例えば、課長以上)であれば第2の引継ぎレベルとする」であるものとする。つまり、第4の引継ぎレベルが適用される場合には、ユーザCの役職が一定以上でなければ第3の引継ぎレベルが適用された場合と同様になり、ユーザCの役職が一定以上であれば第2の引継ぎレベルが適用された場合と同様になる。
【0104】
第5の引継ぎレベルは、「N人前までの部課M(ユーザCが属する部課)のユーザが登録されている期間のみアクセス可能」である。ここで、N=1であるものとすると、部課Mに属するユーザのうち、ユーザCの1人前はユーザBである。この場合において、図10に示す例において第5の引継ぎレベルが適用された場合には、ユーザCは、ユーザBがグループに登録されているt3からt4までの期間及び当該ユーザCがグループに登録されているt5から現在までの期間においてグループに投稿された記事に対してアクセスすることができる。
【0105】
第6の引継ぎレベルは、「登録されている期間のみアクセス可能」であるものとする。図10に示す例において第6の引継ぎレベルが適用された場合には、ユーザCは、当該ユーザCがグループに登録されているt5から現在までの期間においてグループに投稿された記事に対してアクセスすることができる。この第6の引継ぎレベルは、上述した図9に示す最も厳しいアクセス可否判定方法に相当する。
【0106】
なお、情報共有システム30の例えば管理者は、当該情報共有システム30において上記した第1〜第6の引継ぎレベルのいずれか(所望の引継ぎレベル)を予め設定することができる。
【0107】
ここで、図11のフローチャートを参照して、本実施形態に係る情報共有システム30において実行されるアクセス可否判定処理の処理手順について説明する。アクセス可否判定処理は、上記した第1〜第6の引継ぎレベルのいずれが設定されている場合であっても、ここで説明する処理手順で統一的に実行されることができる。
【0108】
まず、記事閲覧・編集部36は、ユーザ端末に対するユーザの操作に応じて、記事格納部224に格納されている記事に対するアクセス要求を入力(受信)する(ステップS11)。このアクセス要求には、当該アクセス要求の対象となる記事を識別するための記事ID及び当該アクセス要求の要求元であるユーザを識別するためのユーザIDが含まれる。記事閲覧・編集部36は、入力されたアクセス要求を例えばアクセス制御部39を介して記事取得部37に渡す。
【0109】
記事取得部37は、記事閲覧・編集部36から渡されたアクセス要求に含まれる記事IDによって識別される記事、つまり、当該記事IDを含む記事(以下、アクセス対象記事と表記)を、記事格納部224から取得する(ステップS12)。記事取得部37は、取得されたアクセス対象記事及びアクセス要求をアクセス可否決定部38に渡す。
【0110】
次に、アクセス可否決定部38は、グループ情報格納部221を参照して、アクセス要求に含まれるユーザIDによって識別されるユーザ(以下、アクセスユーザと表記)が当該アクセス要求に含まれる記事IDによって識別される記事(つまり、アクセス対象記事)の投稿先グループのメンバである(つまり、投稿先グループに属している)か否かを判定する(ステップS13)。
【0111】
ここで、記事取得部37から渡されたアクセス対象記事に含まれる投稿先グループ名及びアクセス要求に含まれるユーザIDを対応づけて含むグループ情報を該当グループ情報と称するものとすると、このステップS13においては、登録解除日が空欄である(つまり、登録が解除されていない)該当グループ情報がグループ情報格納部221内に存在する場合に、アクセスユーザが投稿先グループのメンバであると判定される。一方、登録解除日が空欄である該当グループ情報がグループ情報格納部221内に存在しない場合に、アクセスユーザが投稿先グループのメンバでないと判定される。
【0112】
アクセスユーザが投稿先グループのメンバでないと判定された場合(ステップS13のNO)、アクセス可否決定部38は、グループ情報格納部221を参照して、アクセスユーザが投稿先グループの過去のメンバであるか否かを判定する(ステップS14)。
【0113】
このステップS14においては、登録解除日が空欄でない(つまり、以前投稿先グループのメンバであったが登録が解除されている)該当グループ情報がグループ情報格納部221内に存在する場合に、アクセスユーザが投稿先グループの過去のメンバであると判定される。一方、登録解除日が空欄でない該当グループ情報がグループ情報格納部221内に存在しない場合に、アクセスユーザが投稿先グループの過去のメンバでないと判定される。
【0114】
アクセスユーザが投稿先グループの過去のメンバであると判定された場合(ステップS14のYES)、アクセス可否決定部38は、当該アクセスユーザが投稿先グループのメンバであった期間(該当期間)内にアクセス対象記事が投稿された(つまり、アクセス対象記事が該当期間内の記事である)か否かを判定する(ステップS15)。
【0115】
このステップS15においては、アクセス対象記事に含まれる投稿日が該当グループ情報に含まれる登録日から登録解除日までの期間(つまり、登録期間)内である場合に、該当期間内に当該アクセス対象記事が投稿されたと判定される。一方、アクセス対象記事に含まれる投稿日が該当グループ情報に含まれる登録日から登録解除日までの期間内でない場合に、該当期間内に当該アクセス対象記事が投稿されていないと判定される。
【0116】
該当期間内にアクセス対象記事が投稿されたと判定された場合(ステップS15のYES)、アクセス可否決定部38は、アクセス対象記事(アクセス要求に含まれる記事IDによって識別される記事)に対するアクセスユーザ(当該アクセス要求に含まれるユーザIDによって識別されるユーザ)のアクセス可否(許可または拒否)を決定する処理(以下、第1のアクセス可否決定処理と表記)を実行する(ステップS16)。
【0117】
この第1のアクセス可否決定処理は、情報共有システム30の管理者によって設定された、グループに過去に登録されていたメンバに対して適用されるアクセス可否判定方法に基づいて実行される。ここで、上述したようにグループに過去に登録されていたメンバに対して適用されるアクセス可否判定方法には、「グループへの登録が解除された後であっても、当該グループに登録されていた期間内に投稿された記事であればアクセス可能」及び「グループへの登録が解除された後は、全ての記事についてアクセスできない」がある。
【0118】
この場合において、情報共有システム30の管理者によって「グループへの登録が解除された後であっても、当該グループに登録されていた期間内に投稿された記事であればアクセス可能」が設定されている場合、第1のアクセス可否決定処理においては、アクセス対象記事に対するアクセスユーザのアクセス可否として許可が決定される。
【0119】
一方、情報共有システム30の管理者によって「グループへの登録が解除された後は、全ての記事についてアクセスできない」が設定されている場合、第1のアクセス可否決定処理においては、アクセス対象記事に対するアクセスユーザのアクセス可否として拒否が決定される。
【0120】
ステップS16の処理が実行されると、第1のアクセス可否決定処理において決定されたアクセス可否(許可または拒否)が出力される(ステップS17)。ここで、アクセス可否として許可が出力された場合には、アクセスユーザは、アクセス対象記事に対してアクセス(例えば、閲覧または編集等)することができる。一方、アクセス可否として拒否が出力された場合には、アクセスユーザは、アクセス対象記事に対してアクセスすることができない。
【0121】
なお、上記したステップS14においてアクセスユーザが投稿先グループの過去のメンバでないと判定された場合、またはステップS15において該当期間内にアクセス対象記事が投稿されていないと判定された場合、ステップS17の処理が実行される。ここでは、アクセス可否として拒否が出力される。
【0122】
一方、上記したステップS13においてアクセスユーザが投稿先グループのメンバであると判定された場合、アクセス可否決定部38は、アクセスユーザが投稿先グループに登録された後にアクセス対象記事が投稿された(つまり、アクセス対象記事が当該登録後の記事である)か否かを判定する(ステップS18)。
【0123】
このステップS18においては、アクセス対象記事に含まれる投稿日が該当グループ情報に含まれる登録日以降である場合に、アクセスユーザが投稿先グループに登録された後にアクセス対象記事が投稿されたと判定される。一方、アクセス対象記事に含まれる投稿日が該当グループ情報に含まれる登録日以降でない(つまり、当該登録日より前である)場合、アクセスユーザが投稿先グループに登録された後にアクセス対象記事が投稿されていないと判定される。
【0124】
アクセスユーザが投稿先グループに登録された後にアクセス対象記事が投稿されていないと判定された場合(ステップS18のNO)、アクセス可否決定部38は、アクセス対象記事(アクセス要求に含まれる記事IDによって識別される記事)に対するアクセスユーザ(アクセス要求に含まれるユーザIDによって識別されるユーザ)のアクセス可否(許可または拒否)を決定する処理(以下、第2のアクセス可否決定処理と表記)を実行する(ステップS19)。第2のアクセス可否決定処理においては、アクセス対象記事を識別するための記事IDに対応づけて公開範囲格納部225に格納されている公開範囲情報に基づいて、例えば当該公開範囲情報に含まれる部課名によって表される部課にアクセスユーザが属する場合、アクセス対象記事に対するアクセスユーザのアクセス可否として許可が決定される。また、第2のアクセス可否決定処理は、上述した第1〜第6の引継ぎレベルのうち情報共有システム30の管理者によって設定された引継ぎレベルに基づいて実行される。この第2のアクセス可否決定処理の詳細については後述する。
【0125】
ステップS19の処理が実行されると、上記したステップS17の処理が実行される。このステップS17においては、第2のアクセス可否決定処理において決定されたアクセス可否が出力される。
【0126】
なお、上記したステップS18においてアクセスユーザが投稿先グループに登録された後にアクセス対象記事が投稿されたと判定された場合、ステップS17の処理が実行される。ここでは、アクセス可否として許可が出力される。
【0127】
次に、図12のフローチャートを参照して、上述した第2のアクセス可否決定処理の処理手順について説明する。この第2のアクセス可否決定処理では、ユーザがグループ内の情報(記事)にアクセスする際、そのユーザが過去に所属してきた部課の履歴と公開範囲を照らし合わせてアクセス可否を判定する。
【0128】
まず、アクセス可否決定部38は、上述した図11に示すステップS1において入力されたアクセス要求に含まれる記事IDに対応づけて公開範囲格納部225に格納されている公開範囲情報を、当該公開範囲格納部225から取得する(ステップS21)。ここで取得される公開範囲情報は、アクセス対象記事(アクセス要求に含まれる記事IDによって識別される記事)の公開範囲を示す。
【0129】
次に、アクセス可否決定部38は、アクセスユーザ(アクセス要求に含まれるユーザIDによって識別されるユーザ)のユーザ情報を、ユーザ情報格納部222から取得する(ステップS22)。この場合、アクセス可否決定部38は、アクセスユーザを識別するためのユーザID(つまり、アクセス要求に含まれるユーザID)を含むユーザ情報を取得する。
【0130】
アクセス可否決定部38は、取得されたユーザ情報及び部課情報格納部223に格納されている部課情報に基づいて、アクセスユーザが属する部課を示す部課名及び当該部課の過去の部課(つまり、アクセスユーザが属する部課に移行する前の部課)を表す部課名(の一覧)を取得する(ステップS23)。この場合、アクセス可否決定部38は、アクセスユーザが属する部課を表す部課名として、ステップS22において取得されたユーザ情報に含まれる部課名を取得する。また、アクセス可否決定部38は、アクセスユーザが属する部課の過去の部課を表す部課名として、アクセスユーザが属する部課を表す部課名を移行先として含む部課情報に含まれる部課名を取得する。なお、アクセスユーザが属する部課の過去の部課に対して更に過去の部課が存在する場合には、同様に当該部課を表す部課名についても取得される。
【0131】
アクセス可否決定部38は、取得された部課名によって表される部課の少なくとも1つに所属している(または所属していた)ユーザであってアクセス対象記事の投稿先グループのメンバであるユーザ(アクセスユーザ以外の他のメンバ)の当該投稿先グループへの登録期間を特定する(ステップS24)。この場合、アクセス可否決定部38は、取得された部課名に対応づけてユーザ情報に含まれるユーザIDを特定し、当該特定されたユーザID及びアクセス対象記事に含まれる投稿先グループ名を含むグループ情報に含まれる登録日から登録解除日までの期間を投稿先グループへの登録期間として特定する。
【0132】
アクセス可否決定部38は、取得された部課名及び当該部課名によって表される部課に所属している(または所属していた)ユーザの投稿先グループへの登録期間を対応づけて含む中間出力情報を生成する(ステップS25)。
【0133】
次に、アクセス可否決定部38は、ステップS21において取得された公開範囲情報及びステップS25において生成された中間出力情報に基づいて、アクセス対象記事に対するアクセスユーザのアクセス可否を決定する(ステップS26)。この場合、アクセス可否決定部38は、上述した第1〜第6の引継ぎレベルのうち情報共有システム30の管理者によって設定された引継ぎレベルに応じてアクセス可否を決定する。なお、アクセス可否として許可が決定されるためには、少なくともアクセスユーザがステップS21において取得された公開範囲情報に含まれる部課名によって表される部課(または当該部課が移行した後の部課)に属している必要がある。換言すれば、記事が登録された当時、その記事にアクセスできたメンバの所属部課にそのユーザが存在していた場合、アクセスを可とする。
【0134】
つまり、アクセス可否決定部38は、公開範囲情報に含まれる部課名及び中間出力情報に含まれる部課名の一致を判定し、当該部課名に対応づけて中間出力情報に含まれる登録期間に対して、アクセス対象記事に含まれる投稿日が管理者によって設定された引継ぎレベル(によって表される範囲)に該当するか否かに応じてアクセス可否を決定する。
【0135】
ここで、図13を参照して、図12に示すステップS26におけるアクセス可否の決定処理について具体的に説明する。
【0136】
ここでは、例えばグループ「製品Xプロジェクト」に登録されている(または登録されていた)ユーザとしてユーザA〜Eが存在するものとする。ユーザAは、第一開発部に属しており、2008年10月2009年10月までグループ「製品Xプロジェクト」に登録されていたものとする。ユーザBは、第二開発部に属しており、2008年10月から現在までグループ「製品Xプロジェクト」に登録しているものとする。ユーザCは、第二開発部に主任として属しており、2008年10月から現在までグループ「製品Xプロジェクト」に登録しているものとする。ユーザDは、2008年10月から2009年4月まで第一営業部に主任として属し、2009年4月から現在まで第一営業部に課長として属しており、2008年10月から現在までグループ「製品Xプロジェクト」に登録しているものとする。また、ユーザEは、第一開発部に属しており、2009年12月から現在までグループ「製品Xプロジェクト」に登録しているものとする。
【0137】
また、図13に示すように、2008年10月から2009年4月までの期間内に記事ID「1004」によって識別される記事が投稿されたものとする。また、2009年10月から2009年12月までの期間内に記事ID「1007」によって識別される記事が投稿されたものとする。ここで、記事ID「1004」によって識別される記事に公開範囲の指定があるものとすると、当該記事ID「1004」によって識別される記事の公開範囲を示す公開範囲情報には、部課名「第一開発部」、「第二開発部」及び「第一営業部」が含まれる。また、記事ID「1007」によって識別される記事に公開範囲の指定あるものとすると、記事ID「1007」によって識別される記事の公開範囲を示す公開範囲情報には、部課名「第二開発部」及び「第一営業部」が含まれる。
【0138】
以下、グループ「製品Xプロジェクト」に現在登録されているユーザEが記事ID「1004」及び記事ID「1007」によって識別される記事に対してアクセスする際のアクセス可否について、上述した第1〜第6の引継ぎレベルの各々が設定されている場合について具体的に説明する。
【0139】
まず、第1の引継ぎレベルが設定されている場合について説明する。第1の引継ぎレベルは、上記したように「全ての期間の記事をアクセス可能」である。この場合、ユーザEは、グループ「製品Xプロジェクト」に投稿された全ての記事に対してアクセス可能である。このため、記事ID「1004」及び記事ID「1007」によって識別される記事に対するユーザEのアクセス可否としては許可が決定される。
【0140】
次に、第2の引継ぎレベルが設定されている場合について説明する。第2の引継ぎレベルは、「部課Mのユーザが最初に登録された時から閲覧可能」である。ここでは、ユーザEが属する部課「第一開発部」が部課Mに相当する。また、部課「第一開発部に属するユーザのうち最初にグループ「製品Xプロジェクト」に登録されたユーザAが当該グループ「製品Xプロジェクト」に登録されたのは2008年10月である。この場合、ユーザEは、2008年10月以降に投稿された記事に対してアクセス可能である。このため、記事ID「1004」及び記事ID「1007」によって識別される記事に対するユーザEのアクセス可否としては許可が決定される。
【0141】
次に、第3の引継ぎレベルが設定されている場合について説明する。第3の引継ぎレベルは、「部課Mのユーザが登録されている期間のみアクセス可能」である。ここでは、ユーザEが属する部課「第一開発部」が部課Mに相当する。また、部課「第一開発部」に属するユーザAがグループ「製品Xプロジェクト」に登録されている期間は2008年10月から2009年10月までである。また、部課「第一開発部」に属するユーザEがグループ「製品Xプロジェクト」に登録されている期間は2009年12月から現在までである。この場合、ユーザEは、2008年10月から2009年10月までの期間内及び2009年12月から現在までの期間内に投稿された記事に対してアクセス可能である。このため、記事ID「1004」によって識別される記事に対するユーザEのアクセス可否としては許可が決定されるが、記事ID「1007」によって識別される記事に対するユーザEのアクセス可否としては拒否が決定される。
【0142】
次に、第4の引継ぎレベルが設定されている場合について説明する。第4の引継ぎレベルは、「基本的に第3の引継ぎレベルと同様であるが、役職が一定以上であれば第2の引継ぎレベルとする」である。ここでは、ユーザEは特別な役職がない。このため、第3の引継ぎレベルが設定されている場合と同様に、記事ID「1004」によって識別される記事に対するユーザEのアクセス可否としては許可が決定されるが、記事ID「1007」によって識別される記事に対するユーザEのアクセス可否としては拒否が決定される。
【0143】
次に、第5の引継ぎレベルが設定されている場合について説明する。第5の引継ぎレベルは、「N人前までの部課Mのユーザが登録されている期間のみアクセス可能」である。ここでは、ユーザEが属する部課「第一開発部」が部課Mに相当する。また、部課「第一開発部」に属するユーザAがグループ「製品Xプロジェクト」に登録されている期間は2008年10月から2009年10月までである。ここで、N=1であるものとすると、部下「第一開発部」に属するユーザのうち、ユーザEの1人前はユーザAである。この場合、ユーザEは、1人前のユーザAがグループ「製品Xプロジェクト」に登録されている2008年10月から2009年10月までの期間内及び当該ユーザEが当該グループ「製品Xプロジェクト」に登録されている2009年12月から現在までの期間内に投稿された記事に対してアクセス可能である。このため、記事ID「1004」によって識別される記事に対するユーザEのアクセス可否としては許可が決定されるが、記事ID「1007」によって識別される記事に対するユーザEのアクセス可否としては拒否が決定される。
【0144】
最後に、第6の引継ぎレベルが設定されている場合について説明する。第6の引継ぎレベルは、「登録されている期間のみアクセス可能」であるものとする。ここでは、ユーザEがグループ「製品Xプロジェクト」に登録されている期間は2009年12月から現在までである。この場合、ユーザEは、2009年12月から現在までの期間内に投稿された記事に対してアクセス可能である。このため、記事ID「1004」及び記事ID「1007」によって識別される記事に対するユーザEのアクセス可否としては拒否が決定される。
【0145】
このように情報共有システム30の管理者によって設定された引継ぎレベルによって、アクセス可否の結果が異なる。
【0146】
上記したように本実施形態においては、情報共有システム30におけるグループ(第1のグループ)に属するユーザによって当該グループに記事が投稿された場合に、当該グループに属するユーザが属する部課(第2のグループ)を当該記事の公開範囲として決定し、当該記事に対するアクセス要求が入力された場合に、当該記事の公開範囲に基づいて、当該記事に対する当該アクセス要求の要求元であるユーザのアクセス可否を決定する構成により、過去の記事に対する合理的なアクセスを可能にした上で、情報セキュリティを向上させることが可能となる。つまり、本実施形態によれば、記事が投稿された時期とその際のコミュニティ(グループ)のメンバの状態から記事の公開範囲の決定(アクセス制御)を自動的に行うことにより、情報共有システム30におけるグループのメンバに新たな作業等を行わせることなく、ユーザの異動または新規登録に関する必要十分なアクセス制御を行うことで、企業等の組織の作業効率を落とすことなく情報セキュリティを高めることができる。
【0147】
なお、本実施形態においては、投稿先グループのメンバの部課名(の集合)を投稿記事の公開範囲として決定するものとして説明したが、当該投稿先グループのメンバの役職を含めて投稿記事の公開範囲としても構わない。これにより、例えば部課「第一開発部」で役職が課長以上のユーザのみが登録できるようなグループ等において投稿された記事に対しては、部課「第一開発部」に属するユーザであっても一担当である(つまり、役職が課長以上でない)場合にはアクセスを拒否する構成とすることができる。
【0148】
また、本実施形態においては、上述した第2のアクセス可否決定処理において必要な情報を取得し、中間出力情報を生成した後にアクセス可否を決定するものとして説明したが、例えば当該第2のアクセス可否決定処理の開始時点で管理者によって設定されている引継ぎレベルを判別した上で当該引継ぎレベルに応じた処理が行われる構成であっても構わない。簡単に説明すると、例えば第1の引継ぎレベルが設定されている場合には、特別な処理を実行することなくアクセス可否として許可を決定すればよい。また、第2〜第4の引継ぎレベルが設定されている場合には、アクセス対象記事を識別するための記事IDに対応づけて公開範囲格納部225に格納されている公開範囲情報に含まれる部課名によって表される部課にアクセスユーザが属しているか否かが判定されればよい。この場合、公開範囲情報に含まれる部課名によって表される部課にアクセスユーザが属している場合にはアクセス可否として許可が決定され、一方、当該部課にアクセスユーザが属していない場合にはアクセス可否として拒否が決定される。なお、第5の引継ぎレベルが設定されている場合には、図12に示す処理と同様の処理が実行されればよい。また、第6の引継ぎレベルが設定されている場合、アクセス対象記事はアクセスユーザがグループへ登録した後に投稿された記事であるため、特別な処理を実行することなくアクセス可否として拒否を決定すればよい。
【0149】
また、本実施形態においては、グループ名によってグループを一意に識別するとして説明したが、実際の運用では例えばメールアドレスまたはグループID等を識別子として用いても構わない。
【0150】
また、本実施形態においては、部課情報格納部223に格納されている部課情報に部(例えば、第一開発部)及びその下位に位置する課(例えば、第一開発部第一課)間の階層関係を示す情報が含まれていても構わない。これにより、例えば公開範囲情報に部課名「第一開発部第一課」が含まれているような場合には、当該部課「第一開発部第一課」の上位に位置する部課「第一開発部」に属するユーザについてもアクセスを許可するというような構成とすることも可能である。
【0151】
また、本実施形態においては、記事格納部224に格納されている記事に親記事IDが含まれていても構わない。この親記事IDは、記事に含まれる記事IDによって識別される記事の親記事を識別するための識別子である。ここで、親記事とは、記事IDによって識別される記事の例えば返信元(または参照元)となる記事であるものとする。この親記事IDが記事に含まれることによって、記事IDによって識別される記事と親記事IDによって識別される記事との間の関係(親子関係)を表すことができる。これにより、例えば公開範囲情報によって示される記事の公開範囲が当該記事の親(または子)記事等にも適用されるような構成とすることも可能である。
【0152】
また、本願発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。
【符号の説明】
【0153】
10…コンピュータ、20…外部記憶装置、22…格納部、30…情報共有システム、31…記事投稿部、32…記事登録部、33…記事内容解析部、34…公開範囲決定部、35…公開範囲登録部、36…記事閲覧・編集部、37…記事取得部、38…アクセス可否決定部、39…アクセス制御部、221…グループ情報格納部、222…ユーザ情報格納部、223…部課情報格納部、224…記事格納部、225…公開範囲格納部。

【特許請求の範囲】
【請求項1】
第1のグループに投稿された記事を当該第1のグループに属する複数のユーザ間で共有することができる情報共有システムにおいて、
前記第1のグループに属するユーザを示すグループ情報を格納するグループ情報格納手段と、
前記ユーザが属する第1のグループとは異なる第2のグループを示すユーザ情報を格納するユーザ情報格納手段と、
前記第1のグループに属するユーザによって当該第1のグループに投稿された記事を入力する記事入力手段と、
前記入力された記事を格納する記事格納手段と、
前記ユーザ情報格納手段に格納されているユーザ情報及び前記グループ情報格納手段に格納されているグループ情報に基づいて、前記記事格納手段に格納された記事の投稿先である第1のグループに属するユーザが属する第2のグループを、当該記事の公開範囲として決定する公開範囲決定手段と、
ユーザが前記記事格納手段に格納された記事にアクセスする際に、当該記事に対するアクセス要求を入力するアクセス要求入力手段と、
前記グループ情報格納手段に格納されているグループ情報、前記ユーザ情報格納手段に格納されているユーザ情報及び前記決定された公開範囲に基づいて、前記入力されたアクセス要求の対象となる記事に対する当該アクセス要求の要求元であるユーザのアクセス可否を決定するアクセス可否決定手段と
を具備する情報共有システム。
【請求項2】
前記公開範囲決定手段は、前記記事格納手段に格納された記事に当該記事の公開範囲を意味する情報が含まれている場合に、前記第1のグループに属するユーザの各々が属する第2のグループを、前記記事格納手段に格納された記事の公開範囲として決定する請求項1記載の情報共有システム。
【請求項3】
記事に対するユーザのアクセス可否を決定するための予め定められた複数のアクセス権の引継ぎレベルのいずれかを設定する設定手段を更に含み、
前記アクセス可否決定手段は、前記設定されたアクセス権の引継ぎレベルに基づいて、前記アクセス要求の対象となる記事に対する当該アクセス要求元であるユーザのアクセス可否を決定する
請求項1記載の情報共有システム。
【請求項4】
前記アクセス可否決定手段は、
前記グループ情報格納手段に格納されているグループ情報に基づいて、前記入力されたアクセス要求の要求元であるユーザが前記第1のグループに属するかを判定する第1の判定手段と、
前記ユーザが前記第1のグループに属する判定された場合、前記ユーザ情報格納手段に格納されたユーザ情報に基づいて、前記入力されたアクセス要求の要求元であるユーザが前記公開範囲として決定された第2のグループに属するかを判定する第2の判定手段と
を含み、
前記公開範囲として決定された第2のグループに属すると判定された場合に、前記入力されたアクセス要求の対象となる記事に対する当該アクセス要求の要求元であるユーザのアクセス可否として許可を決定する
請求項1記載の情報共有システム。
【請求項5】
第1のグループに投稿された記事を当該第1のグループに属する複数のユーザ間で共有する情報共有方法であって、前記第1のグループに属するユーザを示すグループ情報を格納するグループ情報格納手段と前記ユーザが属する第1のグループとは異なる第2のグループを示すユーザ情報を格納するユーザ情報格納手段とを利用する情報共有システムが実行する情報共有方法において、
前記第1のグループに属するユーザによって当該第1のグループに投稿された記事を入力するステップと、
前記入力された記事を記事格納手段に格納するステップと、
前記ユーザ情報格納手段に格納されているユーザ情報及び前記グループ情報格納手段に格納されているグループ情報に基づいて、前記記事格納手段に格納された記事の投稿先である第1のグループに属するユーザが属する第2のグループを、当該記事の公開範囲として決定するステップと、
ユーザが前記記事格納手段に格納された記事にアクセスする際に、当該記事に対するアクセス要求を入力するステップと、
前記グループ情報格納手段に格納されているグループ情報、前記ユーザ情報格納手段に格納されているユーザ情報及び前記決定された公開範囲に基づいて、前記入力されたアクセス要求の対象となる記事に対する当該アクセス要求の要求元であるユーザのアクセス可否を決定するステップと
を具備する情報共有方法。
【請求項6】
第1のグループに属するユーザを示すグループ情報を格納するグループ情報格納手段と前記ユーザが属する第1のグループとは異なる第2のグループを示すユーザ情報を格納するユーザ情報格納手段と記事格納手段とを有する外部記憶装置と、当該外部記憶装置を利用するコンピュータとから構成される、前記第1のグループに投稿された記事を当該第1のグループに属する複数のユーザ間で共有することができる情報共有システムにおいて、前記コンピュータによって実行されるプログラムであって、
前記コンピュータに、
前記第1のグループに属するユーザによって当該第1のグループに投稿された記事を入力するステップと、
前記入力された記事を前記記事格納手段に格納するステップと、
前記ユーザ情報格納手段に格納されているユーザ情報及び前記グループ情報格納手段に格納されているグループ情報に基づいて、前記記事格納手段に格納された記事の投稿先である第1のグループに属するユーザが属する第2のグループを、当該記事の公開範囲として決定するステップと、
ユーザが前記記事格納手段に格納された記事にアクセスする際に、当該記事に対するアクセス要求を入力するステップと、
前記グループ情報格納手段に格納されているグループ情報、前記ユーザ情報格納手段に格納されているユーザ情報及び前記決定された公開範囲に基づいて、前記入力されたアクセス要求の対象となる記事に対する当該アクセス要求の要求元であるユーザのアクセス可否を決定するステップと
を実行させるためのプログラム。

【図1】
image rotate

【図2】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate

【図7】
image rotate

【図8】
image rotate

【図9】
image rotate

【図10】
image rotate

【図11】
image rotate

【図12】
image rotate

【図13】
image rotate


【公開番号】特開2012−160104(P2012−160104A)
【公開日】平成24年8月23日(2012.8.23)
【国際特許分類】
【出願番号】特願2011−20504(P2011−20504)
【出願日】平成23年2月2日(2011.2.2)
【出願人】(000003078)株式会社東芝 (54,554)
【出願人】(301063496)東芝ソリューション株式会社 (1,478)
【Fターム(参考)】