特開 2024-97304 グループデータ管理方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024097304

(43)【公開日】2024-07-18

(54)【発明の名称】グループデータ管理方法

(51)【国際特許分類】

   G06Q 50/10 20120101AFI20240710BHJP

【ＦＩ】

G06Q50/10

【審査請求】有

【請求項の数】10

【出願形態】ＯＬ

【外国語出願】

(21)【出願番号】P 2023222077

(22)【出願日】2023-12-28

(31)【優先権主張番号】111150492

(32)【優先日】2022-12-28

(33)【優先権主張国・地域又は機関】TW

(71)【出願人】

【識別番号】524002935

【氏名又は名称】李揚

(74)【代理人】

【識別番号】110001519

【氏名又は名称】弁理士法人太陽国際特許事務所

(72)【発明者】

【氏名】李揚

(57)【要約】

【課題】コストをできるだけかけずに取引できるグループデータ管理方法を提供する。
【解決手段】サーバは第２のユーザー端末からグループ加入リクエストと第２のユーザー情報を受信し、サーバはグループ加入リクエストに応答して、第２のユーザー情報を第１のグループリストに追加し、サーバは第２のユーザー端末からグループ脱退リクエストを受信し、サーバを経てグループ脱退リクエストを第１のユーザー端末に提供し、サーバは第１のユーザー端末から脱退同意情報を受信し、サーバは脱退同意情報に応答して、サーバは脱退同意情報に応答して、第１のグループリストから第２のユーザー情報を取り除く。
【選択図】図２

【特許請求の範囲】

【請求項1】

サーバに適用され、前記サーバは第１のユーザー端末と第２のユーザー端末に接続するのに適するグループデータ管理方法であって、
前記サーバは前記第１のユーザー端末から第１のグループ設立リクエストと第１のユーザー情報を受信し、前記サーバは前記第１のグループ設立リクエストに応答して第１のグループリストを生成し、前記第１のグループリストは前記第１のユーザー情報を含み、
前記サーバは前記第２のユーザー端末からグループ加入リクエストと第２のユーザー情報を受信し、前記サーバは前記グループ加入リクエストに応答して、前記第２のユーザー情報を前記第１のグループリストに追加し、
前記サーバは前記第２のユーザー端末からグループ脱退リクエストを受信し、前記サーバを経て前記グループ脱退リクエストを前記第１のユーザー端末に提供し、
前記サーバは前記第１のユーザー端末から脱退同意情報を受信し、前記サーバは前記脱退同意情報に応答して、前記サーバは前記脱退同意情報に応答して、前記第１のグループリストから前記第２のユーザー情報を取り除く
ことを特徴とするグループデータ管理方法。

【請求項2】

前記サーバは前記第２のユーザー端末から第２のグループ設立リクエストと前記第２のユーザー情報を受信し、前記サーバは前記第２のグループ設立リクエストに応答して、第２のグループリストを生成し、前記第２のグループリストは前記第２のユーザー情報を含み、
前記サーバは前記第２のユーザー端末からグループ統合リクエストを受信し、前記サーバは前記グループ統合リクエストに応答して、前記第２のグループリストに含まれる情報を前記第１のグループリストに追加する
ことを特徴とする請求項１に記載のグループデータ管理方法。

【請求項3】

前記サーバは前記グループ統合リクエストに応答して、前記第２のグループリストに含まれる情報を前記第１のグループリストに追加するステップの後、前記サーバは前記第２のグループリストを削除することを更に含む
ことを特徴とする請求項２に記載のグループデータ管理方法。

【請求項4】

前記サーバは前記第１のユーザー端末から前記脱退同意情報を受信するステップの後、前記サーバは前記第１のグループリストから前記第２のグループリストに含まれる情報を取り除くことを更に含む
ことを特徴とする請求項２に記載のグループデータ管理方法。

【請求項5】

前記サーバは前記第１のグループ設立リクエストに応答して、前記第１のグループリストを生成するステップの前に、前記サーバは前記第１のユーザー端末から数量目標と第１の順位条件目標を受信し、
前記サーバは前記第２のグループ設立リクエストに応答して、前記第２のグループリストを生成するステップの前に、前記サーバは前記第２のユーザー端末から条件情報を受信し、
前記サーバは前記第２のユーザー端末から前記グループ統合リクエストを受信するステップの後、前記サーバは前記第１の順位条件目標に前記条件情報が含まれ且つ前記第１のグループリストに含まれる人数が前記数量目標に達していないと判断したとき、前記サーバは前記グループ統合リクエストに応答して、前記第２のグループリストに含まれる情報を前記第１のグループリストに追加する
ことを特徴とする請求項２に記載のグループデータ管理方法。

【請求項6】

前記サーバは前記第１のユーザー端末から第２の順位条件目標とデフォルトマージ時間を受信し、
前記サーバは前記第２のユーザー端末から前記グループ統合リクエストを受信するステップの後、前記サーバは前記デフォルトマージ時間に達し、前記第２の順位条件目標に条件情報が含まれ、且つ、前記第１のグループリストに含まれる人数が数量目標にまだ達していないと判断したとき、前記サーバは前記グループ統合リクエストに応答して、前記第２のグループリストに含まれる情報を前記第１のグループリストに追加する
ことを特徴とする請求項２に記載のグループデータ管理方法。

【請求項7】

前記サーバは前記第２のユーザー端末から前記グループ統合リクエストを受信するステップの後、前記サーバはデフォルトマージ時間にまだ達していないと判断したとき、前記サーバは前記グループ統合リクエストに応答しない
ことを特徴とする請求項６に記載のグループデータ管理方法。

【請求項8】

前記サーバは前記第２のユーザー端末から第２のグループ設立リクエストと前記第２のユーザー情報を受信し、
前記サーバは前記第２のグループ設立リクエストに応答して、第２のグループリストを生成し、前記第２のグループリストには前記第２のユーザー情報が含まれ、
前記サーバは前記第２のユーザー端末からグループ統合リクエストを受信し、前記サーバは前記グループ統合リクエストに応答して、第３のグループリストを生成し、前記第３のグループリストには前記第１のグループリストに含まれる情報と、前記第２のグループリストに含まれる情報が含まれる
ことを特徴とする請求項１に記載のグループデータ管理方法。

【請求項9】

前記サーバは前記グループ統合リクエストに応答し、前記第３のグループリストのステップの後、前記サーバは前記第２のグループリストを削除する
ことを特徴とする請求項８に記載のグループデータ管理方法。

【請求項10】

前記サーバは前記第１のユーザー端末から前記脱退同意情報を受信するステップの後、前記サーバは前記第３のグループリストから前記第２のグループリストに含まれる情報を取り除く
ことをとする請求項８に記載のグループデータ管理方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明はグループデータ管理方法に関し、特に、コミュニティデータのグループデータ管理方法に関する。

【背景技術】

【0002】

従来の電子商取引では、ソース供給やベンダー供給等の種々のビジネスモデルが使用されていた。

【0003】

ここで、ソース供給モデルでは、プラットフォームが統一された方法で消費者の注文を受け取り、台湾のPChomeやアマゾン(Amazon、登録商標)のショッピングウェブサイト等の単一の販売者が商品を集中的に発送する。

【0004】

また、ベンダー供給モデルでは、プラットフォームが消費者の注文を統一して受け取り、個々の販売者が商品を個別に出荷する。このプラットフォームは、シンガポールのShopeeショッピングやeBay（登録商標）ウェブサイト等の物流ステータスのみを管理する。

【0005】

近年、コミュニティソフトウェアプラットフォームの進歩により、ベンダー供給モデルにおいて、新たなコミュニティ注文モデルが徐々に発展してきている。

【0006】

コミュニティ注文モデルでは、コミュニティソフトウェアプラットフォームは、消費者が買い物をする行動に介入しない。

【0007】

そして、このモデルでは、消費者はコミュニティソフトウェアを使用して、同じショッピングのニーズを有する他の複数の消費者を招集し、1つ以上の特定のオペレーターからグループ購入を行う。

【発明の概要】

【発明が解決しようとする課題】

【0008】

新型コロナが流行し始めてから、緊急事態宣言による外出自粛や、遠隔地における物流チェーンが滞ったことにより、消費者がコミュニティ注文モデルにコミュニティソフトウェアプラットフォームを使用する傾向が更に高くなっている。

【0009】

たとえば、同じコミュニティ内で、グループ購入リーダーがコミュニティプラットフォーム(Line（登録商標）やFacebook（登録商標）プラットフォーム等)上で複数のコミュニティメンバー向けのチャットグループを開設する。

【0010】

リーダーはチャットグループでそれを宣伝し、同じ買い物のニーズを持つコミュニティメンバーを招集し、特定の加盟店に注文してもらい、その後、リーダーが商品を受け取り、地域のメンバーに配布する。

【0011】

しかし、現在のコミュニティ注文モデルにはプラットフォーム管理が十分とは言えない。つまり、コミュニティ注文モデルの運営を行うには、メンバー同士が地理的に近い位置に住み、且つグループ購入リーダーとコミュニティメンバー間に信頼関係が有ることが前提となる。

【0012】

一方、取引紛争が発生した場合、コミュニティメンバーは、グループ購入リーダーに解決を求めるか、地域コミュニティ管理委員会を利用することができる。

【0013】

しかし、コミュニティ注文モデルの事業規模が複数の地域に拡大した場合には、メンバー間が地理的に離れてしまうことにより生ずる信頼関係の欠如が発生しかねない。また、コミュニティソフトウェアの匿名性等により消費者間で紛争が発生した場合、一方の取引の当事者がコミュニティメンバーから脱退すると、他方の当事者が解決策を見つけることが困難となってしまう。

【0014】

一方、グループショッピングでは通常、加盟店の送料や割引目標を達成するために一定数以上の取引・売買が必要となる。また、取引の相手が決まらない場合、又は十分な人数がいない場合にはコミュニティを行うグループ自体が崩壊し、取引が失敗する可能性すらあり得る。

【課題を解決するための手段】

【0015】

本発明は上述した問題を解決するために以下の構成を備える。即ち、
サーバに適用され、前記サーバは第１のユーザー端末と第２のユーザー端末に接続するのに適するグループデータ管理方法であって、
前記サーバは前記第１のユーザー端末から第１のグループ設立リクエストと第１のユーザー情報を受信し、前記サーバは前記第１のグループ設立リクエストに応答して第１のグループリストを生成し、前記第１のグループリストは前記第１のユーザー情報を含み、
前記サーバは前記第２のユーザー端末からグループ加入リクエストと第２のユーザー情報を受信し、前記サーバは前記グループ加入リクエストに応答して、前記第２のユーザー情報を前記第１のグループリストに追加し、
前記サーバは前記第２のユーザー端末からグループ脱退リクエストを受信し、前記サーバを経て前記グループ脱退リクエストを前記第１のユーザー端末に提供し、
前記サーバは前記第１のユーザー端末から脱退同意情報を受信し、前記サーバは前記脱退同意情報に応答して、前記サーバは前記脱退同意情報に応答して、前記第１のグループリストから前記第２のユーザー情報を取り除く
ことを特徴とするグループデータ管理方法。

【0016】

また、前記サーバは前記第２のユーザー端末から第２のグループ設立リクエストと前記第２のユーザー情報を受信し、前記サーバは前記第２のグループ設立リクエストに応答して、第２のグループリストを生成し、前記第２のグループリストは前記第２のユーザー情報を含み、
前記サーバは前記第２のユーザー端末からグループ統合リクエストを受信し、前記サーバは前記グループ統合リクエストに応答して、前記第２のグループリストに含まれる情報を前記第１のグループリストに追加する
ことを特徴とする請求項１に記載のグループデータ管理方法。

【0017】

また、前記サーバは前記グループ統合リクエストに応答して、前記第２のグループリストに含まれる情報を前記第１のグループリストに追加するステップの後、前記サーバは前記第２のグループリストを削除することを更に含む
ことを特徴とする請求項２に記載のグループデータ管理方法。

【0018】

また、前記サーバは前記第１のユーザー端末から前記脱退同意情報を受信するステップの後、前記サーバは前記第１のグループリストから前記第２のグループリストに含まれる情報を取り除くことを更に含む
ことを特徴とする請求項２に記載のグループデータ管理方法。

【0019】

また、前記サーバは前記第１のグループ設立リクエストに応答して、前記第１のグループリストを生成するステップの前に、前記サーバは前記第１のユーザー端末から数量目標と第１の順位条件目標を受信し、
前記サーバは前記第２のグループ設立リクエストに応答して、前記第２のグループリストを生成するステップの前に、前記サーバは前記第２のユーザー端末から条件情報を受信し、
前記サーバは前記第２のユーザー端末から前記グループ統合リクエストを受信するステップの後、前記サーバは前記第１の順位条件目標に前記条件情報が含まれ且つ前記第１のグループリストに含まれる人数が前記数量目標に達していないと判断したとき、前記サーバは前記グループ統合リクエストに応答して、前記第２のグループリストに含まれる情報を前記第１のグループリストに追加する
ことを特徴とする請求項２に記載のグループデータ管理方法。

【0020】

また、前記サーバは前記第１のユーザー端末から第２の順位条件目標とデフォルトマージ時間を受信し、
前記サーバは前記第２のユーザー端末から前記グループ統合リクエストを受信するステップの後、前記サーバは前記デフォルトマージ時間に達し、前記第２の順位条件目標に前記条件情報が含まれ、且つ、前記第１のグループリストに含まれる人数が前記数量目標にまだ達していないと判断したとき、前記サーバは前記グループ統合リクエストに応答して、前記第２のグループリストに含まれる情報を前記第１のグループリストに追加する

【0021】

ことを特徴とする請求項２に記載のグループデータ管理方法。

【0022】

また、前記サーバは前記第２のユーザー端末から前記グループ統合リクエストを受信するステップの後、前記サーバはデフォルトマージ時間にまだ達していないと判断したとき、前記サーバは前記グループ統合リクエストに応答しない
ことを特徴とする請求項６に記載のグループデータ管理方法。

【0023】

また、前記サーバは前記第２のユーザー端末から第２のグループ設立リクエストと前記第２のユーザー情報を受信し、
前記サーバは前記第２のグループ設立リクエストに応答して、第２のグループリストを生成し、前記第２のグループリストには前記第２のユーザー情報が含まれ、
前記サーバは前記第２のユーザー端末からグループ統合リクエストを受信し、前記サーバは前記グループ統合リクエストに応答して、第３のグループリストを生成し、前記第３のグループリストには前記第１のグループリストに含まれる情報と、前記第２のグループリストに含まれる情報が含まれる
ことを特徴とする請求項１に記載のグループデータ管理方法。

【0024】

また、前記サーバは前記グループ統合リクエストに応答し、前記第３のグループリストのステップの後、前記サーバは前記第２のグループリストを削除する
ことを特徴とする請求項８に記載のグループデータ管理方法。

【0025】

また、前記サーバは前記第１のユーザー端末から前記脱退同意情報を受信するステップの後、前記サーバは前記第３のグループリストから前記第２のグループリストに含まれる情報を取り除く
ことをとする請求項８に記載のグループデータ管理方法。

【発明の効果】

【0026】

本発明によれば、第２のグループは第１のグループを統合し、共に共同購入目標を達成するので、仮に、物流コストが第１の順位条件目標よりも高くなってしまう場合でも、尚もコストを抑えることができる余地がある。

【図面の簡単な説明】

【0027】

【図1】本発明の実施形態によって示されるグループデータ管理方法を実現するためのシステムのブロック図である。

【図2】本実施形態によって示されるグループデータ管理方法のフローチャートである。

【図3】本発明の他の実施形態によって示されるグループデータ管理方法のフローチャートである。

【発明を実施するための形態】

【0028】

先ず、図１を参照して説明する。ここで、図１は本発明の実施形態によって示されるグループデータ管理方法を実現するためのシステムのブロック図である。

【0029】

本実施形態に示すように、グループデータ管理システム１は、サーバ１１、データストレージモジュール１２、第１のユーザー端末２１、第２のユーザー端末２２、第３のユーザー端末２３、第４のユーザー端末２４を含む。

【0030】

データストレージモジュール１２は、サーバ１１に接続されており、サーバ１１は、ネットワーク１１０を介して、第１のユーザー端末２１、第２のユーザー端末２２、第３のユーザー端末２３、及び第４のユーザー端末２４とそれぞれ接続されている。

【0031】

ここで、ネットワーク１１０は、インターネット、３Ｇネットワーク、無線ローカルエリアネットワーク(WLAN)等の有線又は無線の通信ネットワークの少なくともいずれかを利用しても良い。

【0032】

第１のユーザー端末２１、第２のユーザー端末２２、第３のユーザー端末２３、及び第４のユーザー端末２４は、それぞれ入力モジュール２１１、２２１、２３１、２４１と、ディスプレイモジュール２１２、２２２、２３２、２４２、及び通信モジュール２１３、２２３、２３３、２４３を含む。

【0033】

サーバ１１は、１つ以上の図示しないプロセッサと、プロセッサに接続された図示しないメモリとを含む。メモリにはプロセッサが実行できるコマンドが含まれており、プロセッサがコマンドを実行するとき、プロセッサは、本実施形態の１つ又は複数の実施形態で説明されるグループデータ管理方法を実行することができる。

【0034】

プロセッサは、SoCチップ、中央処理装置(CPU)、マイクロ制御装置(Micro-Control Unit, MCU)、特定用途向け集積回路(Application Specific Integrated Circuit, ASIC)、又は、フィールドプログラマブルロジックゲートアレイ(Field Programmable Gate Array, FPGA)、又は論理回路である。

【0035】

また、メモリにはフラッシュメモリ(flash memory)又は読み取り専用メモリ(Read-only memory, ROM)を使用できる。

【0036】

例えば、これに限定されないが、消去可能なプログラマブル読み取り専用メモリ(Erasable Programmable Read-Only Memory, EPROM)、フラッシュ読み取り専用メモリ(Flash Read-Only Memory, Flash ROM)、電気的に消去可能なプログラマブル読み取り専用メモリ(Electrically-Erasable Programmable Read-Only Memory, EEPROM)、又は現場交換可能ユニット(Field-Replaceable Unit, FRU) EEPROMでも差し支えない。

【0037】

データストレージモジュール１２は、電気的、磁気的、又は光学的手段を使用して情報を記憶する装置であり得る。たとえば、ハードディスク、ランダムアクセスメモリ(RAM)、読み取り専用メモリ(ROM)、光ディスク、フロッピー（登録商標）ディスク、磁気テープ等が挙げられるが、これらに限定さるものではない。

【0038】

データストレージモジュール１２は、サーバ１１によって制御され、少なくとも１つ以上のユーザーに関連するユーザー情報、グループリスト、又は取引情報を記憶する。

【0039】

ユーザー情報には、ユーザーの名前、アカウントナンバー、パスワード、画像、性別、住所、取引履歴、取引対象等の情報のうち１つ又は複数が含まれても良い。

【0040】

グループリストには、管理者のユーザー情報、グループメンバーのユーザー情報、グループ情報が含まれても良い。

【0041】

グループ情報には、グループ名、所属地域(行政区情報、地理的位置情報、カスタム範囲等)、取引対象カテゴリ（オーディオ取引、宝石取引、日用品等）、会員数、「いいね」が押された数、シェア数、コメント数、情報（コメント）内容、閲覧数、閲覧時間等のうちの１つ以上が含まれても良い。

【0042】

取引情報には、ユーザーの対話中に生成される画像、テキスト、音声、ビデオ、及び取引対象に関する情報が含まれる。

【0043】

たとえば、名前、材質、仕様、サイズ、重量、容量、数量、色、梱包、容量、出荷エリア、配送エリア、出荷エリアと配送エリア間の距離、出荷時間、配送時間、取引メモ等であるが、これらに限定されない。

【0044】

本実施形態では、前記取引は金銭取引に限定されるものではなく、作品の共有等の目的を持ったコミュニケーション活動を指す場合もある。

【0045】

第１のユーザー端末２１～第４のユーザー端末２４は、ポータブルデバイス又はハンドヘルドデバイスであり、例えば、スマートフォン、タブレットＰＣ、携帯電話、ノートブックコンピュータ、カーコンピュータ、パーソナルデジタルアシスタント（ＰＤＡ）等の電子計算装置であるが、これらに限定されない。

【0046】

第１のユーザー端末２１～第４のユーザー端末２４は、それぞれ通信モジュール２１３、２２３、２３３、２４３を含み、ネットワークデータパケットを送受信する

【0047】

通信モジュール２１３、２２３、２３３、２４３は、１つ以上の通信プロトコルをサポートすることができる。

【0048】

通信プロトコルは、以下の物には限られないが、例えば、グローバル移動通信(Global System for Mobile communication, GSM（登録商標）)、パーソナル携帯電話システム(Personal Handy-phone System, PHS，登録商標)、コード多重取得(Code Division Multiple Access, CDMA，登録商標)システム、ブロードバンドコード分割多元接続(Wideband Code Division Multiple Access, WCDMA（登録商標）)システム、ロング・ターム・エボリューション(Long Term Evolution, LTE，登録商標)システム、グローバル相互運用性マイクロ波アクセス(Worldwide interoperability for Microwave Access, WiMAX，登録商標)システム、ワイファイ(Wireless Fidelity, Wi-Fi，登録商標)、ジグビー(ZigBee（登録商標）)、ブルートゥース（登録商標）（Bluetooth（登録商標））、無線周波数であっても良い。

【0049】

ユーザー端末は、通信モジュール２１３、２２３、２３３、２４３を使用してネットワーク１１０から情報を受信し、そして、表示モジュール２１２、２２２、２３２、２４２を使用して、ユーザーに情報を提示する。

【0050】

入力モジュール２１１、２２１、２３１、２４１は、ユーザーによって提供された情報を受信するために使用され、通信モジュール２１３、２２３、２３３、２４３は、ネットワーク１１０を介してサーバ１１に情報を送信するために使用される。

【0051】

入力モジュール２１１、２２１、２３１、２４１は、ユーザーからのデータ入力又は操作指示等の入力を受信するために使用されるタッチスクリーン、トラックパッド、マウス、キーボード、マイク、カメラ等から選択される少なくとも１つのコンポーネントであり得る。ここで、入力データはテキスト、画像、或いは音声等のうち少なくとも何れかであっても良い。

【0052】

本実施形態におけるサーバ１１は、グループデータ管理方法を実行して、通信、ビデオ、ライブブロードキャスト、チャット、ビデオ、売買、友人、ゲーム、及びドキュメントオペレーティングシステム等のコミュニティプラットフォームを確立する。

【0053】

また、コミュニティプラットフォームの場合、メンバー（ファン、メンバー、共同購入メンバー等）を集めるのは簡単ではなく、運営はコミュニティマネージャーのマーケティングと管理のみに依存する。また、コミュニティ間の交流も容易ではなく、直接的な情報発信も難しい。

【0054】

このため、コミュニティへの加入(子コミュニティは親コミュニティのサブセットとなり、子コミュニティは破棄される)又は合併(サブコミュニティと親コミュニティが一体化し、サブコミュニティと親コミュニティが共存する)を通じて、コミュニティのメンバーは特定の目標共に達成でき、且つコミュニティの規模を急速に拡大することもできる。

【0055】

更に、複数のコミュニティを統合して新たなコミュニティを形成することも可能であり、コミュニティでのコミュニケーションの際に生じる取引紛争や社会的な紛争を回避するための一元管理が可能である。以下の実施形態は、グループデータ管理方法を利用して、コミュニティ注文モデルを備えた取引プラットフォームを例として確立する。

【0056】

現在のコミュニティ注文モデルの取引は、主にLineやFacebook（登録商標）等のコミュニティプラットフォームを利用して取引対象の閲覧やコミュニケーションを行っているが、取引を行う際には、価格の混乱、決済の安全性、取引対象が虚偽である等の取引上の問題がある。

【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】

本実施形態では、返信される情報は、第１のグループの付属コミュニティとなる第２のグループに関連する情報を含む。たとえば、第２のグループは、2023年１月１日に第１のグループの付属コミュニティとなる。

【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】

したがって、第２のグループは第１のグループを統合して、共同で共同購入目標を達成する。

【0124】

サーバ１１は、第１の順位条件目標に条件情報が含まれていないと判定した場合（ステップＳ２０４、判定結果が「Ｎｏ」である）、デフォルトマージ時間に達したか否かを判定する（ステップＳ２０６）。

【0125】

ここで、デフォルトマージ時間とは、予め設定された時刻を指し、絶対時間（例：2023年2月1日午後0時0分）、又は相対時間（例：第１のグループの設立からジャスト1か月後等）であり得る。

【0126】

本実施形態では、デフォルトマージ時間は、ユーザーが設定することも、プラットフォームによって自動的に生成することもできる。

【0127】

本実施形態において、デフォルトマージ時間は、取引終了時刻が決定される前の時刻を指す。たとえば、入札終了日が2023年2月1日の午後０時０分の場合には、デフォルトマージ時間は1か月前の入札終了日、つまり2023年1月1日の午後０時０分にできる。

【0128】

サーバ１１が、デフォルトマージ時間に達していないと判定した場合（ステップＳ２０６、判定結果が「Ｎｏ」である）、第２のグループの条件情報が第１のグループが設定した条件目標を満たしていないため、サーバ１１は以下のように動作する。

【0129】

サーバ１１は、ユーザー端末からグループ統合リクエストを受信し続け（ステップＳ２０１）、第１のグループと統合する条件を満たす他のグループを探索する。

【0130】

サーバ１１は、デフォルトマージ時間に達したと判定した場合（ステップＳ２０６、判定結果が「Ｙｅｓ」である）、サーバ１１は、第１のユーザーが設定した第２の順位条件目標に第２のユーザーが設定した条件情報が含まれるか否かを判定する（ステップＳ２０７）。

【0131】

たとえば、第１のユーザーが設定した第１の順位条件目標は、台北市の消費者であり、第２の順位条件目標は桃園市と宜蘭市の消費者であり、第２のユーザーが設定した条件情報は宜蘭市で商品を受け取ることである。このため、第１の順位条件目標には条件情報が含まれないが、第２の順位条件目標には条件情報が含まれる。

【0132】

ここで、第２の順位条件目標は、第１のグループを設立するとき、ユーザーにより第１の順位条件目標と第２の順位条件目標とを同時に設定することができ、サーバ１１にアップロードされる。

【0133】

あるいは、サーバ１１が、デフォルトマージ時間に達したと判定した場合（ステップＳ２０６、判定結果が「Ｙｅｓ」である）、サーバ１１が第２の順位目標を発送して、第の１ユーザー端末２１に設定するようにリクエストし、第１のユーザー端末２１から第２の順位条件目標の設定を受け付けても良い。

【0134】

サーバ１１が第１のユーザーが設定した第２の順位条件目標に第２ユーザーが設定した条件情報が含まれていないと判定した場合（ステップＳ２０７、判定結果が「Ｎｏ」である）、サーバ１１はユーザー端末からグループ統合リクエストを受信し続け（ステップＳ２０１）、第１のグループと統合する条件目標を満たす他のグループを探す。

【0135】

サーバ１１は第１のユーザーが設定した第２の順位条件目標に第２のユーザーが設定した条件情報を含むと判定した場合（ステップＳ２０７、判定結果が「Ｙｅｓ」である）、サーバ１１は第２のグループリストに含まれる情報を第１のグループリスト（第１のグループリスト）に追加する（ステップＳ２０５）。

【0136】

したがって、第２のグループは第１のグループを統合し、共に共同購入目標を達成する。

【0137】

本実施形態の取引活動では、宜蘭市にある第２のグループ（第２の順位条件目標）に物品を輸送する物流コストは、台北市に輸送する物流コスト（第１の順位条件目標）よりも高くなってしまうものの、取引フローから導き出される取引コストと比較すると、尚もコストを抑えることができる余地がある。

【0138】

このように、本実施形態におけるグループデータ管理方法は、グループ統合をすることにより取引コストを効果的に削減できる。

【0139】

なお、本実施形態で示したフローチャートの各ステップは、必ずしも例示した順番に実行する必要はなく、例えば、ステップＳ２０２、ステップＳ２０３をステップＳ２０４の最後に移すことも可能である。

【0140】

本実施形態では、サーバ１１はグループデータ管理方法の実行中（例えば、ステップＳ１０８の後）、デフォルト脱退時間に達したか否かを判定する。

【0141】

ここで、デフォルト脱退時間とは、事前に設定された時刻を指し、絶対的な時刻(たとえば、2023/2/1の午後0時0分)にすることもでき、相対的な時刻(たとえば、第１のグループが確立されてからジャスト1か月後)を指定することもできる。

【0142】

デフォルト脱退時間は、ユーザーが設定しても良く、プラットフォームが自動的に生成するようにしても良い。

【0143】

図２を参照して説明する。ステップＳ１０８の後、サーバ１１がデフォルト脱退時間に達したと判断した場合、サーバ１１はステップＳ１１１を直接実行する。

【0144】

サーバ１１は、デフォルト脱退時間に達していないと判断した場合、ステップＳ１０９～Ｓ１１０を実行する。

【0145】

換言すると、デフォルト脱退時間は、第１のグループに加入した第２のユーザー、又は第１のグループに統合された第２のグループが自らの意思でグループを脱退できる時間分割点である。

【0146】

デフォルト脱退時間が来る前に、第２のユーザー(第２のグループ)がグループを離れる行為は制限されている。

【0147】

デフォルト脱退時間に達した後、第２のユーザー(第２のグループ)は自由にグループを脱退することができる。これにより、プラットフォームメカニズムを利用して取引の安定性を提供できる。

【0148】

本実施形態では、デフォルト脱退時間は、ステップＳ１０１～Ｓ１０２で、第１のグループを作成するときに、第１のユーザーによって設定される。

【0149】

他の実施形態では、デフォルト脱退時間は、ステップＳ１０３～Ｓ１０４で、第１のグループに参加するときに第２のユーザーによって設定される。

【0150】

ここで、サーバ１１は、第２のユーザー端末２２が送信したデフォルト脱退時間の設定情報を受信し、第１のユーザー端末２１にデフォルト脱退時間の設定情報を提供する。

【0151】

サーバ１１は、第１のユーザー端末２１が発送したデフォルト脱退時間の合意情報を受信した後、第１のグループに対して第２ユーザーのデフォルト脱退時間を設定する。

【0152】

たとえば、第２のユーザーが共同購入グループに参加するとき、第１のグループにデフォルト脱退時間を設定するようリクエストし、デフォルト脱退時間に達すると、自由にグループを脱退できる。

【0153】

本実施形態では、デフォルト脱退時間は、特定のイベントが発生する時刻を指す。たとえば、第２のユーザーがライブブロードキャストグループに加入した後、ライブブロードキャストが終了した後に自由にグループから脱退することができる。

【0154】

本発明については上記の実施形態を通じて説明したが、これらの実施形態は、特許請求の範囲を実施形態の範囲に限定する趣旨ではない。また、当業者であれば、本件の趣旨と範囲を逸脱することなく、若干の変更や修正を行うことができるが、そのような変更を行ったものも、本願の技術的範囲に属するものとする。また、本願の技術的範囲は特許請求の範囲に基づいて定められる。

【符号の説明】

【0155】

１ グループデータ管理システム
１１ サーバ
１１０ ネットワーク
１２ データストレージモジュール
２１ 第１のユーザー端末
２１１ 入力モジュール
２１２ ディスプレイモジュール
２１３ 通信モジュール
２２ 第２のユーザー端末
２２１ 入力モジュール
２２２ ディスプレイモジュール
２２３ 通信モジュール
２３ 第３のユーザー端末
２３１ 入力モジュール
２３２ ディスプレイモジュール
２３３ 通信モジュール
２４ 第４のユーザー端末
２４１ 入力モジュール
２４２ ディスプレイモジュール
２４３ 通信モジュール
Ｓ１０１～Ｓ１１１ ステップ
Ｓ２０１～Ｓ２０７ ステップ

【図1】

【図2】

【図3】

【外国語明細書】