Patent Application
20080052203
Methods, systems, user interfaces, and other aspects of the invention are described. Reference will be made to certain embodiments of the invention, examples of which are illustrated in the accompanying drawings. While the invention will be described in conjunction with the embodiments, it will be understood that it is not intended to limit the invention to such embodiments. On the contrary, the invention is intended to cover alternatives, modifications and equivalents that are within the spirit and scope of the invention. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.
Moreover, in the following description, numerous specific details are set forth to provide a thorough understanding of the present invention. However, it will be apparent to one of ordinary skill in the art that the invention may be practiced without these particular details. In other instances, methods, procedures, components, and networks that are well known to those of ordinary skill in the art are not described in detail to avoid obscuring aspects of the present invention.
Some other examples of community networks or groups are illustrated in
Similarly,
For convenience of explanation, the following terms are used herein to describe community networks and group hierarchy:
According to certain embodiments, the online environment (website) is hosted by a service provider, and allows various types of groups to create their own Group Domain within the website in order to organize and manage the group's activities, communications, and payments. The embodiments are applicable for use by various types of groups, including online and offline community networks, clubs, professional organizations, schools, churches, community groups, and so on. The embodiments can be customized to fit the needs and identities of the particular types of groups or organizations.
According to certain embodiments, the online environment for creating community networks may include the following tools and features:
There are a number of ways that the embodiments can be offered to end users and groups as a service. An embodiment can be hosted and offered by a service provider that has developed the embodiments, for example. The developer of the embodiments may sell or license the embodiments to one or more solution providers that may host and offer the service to groups. As another example, a vendor with rights to the embodiments may offer the service to groups but utilize a third party service provider to host and provide support for the service. For purposes of explanation, the term “service provider” is used to indicate an entity that owns the rights to some of the embodiments and that offers the associated service to groups with or without the assistance of a third party for hosting and support services. The term “service” relates to the service being offered by the service provider that is utilizing an embodiment, and is used interchangeably with the term “embodiment”. Also, the term “online environment” is used interchangeably with the term “embodiment.”
The embodiments support group hierarchy, inheritance of group attributes, membership and identity, payment handling and group financial tools, customization tools for the Group Domains, revenue splitting with participating groups, and user support for multiple group membership with consolidated dashboard views via a single online portal. Further, the embodiments support a number of methods for improved group fund-raising solutions, support building mutually beneficial relationships between groups and local merchants, and support ways for groups and a website owner to collaborate on the filtering and approval of online advertisements and promotions. An abstract diagram of the landscape of certain embodiments is shown in
According to one aspect of certain embodiments, groups in a Group Domain are able to establish their own identity, behavior, and appearance of the Group Domain within the online environment. According to another aspect of certain embodiments, customization is possible to enable the group to control: 1) the manner in which content is published within the online environment, 2) policies for member and content management, 3) processes and tools for group and user support, 4) the look-and-feel for the group calendar, and so on.
According to yet another aspect, the online environment for creating community networks allows sub-groups to inherit or leverage the identity, attributes, membership, and support mechanisms that are created by a parent group. Thus, the online environment enables a rapid and secure way for a sub-group to establish itself within a Group Domain.
According to certain embodiments, an individual user does not need to create a new identity or membership within each separate Group Domain. Instead, the user can view or act in any Group Domain in the online environment as long as the user is a member of the particular Group Domain in which he wishes to act or view. In other words, the user can use a single identity or login information in order to access an aggregated or consolidated view of multiple Group Domains of which the user is a member. The benefits and time savings of such a feature are significant. For purposes of illustration, assume that a parent has two children active in the following school groups: the local elementary school, 1st grade classroom, 2nd grade classroom, band, 2nd grade drama, 2nd grade field trips (for which the parent volunteers to help), 1st grade parent assistants, and a school soccer team. It would be useful for the parent to login to an online environment that provides an aggregated calendar that displays all of the relevant events, associated with the above school groups, occurring within the next day, week, or month. Also, a family is likely to be involved in groups outside of the school domain, such as a youth soccer league, community service organizations such as Kiwanis or Rotary International, and other ad-hoc community groups such as a town parade committee. The aggregation of events, news and other communications from these various groups to an individualized, consolidated view are possible, according to certain embodiments. When an individual(s) or member(s) has an aggregated view of activities for multiple groups, and has the ability to register and make any required payments for the activities, increased efficiency is realized by the member(s) and groups alike.
Further, according to another aspect of certain embodiments, groups and sub-groups can set-up activities, request payments, collect and track payments, and generate transaction and payment request summary reports using the online environment.
Fund-raising is an active area for many groups. For purposes of illustration, assume that, in a co-sales fund-raising effort, the groups are the “foot soldiers” that sell and/or promote one or more advertising and marketing products offered by the online environment to merchants in order to reap a share of the sales revenue transacting between merchants and the online environment. In other cases, groups explore a win-win-win relationship with local merchants, where the group members purchase services or goods from the merchant who has agreed to give a certain percentage of the revenue back to the group. In this case the online environment facilitates the marketing of the reward sharing being offered by the merchant. The online environment also facilitates the transfer of revenues from the merchant to the participating groups. This is a win for the group that receives the fund-raising revenue, a win for the merchant as an opportunity to market itself and expand its customer base, and also a win for the members who are supporting a “well-intended” merchant and their group simultaneously. Thus, the online environment facilitates the win-win-win relationship between groups, the groups' members, and local merchants, and dramatically reduces the effort required of the participants. Such embodiments assist the fund-raising needs of a group, help a merchant market to and expand its customer base, and create strong relationships in the local community. A revenue sharing relationship between the online environment provider and the groups, where the marketing and advertising revenues are shared, will greatly enhance the win-win relationship.
The embodiments support the hierarchy, roles, policies, and relationships that occur in most group instances. The hierarchy and group member roles in certain embodiments are illustrated in
The sample roles illustrated in
Each Group Domain usually has at least one member designated as the manager. For purposes of explanation, the terms “Group Domain Manager” or “Administrator” are used to refer to one or more members designated as the Manager at the Group Domain level. Such a member usually has the broadest privileges within the group for managing the Group Domain. Such privileges include defining the attributes that can be inherited by sub-groups, removal of members and filtering and approving supporting merchants and advertisements within the Group Domain, according to certain embodiments. However, the Group Domain's manager's privileges may vary from one sub-group to another and do not automatically include privileges for editing content within sub-groups, for example. According to certain embodiments, membership in sub-groups is defaulted to a subset of the parent group's membership. However, any member of a Group Domain can be added to the membership of an arbitrary sub-group. Each sub-group layer usually has at least one editor and may have a manager who functions as the group-level coordinator. The manager determines membership for the group, manages group administration, etc. Members may be removed at the discretion of the manager. For example, members may be removed for violating policies instituted by the online environment and/or those instituted by the Group Domain.
Support for hierarchy and inheritance in certain embodiments enable the rapid creation of sub-groups from a parent group, and/or the expansion of a Group Domain by adding and linking a new parent group to an existing sub-group. Apart from being a quicker way to establish or expand a group's domain, support for hierarchy and inheritance also enables a flexible adoption model for certain embodiments. The service associated with an embodiment can be tested, adopted, and customized at an arbitrary point in the group hierarchy. Additional parent or sub-groups can then adopt the service, create a linkage to existing group(s) in the domain, and inherit from the membership pools, identities, payment service tools, support tools, merchant relationships, advertisement filtering, member types and roles, email exploders, and other shared tools and services that have already been created in the online environment of an embodiment. The benefit for the service provider offering the service of an embodiment is the rapid rates of adoption and deeper penetration with a given Group Domain once one group within the domain has agreed to adopt the service. Also, the rate of adoption is increased by parents and other users that are using the service for one Group Domain (such as a school), and then help introduce the service for use in other Group Domains (such as a youth soccer league or town committees).
The characteristics of a Group Domain in certain embodiments parallel the characteristics of a real-life group organization in many ways. For example, the top-level domain of Kiwanis is Kiwanis International. At the Kiwanis International level: 1) the total membership pool for the Kiwanis organization is defined, 2) access to the Kiwanis organizational resources, finances, and roles for its members are established, and 3) non-members are not permitted access to privileged information. A Group Domain instance of Kiwanis International in the online environment of certain embodiments behaves in a similar way. The top-level Group Domain defines the total membership for Kiwanis within the online environment. Non-members are not permitted access to the Kiwanis Group Domain. Thus, the Kiwanis International Group Domain can be considered a “walled-garden” within the service. The Kiwanis manager exclusively controls the authentication and granting of membership to users, according to certain embodiments. The internet URL used to access the Kiwanis Group Domain may be specific, such as: www.Kiwanis-International[service provider].com where “service_provider” refers to the service provider's web domain. Additionally, a group may choose to redirect some or all of a web domain owned by the group to their “walled-garden” Group Domain area within the service provider's website. For example, www.kiwanis-international.net may automatically redirect users to www.Kiwanis-International.[service provider].com.
According to certain embodiments, a number of other components within the online environment combine to create a competitive service offering that can result in broader and deeper adoption of the service by various Group Domains, within a Group Domain, and by individual users. Such components are listed below and discussed in greater detail herein:
In addition to the components listed above, the following features are offered as part of the online environment, according to certain embodiments.
Real-life groups or communities like Kiwanis International, a school, or a sports organization like AYSO are organized into their own Group Domain within the online environment of certain embodiments. A Group Domain functions as an organization's virtual “walled garden” where the group controls and offers secure access to its members. The hierarchy of a Group Domain instance and its associated sub-groups, roles, and membership are illustrated in
An organization can utilize the online environment to create a new Group Domain at any layer of the existing organization. For example, a local soccer team can establish an AYSO Group Domain in the online environment of certain embodiments for use by their local members. Since an embodiment treats a Group Domain as nothing more than a special type of group that has no parent groups, it is quite simple for the AYSO organization to expand the hierarchy upwards to other local teams, and to the regional level, and eventually to the national level without requiring the creation of a new Group Domain. The top-level group in the organizational hierarchy simply becomes the Group Domain. Each of these levels of the organization would be linked within the online environment of an embodiment based on the hierarchy shown in
In other cases, an organization may choose to use the online environment of an embodiment to create a top level group and expand to the lower levels of the organization immediately or over time. As an example, an administrator for a local school like Bullis Charter School (BCS) might set-up the BCS Group Domain using the online environment. The administrator would follow the steps below to establish a new Group Domain in the online environment, to perform basic configuration of the Group Domain, and to establish membership and user roles, according to certain embodiments:
As a result of the above steps, the folder structure illustrated in TABLE 2 below is created for the new Group Domain making it functional within the online environment of an embodiment. Subsequent to the creation of the folder structure illustrated in TABLE 2, members with manager or editor access rights within the Group Domain may initiate the creation of sub-groups by following a subset of the steps described above for creating a Group Domain. When establishing a sub-group, the group owner can leverage the Group Domain membership directory to define the sub-group membership and automatically inherit the access rights, roles, attributes, and utilities that have been established at the Group Domain level and by any associated parent groups.
Upon creating a new sub-group, the folder structure for sub-groups illustrated in TABLE 2 is created.
By creating new sub-groups or even parent groups, a given Group Domain expands and retains the notion of hierarchy depending on where the new group is being created. This ensures that groups can create their own Group Domain within the online environment which accurately and organically reflects the hierarchy present within their organization.
As the Group Domain expands, the online environment's support for inheritance ensures that, by virtue of their location within the hierarchy, groups may “inherit” tools and services that have been added at higher levels in the hierarchy. A good example is the Payment Service. According to certain embodiments, there is a Payment Service present at the top level of a Group Domain, but there may be other payment services added at lower levels of the group hierarchy. In such a case, a group will use the Payment Service that is located at the node that is closest to the group and that is higher up in the hierarchy.
The AYSO example illustrates the online environment's inheritance feature. It is possible that payment processing and handling can be coordinated on a regional basis in most cases. However, in large local markets, it is desirable to process payments at a local level. In such a case, the “AYSO West” region can establish a Payment Service that all organizations in the West can use. However, the local clubs in the San Francisco region (sub-groups to the West region) may have their own Payment Service. Thus, when a user in the “Marina District, 9 year old” sub-group of “San Francisco” submits a payment, the online environment of certain embodiments will automatically look in the “Marina District, 9 year old” sub-group folder for a Payment Service first. If a Payment Service is not found in that sub-group, the service will traverse up the hierarchy to the “San Francisco” sub-group. Since a Payment Service is provided in the “San Francisco” sub-group, such a payment service will be used. If no Payment Service is provided in that sub-group then the Payment Service provided in the “West” region sub-group is used.
In other cases, the inheritance feature provides for the reuse of attributes or tools that have been created by parent groups in the domain hierarchy. For example, the AYSO national organization may wish to create custom icons, graphics, backgrounds, fonts, calendar images and formats, etc., to improve the look-and-feel of their Group Domain and organizational identity. Sub-groups within the AYSO domain may use any attributes made available for inheritance by the Manager(s) to customize group content and views. Thus, the sub-groups' set-up time is vastly reduced. Further, a more consistent identity for the entire organization is created. On the other hand, if Group Domain managers may allow sub-groups to have the ability to create their own look-and-feel and identity, according to certain embodiments.
Once a user is successfully added to a Group Domain as a member, the user becomes a “Domain Member” and will default to a Viewer role within the Group Domain with the associated privileges. The member roles and detailed access rights are listed in TABLE 1, while a sample listing of user terms is shown in TABLE 3, herein. A member's role may be upgraded to Participant, Editor, and Manager roles by a Group Domain manager. As members are added to groups within the Group Domain, the newly added members take on the role of “Group Member”, and will default to the Viewer role. Such members may be upgraded to another role by a group manager. The manager may also modify the default role that users receive at the time the users join a group.
As shown in TABLE 1, the role of Viewer is primarily used to limit user's access rights to subscribe to and view content, whereas a Participant role allows a user to actively participate in the group. For example, the participant role allows a user to participate in events, receive and accept payment requests, participate in chat sessions, forums, and polls, and so on. In most cases, members of a group are designated as Participants, while a smaller number of members are designated as Editors. An Editor is a user that has permission to create content within a group context. The Editor automatically becomes the “Owner” of any content item or object that he or she creates. Thus, an Owner has manager-level access rights for content item he created (e.g., the ability to edit, move, and archive the content item).
Prior to a user joining or creating a Group Domain, the user may visit the online environment of an embodiment to learn about the service and request more information. Such persons can browse as “Anonymous” users or logon as “Guest” users. Anonymous and Guest users have no access to Group Domains even as a viewer, unless one or more Group Domains have published content that is outside the “walled garden” and is thus visible to the public. Once a user has created a personal account within the online environment of an embodiment, the user is deemed an “Authenticated user” and can then have access to the user's own user folder, dashboards, preference settings, and so on. However, an authenticated user must still be explicitly added to a Group Domain before the user can gain access to a Group Domain, according to certain embodiments. The Guest and Authenticated User roles are explained in greater detail in TABLE 3, herein.
The online environment of certain embodiments allows an agent or proxy relationship to be established between two or more users to enable the sharing of privileges, roles, and views. In general, the agent relationship between two or more users is established by consent. However, in the case of a minor (a child below the age of 18), the agent relationship between the child's account and one or more adult accounts would likely be established directly by the adults. The linking a number of user accounts within a family is one way to use the agent relationship so that both parents can act on behalf of the children in the family, and also on behalf of the entire family.
The “Groupling” feature is used by the online environment of certain embodiments to store or group members of a similar type as defined either by the group membership or the type of role the member possesses within a Group Domain. Grouplings are a convenient way to manage and communicate with lists of people with common interests, characteristics, or agent relationships. Grouplings can be explained using the Bullis Charter School (BCS) organization example. The BCS group may like to define member types such as “student,” “teacher,” “admin,” “parent” types and thereby create the following Grouplings:
Members of a group may belong to more than one Groupling, but must belong to at least one Groupling, according to certain embodiments. If a member is not given any domain-defined type, he or she will be added automatically to the “others” Groupling.
By selecting from the top-level “—all” Groupling (e.g., bcs-all), members can be identified and assigned to the role-oriented Grouplings for the two groups just created, namely, the top level group (e.g., “bcs”) and the admin group (e.g., bcs.admin). As a non-limiting example, for the top level, the member role Grouplings may be named as follows:
For the admin group, these role Grouplings may be named as follows:
In the BCS example, the following additional Groupling configuration is suitable for establishing a sub-group within the BCS domain:
With respect to agent relationships, the act of establishing an agent with the ability to act on behalf of another user is not bi-directional, according to certain embodiments. For example, parents would like to act on behalf of their children, but not vice-versa. A pair of users can establish each other as agents in order to create a bi-directional agent relationship, such as in the case of spouses.
A family group is an example of a set of specialized group with specific agent relationships as described above. The online environment of certain embodiments provides for the creation of specialized groups with specific agent relationships and roles between the members of the group and custom treatment of views and actions within the online environment of certain embodiments based on the types of groups being supported. These specialized groups and their associated views can be adopted by users and groups, or created by the groups themselves.
Once an agent relationship is created, an agent may have access to all of the content, views, and actions available to the user that the agent is representing, and at least the following is applicable, according to certain embodiments:
An agent may or may not have access to the communication and collaboration tools (e.g., chat, forums, email) to communicate on behalf of the user, and may or may not have access to the user's configuration panel depending on the restrictions that are applied to the agent relationship, according to certain embodiments.
This online environment of certain embodiments also provides the following capabilities for supporting agent relationships:
To track agent relationships, an agent Groupling may be assigned to each user. The agent Groupling is named according to the user's name agent.<username> and contains the user ids of the user's agents. For example, an agent Groupling for a child may look like:
Email exploders associated with Grouplings are a powerful communication tool featured within the online environment of certain embodiments. Email exploders can be used to send email directly to a group of people, or more likely, to send email directly into a forum associated with the Groupling. There are two sample naming conventions for email exploders. The generic approach is based on appending the group name hierarchy to the service providers' domain. Some examples for BCS are:
The second email exploder naming convention is based on utilizing a custom web domain that a group has forwarded to their Group Domain within the service provider's web site. Returning to the above BCS example, if BCS owns the “bullischarterschool.net” web domain and enabled domain-forwarding to their Group Domain, the email exploders may look like:
1. first.grades@bullischarterschool.net
2. first.grades-students@bullischarterschool.net
3. first.grades_managers@bullischarterschool.net
Maintaining the security and integrity of the various Group Domains within an online environment of certain embodiments creates a trusted “walled garden” environment where private and sensitive organizational and personal information can be created and maintained. The online environment of certain embodiments provides an encrypted login capability along with encrypted data transfers after an Authenticated User logs into the online environment. The security of a user's identity is tied to a unique and valid email address, for example. Generally, an authenticated user has no access to Group Domains unless the user is granted membership to the Group Domain. Thus, managers of a Group Domain verify a user's identity and email address prior to granting the user membership privileges. With such a scheme, a user can reuse his identity for each additional Group Domain that the user joins.
Even though a user may belong to multiple Group Domains and groups, the user participates in each group separately, thereby preserving the integrity of each group's “walled garden”. The user can view and act upon content that is consolidated from various groups into the user's home dashboard. However, the user's role and access rights are automatically modified to the appropriate levels with respect to the content the user is viewing or upon which the user is acting depending on the group context associated with the content.
Each user of the online environment or a service instance has his/her virtual home in the online environment, according to certain embodiments. The user's virtual home includes a dashboard, content folders and items, preference settings, profile settings, and other utilities such as payment status views and reporting. Each user's virtual home functions as the user's personal “walled garden” environment to which only the authenticated user has access, unless the user designates one or more agents with access rights to the user's virtual home. Whenever an authenticated user successfully logs into the service, the authenticated user is directed to that user's dashboard page. The home dashboard is the focal point with respect to the user's ability to view and act upon content items and requests. The dashboard consolidates such information from all groups in which the user is a member. The home dashboard is also the springboard to other Group Domains and favorite groups of the user.
Within the “preference” tool, a user can establish a personal profile and contact information. By default, this information is not available to Group Domains or groups unless specified by the user. The user can configure the profile information to allow portions of the profile information to be shared with a specified Group Domain. A non-limiting implementation includes a table with the rows comprising various pieces of personal information (address number, street address, city, state, zip, home phone, cell phone, fax number, email address, alternate email address, etc.). The columns may list the group domains to which the respective user belongs. Each cell (at the intersections of the rows & columns) may contain a checkbox that can be checked or unchecked by the respective user depending on whether the respective user wishes to disclose, to the specified Group Domain, the piece of information in the corresponding cell.
Many of the informational panes in the dashboard are configured to consolidate information from all the groups for which the user is a member. The user may customize this setting by de-selecting groups for inclusion in the dashboard in the “preferences” tool. Each group, for which the user is a member, has the same relative priority for the purpose of determining which content items are to appear in the dashboard. However, the user may also raise or lower the priority of each group or an entire Group Domain in the “preferences” tool. In other words, the user is provided a “volume” knob for each group. If the user turns a groups' “volume” down to zero, the group is effectively removed from the dashboard all-together without affecting the user's membership in the group. Such preference settings have an impact on the dashboard panes because the panes consolidate information from several groups.
An example of a user's home dashboard is shown in
The payment status pane contains a summary of the user's payment requests, typically from all groups of which the user is a member except for groups for which the “volume” set to zero by the user. A summary of the number of open and pending payments, as well as the date of the next payment that is due, may be viewed at payment status pane. Each status text is also a functional link that takes the user to a more detailed payment status view, or to an individual payment request.
The search box allows the user to search for content within the user's home or within groups of which the user is a member. The default action for a search is to search for content within all groups and the user's home. However, the user has options to restrict the search to the user's home, to all groups, or to the current group to where the user has navigated (only applicable when the user is navigating or viewing content within a group home area).
The user folder navigation pane offers quick access to the user's content items, preferences, profile settings, dashboard page, utilities, list of the groups for which the user is a member, and payment request status page. Most of the applicable customizations and user preference settings are available from this location. The Content folder behaves in the same way as a group's content folder. The content folder is a location for a user to add content items, such as files, pictures, news items, and so on. A user may allow other users or even groups of users to access selected content items, but in so doing does not enable other users to gain access to the rest of a user's content items and home area. The “groups” list page: 1) displays all the groups for which the user is a member including those groups for which the “volume” is set to zero by the user, 2) includes links to each group, 3) allows the user to accept requests to join new groups, and 4) allows the user to cancel group memberships.
The events list pane includes an at-a-glance view of current upcoming events of the highest priority consolidated from all the groups of which the user is a member. Generally, each item in the list includes the event title, date(s), and group label to indicate the group with which the event is associated. The text for each event is an active HTML link, for example, to a page comprising the details of the event in the applicable group's home content area.
The largest pane in the dashboard generally includes the user's “hot items list.” The hot items list is a consolidated and prioritized summary list of content items from all the groups of which the user is a member. According to certain embodiments, each item in the list includes an icon indicating the type of content (e.g., news item, need item, event, payment request, picture, etc), an item title, the short description or overview of the item (if any), and a group label to indicate the group with which the item is associated. As a non-limiting example, the text and icons associated with each item is an active HTML link to a page containing a view of the content item with the associated details. By default the list is sorted and filtered based on a method described below. However, the user has many options for specifying the sort and/or filter criteria for the hot items list, including:
A method is used by the online environment of certain embodiments to determine the degree of visibility of various content items when displayed in a user's dashboard. In general, the method is used to determine a dashboard rank ordering score (or just “rank”), for example, from 0-10 for each content item applicable to a specific user: A list of content items is created in order of highest dashboard priority score to the lowest score. For instance, if there is space to display X number of content items in a dashboard pane, then the first X items from the prioritized list are displayed in rank order by the display software.
The method used in determining the dashboard priority score for a content item may be fixed, or adjustable by a service provider based on user feedback and based on the performance of the method. Thus, the choice of method may vary from implementation to implementation. However, an example of the dashboard rank ordering score computation is shown below.
In this example, the following components are used in the determining a content items' dashboard rank, according to certain embodiments:
The dashboard priority score of a specific content item can be represented by:
where all the components except Datepriority are set by either the user or established by the owner of the content item. The Datepriority component is computed in the following manner:
The Manager role is a special role within a group. In a use-scenario, the manager role is assumed by a group coordinator or lead person. Initially the Manager role defaults to the user that created the group. In many cases, a new group may be formed temporarily for the purpose of coordinating an event, a class, or a workshop, for example. In such a case, the Manager role may be assumed by the user who is leading the temporary event, such as a play or concert, or a teacher, or a volunteer group lead. A Group Manager may delegate a multitude of tasks such as the above and create a sub-group for coordination of the associated activities. The Manager role usually does not vary from one group to another, with two exceptions, according to certain embodiments. The Manager of a Top-level Group (a group with no parents) has expanded privileges in comparison to a Manager of any other group (that has a parent group). The second case in which a Manager's roles can vary from one group to another is based on the access roles and modified inheritance rules established by a manager of a group that is higher up in the group hierarchy. Managers can limit access roles, reduce inheritance capabilities, or force certain attributes to be inherited by sub-groups formed below their group in the hierarchy, according to certain embodiments. A top-level Group manager role is usually assumed by one or more group officers or administrators because such a role includes managing the Group Domain membership, identity, and access rules and privileges.
The typical permissions and roles available to a group manager are listed in TABLE 1. A manager may modify the group inheritance and permissions settings to limit or prohibit some of the Manager permissions available to groups that are lower in the group hierarchy. Some examples of limiting the permissions of a sub-group manage are discussed below.
A group may have one or more Administration sub-groups associated with it. The group Manager can delegate portions of the Manager role to other Manager or Editor roles within each sub-group. Such Administration sub-groups are simply special cases of a Group Manager's ability to create sub-groups and to delegate authority. Five sample roles in the Administration sub-group are listed in TABLE 4. TABLE 4 describes the manager roles for Accounting, Admissions, Support, Member and Merchant sub-groups.
However, other possibilities for delegating Manager tasks may exist. Thus, the roles that are supported in the online environment may vary from implementation to implementation. These roles are merely a collection of permissions and access surrounding accounting and member administration, and each can be handled directly by the manager(s) or assigned to another group member depending on the manager's preference. However, each role is discussed herein as a set of access rules and tools available to a Group manager.
A use-scenario for handling group accounting and payments includes assigning the Accounting Manager role to the Group Treasurer and to then disable the ability for other groups in the domain to create their own Payment Service. Thus, all payments and accounting issues are handled by the Group Treasurer. However, in larger and more complex group organizations, such as national organizations, it may be beneficial for sub-groups to have the ability to create and manage their own accounts.
In a top-level Group, an Admissions Management sub-group and one or more Admissions Manager roles may be established to manage admission of members into the Group Domain using an Admissions Management tool. In larger and more complex organizations, other Admissions Management sub-groups may be needed in other parts of the Group Domain hierarchy, as in the case of handling sub-group regional membership.
An important role of the Admissions Manager is authenticating and registering new users as members. The task of establishing or managing Group Domain membership may be handled in one or more of the following ways by an Admissions Manager and an Admissions Management tool, according to certain embodiments:
The Support sub-group and Support Manager role is used to centralize support for the Group Domain, or associated Group Sub-Tree, to one or more group members. The Support sub-group and Support Manager are provided with support tools in the online environment. As a non-limiting example, the support tools provide level 1 support and include the ability to escalate unsolved issues to level 2 for sending to the online environment's support group. The online environment provides flexibility for the Support Manager role and enables associated responsibilities to be out-sourced to a third party at the preference of the Group Domain. For example, the online environment may offer level 1 support services to Group Domains at a fee.
A Member Management sub-group and Member Manager role is a light-weight mechanism used by a group to manage member administration, including the creation and management of Grouplings and their associated email exploders. Parent group memberships can be used automatically to limit group membership by a Member Manager, but the Group Domain member directory is automatically used by the online environment of certain embodiments to ensure that only Group Domain members are added as members of a group. Thus, any new members that are granted access to the group have been authenticated at the Group Domain level.
The term “Coordinator”, used within the online environment, refers to a person who creates either an Event or a Payment Request content item. The term “Coordinator” typically applies to a real-life group coordinator.
The group home dashboard is the starting point for viewing a summary of what's happening within a group. The group home dashboard has many panes in common with the user home dashboard. Additionally, when navigating anywhere within a Group Domain, the group identity is typically visible at the top of the window. The group logo or identity is usually configured at the Group Domain level and can be inherited or over-written within sub-groups depending on the inheritance rules created by the group managers.
As described in the User Home Dashboard, the following panes are also visible when the user views a group home dashboard (and in most other views within the online environment of certain embodiments: “Quick-nav” bar, Search, Payment Status pane, and the Events List pane. The functionality and content viewed in each of these panes behaves in a similar way as described in the User Home Dashboard section, with the exception of the Events List pane.
The content displayed in the Events List pane defaults to showing events associated with the current group and sub-groups rather than consolidating events from all the groups of which the user is a member. The user may customize the events viewed in the Events List to consolidate events from:
When events from more than one group are shown in the Event List pane then the event associated with the current group are highlighted.
The Group folder navigation pane may contain links to the following items while the user navigates anywhere within a group home, according to certain embodiments:
From the Group folder navigation pane, a user can quickly navigate to the group home dashboard, sub-groups, group content folders, and member directory. From the Group folder navigation pane, a manager can gain access to group administration tools that they utilize in their role.
The following content items may have forms available for Editors to create content and views available for other members to view the content items:
Each content item type has a specialized form and view mode, according to certain embodiments. TABLE 5 illustrates some non-limiting examples for form and view fields which are applicable or available for all content items.
Content items in the online environment of certain embodiments include Event, Needs, and Payment Request content items. Some non-limiting examples for form and view fields associated with an Event are listed in TABLE 6.
In the fields associated with Events, it possible to request or require registration for an event. Group members can register for an Event using simple Event Registration form fields incorporated into an Event form. Some non-limiting examples of fields associated with an Event Registration are listed in TABLE 7.
“Needs” content items are a useful and flexible part of the online environment of certain embodiments. The ability to request a “need” within a group occurs in many different scenarios, including requesting volunteers to play specific roles at an event, to bring certain materials or foods, to be drivers or car-pool leads, etc. Other scenarios include requests for participation or donations. The online environment of certain embodiments supports an organization's requirements for coordinating “Needs” requests in a number of ways, including:
A Needs Request item list is an advanced and detailed way for a group coordinator to request and track the response to needs. A Needs Request item list can be associated with or referenced by most other content items, but are particularly applicable to Event and Payment Request items where volunteers or items are being requested in association with an event. Some non-limiting examples of fields associated with a Needs Request item list are listed in TABLE 8.
Nearly all content items can be designated as a “Notice”, which is a special priority designation enabling an Editor to promote a content item to a group or user's dashboard view. This is particularly useful for important or time critical items needing to be highlighted to a group's membership. Whether an item with the Notice designation gets promoted to a group or user's dashboard depends on how many other content items of an equal or higher priority and with an imminent target date are applicable to the group or user dashboard.
Online payment forms and views are an important part of the online environment of certain embodiments and a key utility utilized by groups. This section only describes Online Payment actions forms, views, whereas the details of the online payment method are described in the “Online Payments and Tracking” section. The following usage cases and actions exist for the various roles within the online environment of certain embodiments:
Members:
The forms and views associated with payments are listed in TABLE 9. An example of a Payment Request form that can be used by a coordinator to create a Payment Request is illustrated in
Depending on the need for Payment Request approvals (as defined by the Accounting Manager), when a coordinator submits a Payment Request, the payment request either will be submitted for approval to the Accounting Manager and subsequently be made available to group members, or the request will be made directly available to group members without an approval cycle.
Table 9 describes some sample payment views and request forms.
The online environment of certain embodiments provides a powerful set of tools for groups to efficiently handle online payments, reimbursements, refunds, and reporting of the associated transactions as previously discussed. The supporting online payment infrastructure and mechanisms used by groups to facilitate the online payments capability is described in this section.
For convenience of explanation, the following terms are used for online payments and tracking:
Some of the software design details associated with online payments including object hierarchy, object descriptions, fields, and attributes are shown in TABLE 10 and TABLE 11, according to certain embodiments.
The Payment Service API is used as an encapsulation method to allow the upper layers of software within the online environment of certain embodiments to be isolated from the details and various payment mechanisms used below the API in order to process online payments. Such an API enables flexibility to adopt, integrate, and support various third party Payment Gateway methods or External Payment Services. Notwithstanding the examples of third party implementations discussed in this document, it is envisioned that multiple other mechanisms will be supported in the embodiments. Some non-limiting examples of Payment Service API calls are listed in TABLE 12.
The functions of the Payment Service API include:
Two underlying methods for implementing online payments within the online environment of certain embodiments are described herein as non-limiting examples. The first involves the usage of an External Payment Service such as PayPal as a vendor that acts as a Payment Gateway and a Group Bank Account (see
A group's Administrator or Accounting Manager can create an account with the External Payment Service vendor and then link the account to the online environment of certain embodiments within the Accounting Management tool, thereby enabling the online environment of certain embodiments to enact the Payment Service using the group-controlled account. One or more separate Group Bank Account's can be linked to the Payment Service bank account in order to transfer funds to a group's General Funds for example. The online environment of certain embodiments may provide for automation and tracking of the fund transfers, but the transfers themselves are carried out within the External Payment Service vendor's website in this scenario, for example.
The second Payment Service scenario or mechanism involves the integration of a Payment Gateway into the online environment of certain embodiments and the use of a Service Provider-controlled merchant bank account as the Virtual Transaction Account for the groups that are supported.
Depending on the scenario used and the kinds of merchant bank services that are provided by an External Payment Service or the Service Provider's merchant bank vendor, online reimbursements sent directly into a member's bank account may or may not be possible. In some cases, the member may be required to have a bank account with the External Payment Service vendor in order to handle reimbursements, such as with PayPal. However, in most cases the offline reimbursement method is available and provides for tracking and reporting of reimbursements.
The online environment of certain embodiments include marketing and advertising programs being sold to merchant businesses, and reward programs for organizations participating as a Group Domain in the online environment. “GoLocal” is the term used to describe the marketing and advertising programs for merchant businesses. GroupReward is the term used to describe the revenue sharing and reward programs for groups. Together, the “GoLocal” and GroupReward features create a linkage and a win-win environment between a community's merchants and its schools, clubs and groups. The online environment of certain embodiments offers merchant businesses a dynamic and cost-effective way to market and promote themselves to Group Domains within the online environment. Such promotions can be targeted toward specific communities or geographies. An illustration of the GoLocal and GroupReward features is shown in
The online environment of certain embodiments provides a mechanism for merchants to create and place advertising and marketing snippets that can appear within the “Supporting Merchants Ad” pane which is displayed, in most cases, to a member when the member is browsing in the online environment website.
The online environment of certain embodiments tracks the frequency that members of a specific Group Domain view and click on advertisements, and bases the GroupReward payments to groups within a Group Domain on the members' participation levels. More detailed information about merchants and their GroupReward marketing programs can also be offered within the online environment website, such as:
The top-level group Manager within a Group Domain, or members with access to a Merchant Management administrative sub-group can determine which merchants and advertisements can reach their membership. The online environment of certain embodiments enables groups to filter and approve or reject advertising and marketing programs from new or existing merchant businesses. The ability to prevent inappropriate merchant advertising from reaching their membership may be a critical issue for certain types of organizations, particularly schools and other educational organization. Groups also have the ability to feature or highlight certain merchant businesses or marketing programs from a participating merchant to their group membership. Since the group itself collects GroupReward revenues based on the participation of their membership in advertising or marketing programs, the GroupReward feature facilitates a win-win-win relationship between a group, its members, and merchant businesses.
The online environment of certain embodiments allows for very flexible reward levels and relationships to exist between the service provider, merchant businesses, and groups. However, the revenue flow is generally from merchant business to the service provider in the form of advertising and/or marketing program subscription payments, followed by some portion of the revenues flowing to groups in the form of GroupReward payments based on their participation levels.
The GroupReward card or GroupReward tracking feature is used to track a user's purchasing activities at participating merchant businesses. In one scenario, GroupReward tracking is possible using a user's existing payment cards such as, credit, ATM, and/or loyalty cards, by registering them with the service provider. When these user cards are registered and used to make payments at participating Merchant Businesses by swiping the card at a Point-of-Sale terminal, they are used by the online environment to track a user's purchasing behavior and the applicable GroupReward revenues to be allocated to the groups in which the user is a member. In another scenario, a GroupReward card is issued by the Service Provider to users and also swiped at a Point-of-Sale terminal when the user makes a purchase at a participating Merchant Business in order to register the purchases with the online environment and Service Provider.
The participating Merchant Businesses establish their GroupReward sharing percentages within the online environment of certain embodiments, thereby determining the percentage of a qualified purchase that is to be paid by the Merchant Business to the groups in which a member belongs. For example, a local coffee shop may decide to allocate 3% of qualified purchases to participating groups in the form of a GroupReward payment. As another example, a larger merchant such as American Airlines or Safeway might choose to allocate 5% toward GroupReward payments. The online environment of certain embodiments enables a Service Provider to receive Point-of-Sale transaction information based on GroupReward or other cards registered by the user from one or more third-party vendors offering Point-of-Sale transaction processing.
The online environment of certain embodiments can process, store, and report on purchases per group, merchant business, or user. A Service Provider can generate periodic reports in order to invoice Merchant Businesses for GroupReward payments and to then allocate those payments to the groups themselves. In addition, a group's participation levels in advertising and marketing programs within the online environment website can be summarized and the appropriate revenue sharing allocated from the Service Provider to the group. The GroupReward and revenue sharing payments can then be made offline or online directly into a group's Virtual Transaction Account or transferred into a group bank account or Payment Service that has been linked to the online environment for processing online group payments.
As part of the GoLocal feature, a Service Provider can offer additional marketing or promotional services to merchant businesses enabling them to link promotions to GroupReward or other user payment cards. As an example, a local coffee shop may wish to offer a 2-for-1 breakfast promotion to members of all local school organizations within a 10 mile radius of the shop for a 30 day period one time per person. The online environment of certain embodiments can enable the merchant to target specific types of groups and geographies, create their marketing or promotional offer, and then present the marketing or promotional offer to the selected target audience through the online environment website. When a qualified member presents one of the registered payment cards (e.g., GroupReward card or credit card) to the merchant, the process of swiping the card into a Point-of-Sale terminal will allow the merchant to determine if the user/purchaser is qualified to receive the 2-for-1 promotion, for example. The online environment of certain embodiments can track a user's usage of specific marketing and advertising campaigns in conjunction with a third-party Point-of-Sale transaction processing vendor in order to qualify them for specific promotions during certain periods of time (e.g., only one 2-for-1 breakfast per month or per year).
Most of the GroupReward and GoLocal features can be implemented in an online manner via the online environment of certain embodiments in conjunction with a Service Provider instance. The online environment may include the following features, according to certain embodiments:
The foregoing description, for purpose of explanation, has been described with reference to specific embodiments. However, the illustrative discussions above are not intended to be exhaustive or to limit the invention to the precise forms disclosed. Many modifications and variations are possible in view of the above teachings. The embodiments were chosen and described in order to best explain the principles of the invention and its practical applications, to thereby enable others skilled in the art to best utilize the invention and various embodiments with various modifications as are suited to the particular use contemplated.
This application claims benefit of Provisional Application 60/840,484, filed Aug. 25, 2006, by David Beyer and Darren Lancaster the entire contents of which is hereby incorporated by reference as if fully set forth herein, under 35 U.S.C. §119(e).
| Number | Date | Country | |
|---|---|---|---|
| 60840484 | Aug 2006 | US |
