US20110035444A1 - Relationship security in online social and professional networks and communities - Google Patents
Relationship security in online social and professional networks and communities Download PDFInfo
- Publication number
- US20110035444A1 US20110035444A1 US12/619,451 US61945109A US2011035444A1 US 20110035444 A1 US20110035444 A1 US 20110035444A1 US 61945109 A US61945109 A US 61945109A US 2011035444 A1 US2011035444 A1 US 2011035444A1
- Authority
- US
- United States
- Prior art keywords
- relationship
- role
- features
- new
- aggregate
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/10—Office automation; Time management
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
- H04L63/104—Grouping of entities
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/54—Presence management, e.g. monitoring or registration for receipt of user log-on information, or the connection status of the users
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/20—Services signaling; Auxiliary data signalling, i.e. transmitting data via a non-traffic channel
- H04W4/21—Services signaling; Auxiliary data signalling, i.e. transmitting data via a non-traffic channel for social networking applications
Definitions
- FIG. 10 is an example operation of the gate of FIG. 9 ;
- B2C Business-to-Consumer
- B2B Business-to-Business
- B2B can be used to represent for relations between enterprises (e.g. between a business vendor 20 and a business customer 20 ), contrary to relations between enterprises and other groups (e.g. customers, public administration).
- the term B2B can be used to define marketing activities as well as electronic communication relations between enterprises.
- M 1 is the customer 12 a and M 2 is the vendor 12 b for one relationship pair 12 and M 1 is the vendor 12 b and M 2 is the customer 12 a for another relationship pair 12 ′ that they have, such that the same M 1 and M 2 members 20 can also have a second Customer to Vendor relationship 12 ′ where M 2 plays the Customer role 12 a and M 1 plays the Vendor role 12 b.
- the dissimilar features/capabilities 18 a,b would be compatible with one another as defined by the role pair 12 . It is also recognised that the features/capabilities 18 a,b assigned to the roles 12 a,b can be directional, such that there may be more assigned features/capabilities 18 a for the role 12 a as compared to the that the features/capabilities 18 b assigned to the role 12 b of the role pair 12 , as further described below.
- relationship pairings 12 can be non-directional and/or directional relationship roles 12 a,b and associated non-directional and/or directional relationship features/capabilities 18 a,b.
- member M 1 may be the vendor and member M 2 may be the customer
- member M 1 may be the customer
- member M 2 may be the vendor.
- M 1 would only be enabled for the first relationship pair 12 for directional outgoing vendor interactions 14 (i.e. to customer) and incoming vendor interactions 14 (e.g.
- Active Interactions 14 can be triggered by an action 14 taken by member M 1 or M 2 , such as active interactions but not limited to: Vendors request to ‘view available time’ and see the available flex calls of their Customers; Vendors booking available time for a call, since only vendors can book available time; and a member 20 changing their contact information (e.g.
- multimember pairings 12 could be implemented by the system 26 , for example where each of a plurality of members is paired to a respective member (e.g. a many to one pairing) or a respective member is paired to a plurality of members (e.g. a one to many pairing).
- This type of pairing provides for the setup of group settings, such as a plurality of customers that are serviced by a vendor, a plurality of vendors that are selected to service a particular customer, a manager that has a number of employees, etc.
Landscapes
- Engineering & Computer Science (AREA)
- Business, Economics & Management (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Strategic Management (AREA)
- Human Resources & Organizations (AREA)
- Entrepreneurship & Innovation (AREA)
- Economics (AREA)
- Tourism & Hospitality (AREA)
- General Engineering & Computer Science (AREA)
- Computing Systems (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- Marketing (AREA)
- Operations Research (AREA)
- Quality & Reliability (AREA)
- Data Mining & Analysis (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Information Transfer Between Computers (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Computer And Data Communications (AREA)
- Storage Device Security (AREA)
Abstract
A method for evolving a defined online existing relationship between two members, the online existing relationship defined by a plurality of existing relationship features to manage network interaction on a communications network between the two members. The method includes receiving a new online relationship having new relationship features different from existing relationship features and characteristic of the new relationship; aggregating the existing and new relationship features as aggregate relationship features to define an aggregate relationship; storing the aggregate relationship features as relationship data; and accessing the relationship data to determine whether a selected network interaction from one of the members is permitted in view of at least one of the corresponding aggregate relationship features, and facilitating the selected network interaction when permitted; wherein the corresponding aggregate relationship features include at least one of the network interaction type, the network interaction content, or the network interaction format.
Description
- This application claims the benefit of U.S. Provisional Application No. 61/272,010, filed Aug. 6, 2009, now pending, the entire contents of which is hereby incorporated herein by express reference thereto.
- This invention relates to configuration of networked entities for coordination of interaction between the networked entities.
- In today's multifaceted society, there are a number of industries (e.g. healthcare) that can be characterized as having a particularly fragmented workforce—in healthcare from physicians to nurses to practice administrators—that are extremely busy in their day to day activities. Day to day work for individuals in today's industries can be highly irregular and unpredictable, and with so many different parts working in isolation there are limited opportunities for people to be exposed to one another. Further, with few networks supporting these people or groups in reaching out and connecting with each other, it's easy for them to become isolated. All of this makes it very difficult for industry professionals to get in touch with who they want when they need to, to stay in touch with colleagues and co-workers within and/or between different industries, and to coordinate productive interactions with each other.
- Social and professional networking is valuable to business professionals and healthcare professionals of all types. When people become members of social and professional online networks, they need to connect with other members in order to share information with, interact with, and network through those members. In cases where people are connecting to business professionals, business relationships are important and need to be entered into with care. Each relationship is different, each relationship has a level of trust, and people do not want to connect online with each of their professional contacts in the same way. Ultimately, it's not a one size fits all world when it comes to connecting online and the representation electronically (i.e. online) of the mixture of real world business and professional relationships is problematic using today's electronic relationship models.
- Accordingly, in the current one size fits all world, a system is needed that enables community members to connect with their business connections in a way that represents their multifaceted life with the plurality of other members in the community (both known and unknown to the community member) because the members do not want to share the same information, communicate and interact in the same way, nor enable people to network through them in the same way, in view of real-world relationships. An example of this is that not everyone is “best” friends with every other person they have met in their real-world life. There are varying degrees of friendship/acquaintance in the real-world and there is a need to represent this in the online/electronic forum, amongst other possible types of relationships between people.
- In one embodiment, the present invention may advantageously provide a benefit and rule configuration environment to obviate or mitigate at least some of the above-presented disadvantages.
- In the current one size fits all world, a system is needed that enables community members to connect with their business connections in a way that represents their multifaceted life with the plurality of other members in the community (both known and unknown to the community member) because the members do not want to share the same information, communicate and interact in the same way, nor enable people to network through them in the same way, in view of real-world relationships. An example of this is that not everyone is “best” friends with every other person they have met in their real-world life. There are varying degrees of friendship/acquaintance in the real-world and there is a need to represent this in the online/electronic forum, amongst other possible types of relationships between people. One method is provided for evolving a defined online existing relationship between a first member and a second member, the online existing relationship defined by a plurality of existing relationship features for use in managing network interaction on a communications network between the first member and the second member. The method comprising: receiving a new online relationship having new relationship features such that the new features are different from the existing relationship features, the new relationship features being characteristic of the new relationship; aggregating the existing relationship features and the new relationship features as aggregate relationship features a combination of the existing relationship features and the new relationship features in order to define an aggregate relationship; storing the aggregate relationship features in a storage as relationship data representing the aggregate relationship defined by the relationship features; and accessing the relationship data in order to determine whether a selected network interaction from one of the members is permitted in view of at least one of the corresponding aggregate relationship features of the aggregate relationship, and facilitating the selected network interaction between the members when determined as permitted; wherein said at least one of the corresponding aggregate relationship features of the aggregate relationship is used to define as permitted at least one of the network interaction type, the network interaction content, or the network interaction format.
- A first aspect of the present invention provided is a method for evolving a defined online existing relationship between a first member and a second member, the online existing relationship defined by a plurality of existing relationship features for use in managing network interaction on a communications network between the first member and the second member, the method including receiving a new online relationship having new relationship features such that the new features are different from the existing relationship features, the new relationship features being characteristic of the new relationship; aggregating the existing relationship features and the new relationship features as aggregate relationship features a combination of the existing relationship features and the new relationship features in order to define an aggregate relationship; storing the aggregate relationship features in a storage as relationship data representing the aggregate relationship defined by the relationship features; and accessing the relationship data in order to determine whether a selected network interaction from one of the members is permitted in view of at least one of the corresponding aggregate relationship features of the aggregate relationship, and facilitating the selected network interaction between the members when determined as permitted; wherein said at least one of the corresponding aggregate relationship features of the aggregate relationship is used to define as permitted at least one of the network interaction type, the network interaction content, or the network interaction format.
- A further aspect provided is a method for evolving a defined online existing relationship pair between a first member and a second member, the online existing relationship pair defined by a first existing relationship role assigned to the first member having a plurality of first existing role features for use in managing network interaction on a communications network between the first member and the second member, and a second existing relationship role assigned to the second member having a plurality of second existing role features for use in managing the network interaction between the first member and the second member, the method including receiving a new online relationship pair having a new first relationship role and a second new relationship role, such that the corresponding first new role features and the second new role features are different from the first existing role features and the second existing role features, the first new role features and second new role features being characteristic of the new relationship pair; aggregating the first existing role features and the first new role features as aggregate first role features being a combination of the first existing role features and the first new role features in order to define an aggregate first role; aggregating the second existing role features and the second new role features as aggregate second role features being a combination of the second existing role features and the second new role features in order to define an aggregate second role; storing the aggregate first role and the aggregate second role with their associated aggregate features in a storage as relationship data representing an aggregate relationship pair defined by the aggregate roles and their corresponding aggregate role features; and accessing the relationship data in order to determine whether a selected network interaction from one of the members is permitted in view of at least one of the corresponding aggregate role or aggregate role features of at least one of the aggregate first role or aggregate second role of the aggregate relationship pair, and facilitating the selected network interaction between the members when determined as permitted; wherein said at least one of the corresponding aggregate role or aggregate role features of at least one of the aggregate first role or aggregate second role of the aggregate relationship pair is used to define as permitted at least one of the network interaction type, the network interaction content, or the network interaction format.
- A further aspect provided is a method for evolving a defined online existing relationship pair between a first member and a second member, the online existing relationship pair defined by a plurality of existing relationship features for use in managing network interaction on a communications network between the first member and the second member, the method including receiving a new online relationship pair having corresponding new relationship features different from the existing relationship features, the new relationship features being characteristic of the new relationship pair; combining the existing relationship features and the new relationship features to generate combined relationship features by adding a new feature from the new relationship features to the existing relationship features, such that a minimum number of the existing relationship features remain as part of the combined relationship features; storing the combined relationship features in a storage as relationship data representing the new relationship pair for the members defined by the corresponding respective combined relationship features; and accessing the relationship data in order to determine whether a selected network interaction from one of the members is permitted in view of at least one of the corresponding combined relationship features, and facilitating the selected network interaction between the members when determined as permitted; wherein at least one of the corresponding combined relationship features of the new relationship pair is used to define as permitted at least one of the network interaction type, the network interaction content, or the network interaction format.
- A further aspect provided is a method for evolving a defined online existing relationship pair between a first member and a second member, the online existing relationship pair defined by a first existing relationship role assigned to the first member having a plurality of first existing role features for use in managing network interaction on a communications network between the first member and the second member, and a second existing relationship role assigned to the second member having a plurality of second existing role features for use in managing the network interaction between the first member and the second member, the method including receiving a new online relationship pair having corresponding first new role features and the second new role features different from the first existing role features and the second existing role features, the first new role features and second new role features being characteristic of the new relationship pair; combining the first existing role features and the first new role features to generate combined first role features by adding a new feature from the first new role features to the first existing role features, such that a minimum number of the existing first role features remain as part of the combined first role features; combining the second existing role features and the second new role features to generate combined second role features by adding a new feature from the second new role features to the second existing role features, such that a minimum number of the existing second role features remain as part of the combined second role features; storing the combined role features in a storage as relationship data representing the new relationship pair for the members defined by the corresponding respective combined role features; and accessing the relationship data in order to determine whether a selected network interaction from one of the members is permitted in view of at least one of the corresponding combined role features, and facilitating the selected network interaction between the members when determined as permitted; wherein at least one of the corresponding combined role features of the new relationship pair is used to define as permitted at least one of the network interaction type, the network interaction content, or the network interaction format.
- A further aspect provided is a method for defining an online relationship pair between a first member and a second member, the relationship pair including a first relationship role assigned to the first member having a plurality of first role features for use in managing network interaction on a communications network between the first member and the second member, and a second relationship role assigned to the second member having a plurality of second role features for use in managing the network interaction between the first member and the second member, the method including assigning the first relationship role to the first member such that the first role features are characteristic of the first relationship role; assigning the second relationship role to the second member such that the second role features are characteristic of the second relationship role, such that the second member must confirm the second relationship role in order for the first member to be able to use the first relationship role in the network interaction between the first and second members; storing the first role and the second role with their associated role features in a storage as relationship data representing the relationship pair; and accessing the relationship data in order to determine whether a selected network interaction from one of the members is permitted in view of at least one of the corresponding relationship roles or role features of at least one of the first role or second role of the relationship pair, and facilitating the selected network interaction between the members when determined as permitted; wherein said at least one of the corresponding relationship roles or role features of at least one of the first role or second role of the relationship pair is used to define as permitted at least one of the network interaction type, the network interaction content, or the network interaction format.
- Exemplary embodiments of the invention will now be described in conjunction with the following drawings, by way of example only, in which:
-
FIG. 1 is a block diagram of a relationship network environment; -
FIG. 2 shows a block diagram of an example computing device for implementing components of the system ofFIG. 1 ; -
FIG. 3 shows example interactions between members in the relationship management system of the system ofFIG. 1 ; -
FIG. 4 shows an example claim of the environment ofFIG. 1 ; -
FIGS. 5 a,5 b, 5 c show example relationship pairs of the members ofFIG. 1 ; -
FIG. 6 shows example member roles of the members ofFIG. 1 ; -
FIG. 7 shows an example relationship gate of the system ofFIG. 3 ; -
FIG. 8 shows a relationship matrix used by the relationship gate ofFIG. 3 ; -
FIG. 9 is a further embodiment of the gate ofFIG. 8 ; -
FIG. 10 is an example operation of the gate ofFIG. 9 ; -
FIG. 11 is an example of banding of the relationships ofFIG. 1 ; -
FIG. 12 a is a further embodiment of the relationships ofFIG. 1 ; -
FIG. 12 b is an example modification of the relationship ofFIG. 12 a; -
FIG. 13 shows an example configuration of the administration system ofFIG. 1 ; and -
FIG. 14 shows an example operation of the administration system ofFIG. 13 . - Referring to
FIG. 1 , relationship and security in online social and professional networks and communities is provided by arelationship environment network 10. Thenetwork 10 provides for members 20 (i.e. registered users) and non-members 24 (i.e. unregistered users) of arelationship administration system 26 to connect/communicate 14 over acommunications network 11 with each other in ways that enhance their real world relationship, such that their online accounts (relationship data 15, otherwise known as a configuredrelationship matrix 15 for the plurality ofmembers 20 and their optionally assignedrelationship roles 12 a,b) share information electronically and the members/non-members relationship administration system 26. It is recognised that bothmembers 20 and non-members 24 will hereafter be referred to generically asmembers 20 for the sake of simplicity, such thatmembers 20 can be of a type registered or unregistered (i.e. non-members). Theadministration system 26 provides for a plurality ofdefined relationship pairs 12 assigned to selected pairs ofmembers 20 to adapt and change over time through amendment in the one ormore relationship roles 12 a,b (or to their commonly assigned relationship features 18 that are not assigned to anyparticular role 12 a,b) assigned to themembers 20 for representing any changes in the professional and/or personal relationship(s) between themembers 20 with each other over time, as facilitated by relationship pair aggregation further described below. - It is also recognised that the
term member 20 can be assigned to a single user and/or a group (e.g. two or more users) by theadministration system 26, such that any individual of the group can use thegroup member 20 as a conduit to electronically interact with other group and/orindividual members 20 via thenetwork 11. For example, agroup member 20 can be a number of individual doctors working together in the same clinic and anindividual member 20 can be a sales representative connecting with and making appointments with thegroup member 20 as a customer of the sales representative (e.g. for selling medical supplies for the group individuals as a whole). It would be up to the individuals of thegroup member 20 to arrange amongst themselves who would be meeting the sales representative at the arranged time/place of the appointment, as the sales representative would not be concerned with whom of the individuals of thegroup member 20 attend the appointment—just that at least one of the group individuals would be available and make able to make/relay decisions concerning buying of medical supplies. - The
administration system 26 could consider thegroup member 20 as adistinct member 20 of therelationship environment 10, realizing that any of the individuals of thegroup member 20 would have the same capabilities/features/privileges 18 and can use thegroup member 20account 15 to interact 14 withother members 20. Alternatively, theadministration system 26 could consider thegroup member 20 as adistinct member 20 of therelationship environment 10, realizing that certain individuals of thegroup member 20 would have slightly differing defined capabilities/features/privileges/restrictions 18 (e.g. defined individuals when signed on as thegroup member 20 would only be able to view 14 appointments but not to confirm 14 them) when using thegroup member 20account 15 to interact withother members 20 associated with therelationship administration system 26. - One example application of the
network 10 and associatedadministration system 26 is for the healthcare industry, which can be characterized as having a particularly fragmented with a workforce—fromphysicians 20 tonurses 20 to practiceadministrators 20—that are extremely busy in their day to day activities. Day to day work in industry can also be highly irregular and unpredictable, and with so many different parts working in isolation there are limited opportunities for people to be exposed to one another. All of this makes it very difficult forindustry professionals 20 to get intouch 14 with who they want when they need to, to stay intouch 14 withcolleagues 20 andco-workers 20 within and/or between different industries, and to coordinateproductive interactions 14 with each other. Accordingly, the ability to coordinate 14 meaningful and expectedonline relationships 12 betweenmembers 20, in particular the evolution of relationships betweenmembers 20 in a flexible and transparent manner is desirable, as further discussed below. - The
relationship administration system 26 can be a web-based service/application, accessible by browser applications of themembers 20, and can provide a medium for the community ofmembers 20 for people (in healthcare and other industries) to electronically (i.e. online) find 14 and connect 14 with peers and/or non-peers, electronically communicate 14 and exchange ideas betweenmembers 20, and electronically coordinate interactions 14 (both online and in person, for example) betweenmembers 20; so thatcommunity members 20 can develop business networks (for example in conjunction with different types of friendships), build knowledge, and/or engage in purposefulproductive relationships 12 outside of their immediate business environment. It is recognised that the electronic communications/connections 14 between themembers 20 are conducted in the framework of thedefined role pairs 12, for example, and the associated features/capabilities 18, as coordinated by theadministration system 26 further discussed below. - Referring to
FIGS. 1 and 4 , an example of therole pair 12 is Vendors (role 12 a) who use thesystem 26 to have access to customerrelationship management tools 30 that let them, as companies or as individual representatives with companies, reach out and connect 14 directly to target their Customers (role 12 b) for their proffered goods and services. Themanagement tools 30 provide themembers 20 with different types ofconnection 14 options with one another over thenetwork 11. Thesystem 26 provides features that support thevendor 20 and thecustomer 20 in buildingnew relationships 12, in enhancing/evolving existingrelationships 12, and in enabling electronic communication, coordination, andvalue exchanges 14 between the assignedroles 12 a,b of therole pair 12. - In economics, economic output can be divided into goods and services. When an economic activity yields a valuable or useful thing, it can be known as production output of the totality of products (e.g. goods or services) in an economy that the
vendor 20 makes available 14 for use by thecustomers 20. Products as goods can range from a simple safety pin, food, clothing, computer components to complex aircraft. Products as services are the performance of any duties or work for another (e.g. helpful or professional activity) and can be used to define intangible specialized economic activities such as but not limited to: providing access to specific information; web services; transport; banking; legal advice; accounting advice; management consultant advice; and medical services. Thevendor 20 providing the products can be a businessperson/individual engaged in wholesale/retail trade, an organization, an administration, and/or a business that sells, administers, maintains, charges for or otherwise makes available product(s) that are desirable by thecustomers 20. Accordingly, thevendor 20 can be one person, or an association of persons, for the purpose of carrying on some enterprise or business; a corporation; a firm; etc. Further, it is recognized that the offered 14 (electronically and/or in person) products/services can be applied tovendor 20 activities not related to specific product(s), for example activities such as customer service, community activities, and/or sponsorships. These general activities of thevendor 20 are also considered as part of the definition ofvendor 20 products. - It will be understood that for the purposes hereof, the
customer 20 may be any user (i.e. first hand product experience) ofvendor 20 products (e.g. goods and/or services). For example, thecustomer 20 may be an individual who purchasesvendor 20 goods and/or services for personal use, and not for resale or for use in the production of other goods and/or services for resale. Or thecustomer 20 may be abusiness purchasing vendor 20 goods and/or services for use in its business, i.e., for resale or for use in the production of other goods and/or services for resale. Further, it is recognized thatcustomer 20 may not purchase the goods and/or services. For example, thecustomer 20 may have acquire the goods and/or services pursuant to a free trial offered by thevendor 20. - Any business or organization can be called an enterprise, while consumers are individuals or households that purchase and use goods and services generated within the economy. It is recognized that both enterprises and consumers can be included in the definition of
customers 20. For example, the definition of B2C (Business-to-Consumer) is used to define the interaction between a business/vendor 20 (e.g. enterprise) that sells products or provides services to end-user consumers (e.g. customers 20). Further, for example, Business-to-Business (B2B) can be used to represent for relations between enterprises (e.g. between abusiness vendor 20 and a business customer 20), contrary to relations between enterprises and other groups (e.g. customers, public administration). The term B2B can be used to define marketing activities as well as electronic communication relations between enterprises. For example, B2B-Marketing can be used to describe all products and services used by enterprises. B2B marketing can be considered more complex than B2C marketing because on the buyer's side, there can be more than one person involved in a B2B sale/purchase, the buying center. - Accordingly, it is recognized that the
customer 20 can be a private individual desiring information/purchase (e.g. B2C) of thevendor 20 products or can be a person, or an association of persons, for the purpose of carrying on some enterprise or business (e.g. a corporation, a firm, etc.) that desires infonnation/purchase (e.g. B2B) of thevendor 20 products. It is recognized that thecustomer 20 can communicate 14 with thevendor 20 as a potential purchaser (i.e. window shopping) or as an intended purchaser of the vendor's 20 products, as desired. - When two or
more members 20 are engaged in one or more relationship pairs 12 (active and/or passive), thesemembers 20 interact 14 with each other on the administration system 26 (via the network 11) in accordance with their relationship pair(s) 12 and their respectiveoptional roles 12 a,b themembers 20 have in those relationship pair(s) 12. It is recognised that between any pair ofmembers 20, a plurality of distinct types ofrelationship pairings 12 can be assigned to them, which facilitates the evolution of their overall online relationship with one another. For example, any twomembers 20 can first start off with being the role ofassociates 12 a,b in an associate based relationship pair 12 (having associate features/capabilities 18 a,b for coordination of the various connections/actions 14 enabled by the associate basedrelationship pair 12. At a later date, the twomembers 20 then add (e.g. aggregate) being the role of customer-vendor 12 a,b in a customer-vendor basedrelationship pair 12 having customer or vendor based features/capabilities 18 a,b for coordination of the various connections/actions 14 enabled by the customer-vendor basedrelationship pair 12. In other words, themembers 20 now have a general relationship with one another that is a combination of associate/customer 12 a or associate/vendor 12 b with one another and therefore all of the features/capabilities 18 a,b assigned to eachmember 20 is a combination of associate/customer 18 a or associate/vendor 18 b, as further described below with respect to relationship banding and relationship aggregating. Therelationship matrix 15 is used as a memory construct/database (e.g. table, chart, etc.) for defining/storing all of the features/capabilities 18 a,b,roles 12 a,b, and/or all thepossible interactions 14 betweenmembers 20 over thenetwork 11. - It is also recognised that as an alternative embodiment the defined online existing
relationship 12 between afirst member 20 and asecond member 20 can be defined by a plurality of existing relationship features 18 for use in managingnetwork interaction 14 on thecommunications network 11 between thefirst member 20 and thesecond member 20. The relationship features 18 are characteristic of therelationship 12, such that at least one of the corresponding relationship features 18 of therelationship 12 is used to define as permitted at least one of thenetwork interaction 14 type, the network interaction content, or the network interaction format. It is recognised that the relationship features 18 can be between thefirst member 20 and the second member 20 (i.e. each of themembers 20 do not have a definedrelationship role 12 a,b, in the relationship 12). Or, as further discussed above, it is recognised that a first portion of the relationship features 18 a characterizes thefirst relationship role 12 a and a second portion of the relationship features 18 b characterizes thesecond relationship role 12 b of therelationship pair 12, such that thefirst relationship role 12 a and thesecond relationship role 12 b are part of the relationship defined as therelationship pair 12 between the first andsecond members 20. In other words, theaggregate relationship pair 12, described above by example only, can be administered by theadministration system 26 as arole-less relationship 12, such that the relationship features 18 are shared between themembers 20 for managing their inter-member 20interactions 14, or can be administered as a roled 12 a,b relationship pair 12, such that each of theroles 12 a,b have characteristic role features 18 a,b. - Referring to
FIG. 8 , anypossible interaction 14 that can occur between twomembers 20 can be defined and therefore enabled/disabled in therelationship matrix 15 via therespective features 18 and the actual implementation of theinteraction 14 is assessed (through reference to the matrix 15) and either accepted or declined by theRelationship Gate 150. Therelationship matrix 15 is therefore available (locally or remotely over the network 11) to theRelationship Gate 150, to maintain an understanding of theroles 12 a,b inside of the assigned relationship pairs 12 in affect (e.g. active and/or passive) at any point in time betweenmembers 20 - The feature or
capabilities 18 a,b available betweenmembers 20 can include such as but not limited to: information visibility/sharing 14 (via profiles, searches, contact records, etc.); notifications and updates 14;communications 14;Events Coordination 14;Interactions 14 Online andCoordination 14 of Interactions Offline; Preferences for the features/capabilities 18 a,b (i.e.limited member 20 specific customization of the general features/capabilities 18 a,b available under the role(s) 12 a,b); and Relationship views 14. - Further, it is recognised that the
matrix 15 is used by therelationship gate 150 to determine whether or not anaction 14 initiated by themember 20 with respect to another member 20 (e.g. send a meeting request for sales call) will be completed as an allowable Relationship Interaction 14 (as defined by the features/capabilities roles 12 a,b), or whether theaction 14 is halted because it cannot occur (i.e. the desiredaction 14 is not compatible with one or both of the feature/capability sets 18, 18 a,b of the member(s) 20. - Further, it is recognised that the
administration system 26 can provide feedback communication to the requestingmember 20 if theaction 14 resulted in no Interaction (e.g. not allowed). Also, it is recognised that theadministration system 26 can provide feedback communication to the requestingmember 20 if theaction 14 resulted in Interaction (e.g. allowed). Also, it is recognised that theadministration system 26 can provide feedback communication/notification to the intendedrecipient member 20 of theaction 14 if it resulted in no Interaction (e.g. not allowed). Also, it is recognised that theadministration system 26 can provide feedback communication/notification to the intendedrecipient member 20 of theaction 14 if it resulted in Interaction (e.g. allowed). - Referring again to
FIG. 8 , the capabilities/features/privileges/restrictions 18 a,b (hereafter referable asfeatures 18 for the sake of simplicity) are grouped as associated/assigned to the respectiveindividual relationship role 12 a,b, for example. For example, a first role type RT1 would have a set/group of assigned features F1,F2,F3,F4,F5,etc. and a second role type RT2 would have a set/group of assigned features F1,F3,F4,F6,F7,etc. It is recognised that the sets/groups of assigned features 18 can have someindividual features 18 in common (e.g. overlapping sets/groups of features 18), however each set/group offeatures 18 as a whole is unique infeature 18 content to the respective role type 12 a that they are assigned. In this manner, theadministration system 26 can facilitate that a first role type RT1 has a unique first set of assigned features 18 and therefore cannot be confused with a second role type RT2 having a unique second set of assigned features 18, such that the first and second set offeatures 18 are not identical. For example, therole type 12 a of a Colleague would have different set offeatures 18 than that of a Vendor, otherwise a Colleague could be confused for a Vendor duringinteractions 14 over thenetwork 11 as defined by the particular role features 18 set that is unique to the particular role type 12 a. - It is also recognised that some
features 18 can be superseded byother features 18, either in whole or in part (e.g. to take the place of such as replace or to augment so as to make an already assignedfeature 18 greater/lesser in size, extent, or influence), during aggregation of relationship pairs 12 and theircorresponding roles 12 a,b and features 18 a,b, as further described below with respect to aggregate relationship pairs 6 (seeFIG. 9 ). - Referring again to
FIG. 1 ,members 20 via theadministration system 26 can connect 14 with each other in ways that represent their real world trusted relationships, includingnonmember 20 interactions. It is recognized that the following discussedmember 20 interactions 14 (as facilitated/defined through the features/capabilities 18 a,b that are shared between members of therelationship pair 12 and/or are associated with the role types 12 a,b of the relationship pair 12) is for exemplary purposes only, recognizing thatnonmembers 20 can and will have at least some of the features/capabilities 18 a,b that are appropriate to theirbase relationship profile 12 a (e.g. public) recognized by thesystem 26. - Referring to
FIGS. 1 and 6 , the types of relationships (i.e.role 12 a,b of the defined role pair 12) that member 1 (M1) is in with other members (Mn), and theadministration system 26 connection relationships that a M1 has with a specific member (M2), will impact: the information M1 can enter 14 into therelationship data 15 about themselves; the information M1 is able to share 14 about themselves, and who they're able to share it with; the features/capabilities 18 amember 20 is able to use in their defined role(s) 12 a,b; the features/capabilities 18 M1 is able to use when interacting with Mn; the ability for M1 to join a Group; the types of requests/responses 14 that the member M1 can have over thenetwork 11; and/or theresults 14 of any searches member M1 executes 14. Further, the relationships that a person may be dependent on factors such as: therole pair 12 assigned to themember 20; service package(s) purchased or otherwise acquired 18 by themember 20 as facilitated by thesystem 26; and organization type and relationship of the organization with thesystem 26. For example, inFIG. 6 member M1 (via their defined two role pairs 12 of customer-vendor and colleague-colleague) can communicate 14 (as enabled/defined through their various features/capabilities 18 as share and/or as assigned 18 a,b torespective roles 12 a,b) with member M2 being both afellow colleague 12 a and arespective customer 12 a of member M1 (being acolleague 12 a andvendor 12 b). For example, member M1 and member M2 can interact 14 with each other ascolleagues 12 a by sharing 14 their in-office calendars (e.g. showing both personal and business activities) as well as placing 14 and accepting 14 orders respectively for particular beauty products (i.e. member M1 is a part-time vendor of skin creams and candles). - Member M1 can also communicate 14 with
other vendors 12 b (defined by the system 26) of the members Mn (for example other part-time vendors of skin creams) to find out whether their customers may be interested in their products (i.e. candles) and to make an introduction/referral 14 to themember Mn customers 12 a. This is an example where member M1 has anactive relationship role 12 of customer-vendor and colleague-colleague with member M2 and member M2 haspassive relationship roles 12 a,b of vendor-vendor with other members Mn. It is recognised that the system 26 s (and enforce via therelationship gate 150 seeFIG. 7 ) the various capabilities/features 18 b of thevendors 12 b differently for the above-described role pair customer-vendor 12 and vendor-vendor 12. For example, member M2 could offer 14 their products for sale to member M1 with the ability to provide 14 order forms and invoicing. However, member M2 could not do thesesame interactions 14 with member Mn, rather member M2 could only perform with member Mninitial contact 14 andrequest 14 introductions to thecustomers 12 a of the member Mn. On the other hand, members M2 and Mn could decide to enter into customer-vendor relationships 12 and then member M2 would gain the additional vendor features/capabilities 18 b commensurate with members Mn being theircustomer 12 a. - It is recognised that the content (e.g. text, image, video, enclosures, message type (email, telephone, text message, etc.), message enclosures, content size/amount/length) and/or format (e.g. form of the content such as colour, font style, message priority, etc.) of the
interactions 14 can be defined and their generation by themember 20 coordinated by the associated features/capabilities 18 (e.g. of therole 12 a,b) that themember 20 is using/operating under on theadministration system 26 with selected (active and/or passive)other members 20. It is also recognised that the content and/or form of theinteractions 14 can be defined using a combination ofdifferent roles 12 a,b and/or their associatedfeatures 18 a,b in view of aggregation of relationship pairs 12, further described below. - In general, when a member (M1) initially connects 14 with another member (M2) via the
system 26, M1 can choose the type or types of relationships (e.g. the role pair(s) 12) they are connecting to M2 in. These relationship role types can include defined role pairs 12 such as but not limited to: -
Business Relationship Communi- Information Interac- Exchange Management Relationship Trust level cations 14 Sharing 14tions 14Info 14Capabilities 14Blocked None None None None None None Public (default) Minimum Minimum Minimum None None None Associate to Low Low Minimum None None None Associate Colleague to High High High High Low Low Colleague Customer to Medium Medium Medium High High High Vendor/Vendor to Customer Student to Medium Medium Medium High None Low Teacher/ Teacher to Student Co-Worker to Medium Medium Medium Medium Medium Med Co-Worker - A number of
interactions 14 are impacted by relationships features/capabilities 18 of the defined role pair(s) 12 between themembers 20, including for example with respect to booking of appointments/meetings and the contents/substance of the meetings: -
- Ability to input 14 available Time for appointments/meetings as visible on their
online profile 9; -
Available Time Viewing 14 andBooking 14 for appointments/meetings as visible on theironline profile 9; - Sample requests 14 as visible on their
online profile 9; - Product input and
display 14 as visible on theironline profile 9 or otherwise sent incommunications 14 to their member of therole pair 12; -
Territory Management 14; - Call
Management 14; - Call
Mapping 14; -
Auto Call Booking 14; and/or -
Auto Rebooking 14 of Calls.
- Ability to input 14 available Time for appointments/meetings as visible on their
- Referring to
FIG. 1 , the AVAILABLE TIME PROCESS allowsmembers 20 who are connected with each in a VENDOR (i.e.role 12 b) and CUSTOMER (i.e.role 12 a) relationship (i.e. role pair 12) to coordinate theirinteractions 14 so as to facilitate sales calls and meetings that are more predictable and productive than the current prior art systems. The process enables CUSTOMERS to identify 14 when they have AVAILABLE TIME (either MEETINGS or FLEX CALLS) for VENDORS to visit. - For MEETINGS, the CUSTOMER simply sets up 14 when he wants a VENDOR to come (e.g. 10 to 10:15 am on Wednesday or 12:30 to 1:30 pm for lunch on Thursday.) FLEX CALLS are periods of time that the CUSTOMER has indicated they will accept a number of drop-in calls (e.g. between 1 pm and 3 pm on Fridays they would accept up to three FLEX CALLS.), as visible on their
online profile 9. - Only
members 20 who are connected to a CUSTOMER as a VENDOR can see 14 AVAILABLE MEETINGS and/or AVAILABLE FLEX CALLS as visible on theironline profile 9. VENDORS who want to BOOK 14 any OPEN MEETINGS or FLEX CALLS will do so on a first come first serve basis, and in accordance with any preferences designated by the CUSTOMER as visible on theironline profile 9. - Only one VENDOR may be able to BOOK 14 a single MEETING. Once booked, the AVAILABLE MEETING is BOOKED and may be not visible to other VENDORS for booking. (Note that a VENDOR or CUSTOMER can CANCEL the meeting, which could reopen the AVAILABLE MEETING to be booked by a different VENDOR.
- Multiple VENDORS can book 14 calls during an AVAILABLE FLEX CALL period as visible on the CUSTOMER'S
online profile 9. The number is limited by the maximum specified by the CUSTOMER. A FLEX CALL that has been BOOKED by a VENDOR is a period when they will be expected to drop in to see the CUSTOMER. Thesystem 26 can divide the FLEX CALL period into a number of set length (and overlapping, if needed) windows. VENDORS who book a FLEX CALL book a specific window, and this distributes the bookings and reduced situations where multiple VENDORS call on a CUSTOMER at the same time. - The specific time within the AVAILABLE FLEX CALL TIME when the call is to be made is up to the VENDOR. This enables them to choose 14 a time that works best with their schedule, but also provides flexibility to the CUSTOMER who has no obligation to maintain an exact meeting time, as input and then made visible on their
online profile 9. Also, the actual discussion produced with a FLEX CALL has no set length, and will be something that works for the VENDOR and the CUSTOMER. - Only
system 26 USER TYPES that are in the CUSTOMER class of user types can create 14 AVAILABLE TIME. Further, onlysystem 26 Users who are a VENDOR CONTACT (i.e. part of the role pair(s) 12 defined between the VENDOR and CUSTOMERS) of these CUSTOMERs can view 14 the AVAILABLE TIME as visible on the CUSTOMERonline profile 9 to book it. - A VENDOR can view 14 a CUSTOMER's calendar on their
online profile 9 to find and BOOK any OPEN (not booked) AVAILABLE FLEX CALL WINDOWS. Each FLEX CALL WINDOW will have a start time and an end time (usually 60 minutes apart.) - Only the VENDOR or a CUSTOMER can see and
book 14 the AVAILABLE FLEX CALLS on theonline profile 9 for the CUSTOMER, as defined and enabled via their definedrole pair 12. To other member types (such as colleagues, co-workers, etc) the time where an AVAILABLE FLEX CALL can appear 14 on the member'sonline profile 9 to be BUSY time, whether the call is BOOKED or OPEN. (This is because the CUSTOMER is saying this time is booked for my VENDORS, and is therefore expected to be booked.). Accordingly, it is recognized that the onlinevisible profile 9 of anyparticular member 20 to anyother member 20 is influenced by the role pair(s) 12 defined between therespective members 20. - Once a FLEX CALL WINDOW maximum booking number (BWmax) is reached, that window is considered FULL and is not viewable by VENDORS other than those that have booked it. For both AVAILABLE MEETINGS and for AVAILABLE FLEX CALLS, the
system 26 can permit the CUSTOMER to setPREFERENCES 18 for the calls. ThesePREFERENCES 18 can take the form of: -
- Capability to set PREFERRED VENDORS, PREFERRED VENDOR ORGANIZATIONS, PREFERRED PRODUCT INTERESTS, etc;
- Frequency that any one VENDOR can BOOK an AVAILABLE MEETING;
- Frequency that any one PREFERRED VENDOR can BOOK an AVAILABLE MEETING;
- Frequency that any one VENDOR can BOOK an FLEX CALL;
- Frequency that any one PREFERRED VENDOR can BOOK an FLEX CALL;
- Frequency that any one VENDOR ORGANIZATION can BOOK an AVAILABLE MEETING;
- Frequency that any one PREFERRED VENDOR ORGANIZATION can BOOK an AVAILABLE MEETING;
- Frequency that any one VENDOR ORGANIZATION can BOOK an FLEX CALL;
- Frequency that any one PREFERRED VENDOR ORGANIZATION can BOOK an FLEX CALL;
- Frequency that any one VENDOR that is discussing a specific PRODUCT can call; and/or
- Some AVAILABLE TIMES can be designated for specific PRODUCTS. (This can be put in the notes, but the TRApp can also support this by confirming the product type of the VENDOR.
- The
system 26 can also facilitate the capability to support multi CUSTOMER calls, and allowing multiple VENDORS to book 14 the same FLEX CALL PERIOD. This would be an event situation. CUSTOMERS can also customize the FLEX CALLS to have FLEX CALL WINDOWS of any length. (e.g. 60 minutes in length, except when the entire AVAILABLE FLEX CALL DURATION is 30 minutes when the window can also be only 30 minutes. - Referring to
FIGS. 1 and 3 , control and transparency of allconnection relationships 12 in thenetworked environment 10 promotesmember 20 confidence ininteractions 14.Members 20 know who they're connecting 14 to, how they're connecting 14 to them, how they're being seen 14 byother members 20 they're connected to, and exactly what it means to be connected 14 to anothermember 20 in aspecific relationship pair 12. - Further,
members 20 have control of theirrelationships 12, just like they have in real life. It's not a one size fits all world and, in business, people havedifferent relationships 12. theadministration system 26 provides for this, for example through pairedrelationship roles 12 a,b, lettingmembers 20 decide whatrelationship role 12 a,b of a pairedrelationship 12 they want to have with anothermember 20. The pairedrelationship roles 12 a,b (and optionaldirectional relationships 12, further described below) can provide that, when amember 20 engages 14 in anonline relationship 12 with anothermember 20, they know therole 12 a,b they play in the relationship and thecorresponding role 12 b,a the connected (of the relationship pair 12)member 20 plays. If a pair ofmembers 20 who are in only one customer-vendor relationship 12, then one of themembers 20 must be thevendor role 12 b and one must be thecustomer role 12 a. Example, in a colleague-colleague relationship pair 12 or in a customer-vendor relationship pair 12, it's clear to both sides exactly whatrole 12 a,b eachmember 20 is playing. For example, I can't be someone'svendor 20, and not have them be mycustomer 20. - The
relationship environment network 10 provides a social network to themembers 20, by enablingmembers 20 to connect to each other in ways that represent their real world business relationships using defined relationship pair(s) 12, including within thepairs 12example roles 12 a,b such as but not limited to: as an associate; as a colleague; as a co-worker; as a customer; as a vendor; etc.Selected roles 12 a,b are compatible with other selectedroles 12 a,b and other selectedroles 12 a,b are not compatible withcertain roles 12 a,b, as further described below (for example, arole 12 a of vendor may not be compatible with the features/capabilities 18 of arole type 12 b of colleague, while arole 12 a of vendor would be compatible with the features/capabilities 18 of arole type 12 b of customer). It is recognised that each of the associatedroles 12 a,b of therole pair 12 includes a plurality features/capabilities 18 that are defined by theadministration system 26, as further discussed below. Once connected via thesystem 26,members 20 users of theadministration system 26 communicate, share information, and/or coordinate interactions viacommunications 14 with each other in accordance with their professional and/or person relationship defined by their role(s) 12 a,b with each other in the role pair(s)/pairing(s) 12. It is recognized that thecommunications 14 can consist of messages (e.g. SMS messages, texting, emails, phone calls, etc.) sent to one another, as well as viewing the online profiles 9 (e.g. system 26 Web page showing the profile of themember 20 with user name, interests,other member 20 connections, hobbies, etc.) of themembers 20. - Some relationships require both
members 20 to be in thesame role 12 a, such as in a Colleague toColleague relationship 12. Other relationships, such as Customer toVendor relationships 12, require each user to have adifferent role 12 a,b. - Referring to
FIGS. 5 a,b,c, in anyrelationship pairing 12, there can be tworelationship roles 12 a,b that may be of the same or different role types. InFIG. 5 a M1 is thecolleague 12 a and M2 is also thecolleague 12 a, such that bothmembers 20 M1 to M2 want to be Colleagues so both users must play the role of aColleague 12 a in this Colleague toColleague relationship 12. InFIG. 5 b M1 is thecustomer 12 a and M2 is thevendor 12 b, such that the twomembers 20 M1 and M2 want to be in a Customer toVendor relationship 12 where M1 plays theCustomer role 12 a and M2 plays theVendor role 12 b. InFIG. 5 c M1 is thecustomer 12 a and M2 is thevendor 12 b for onerelationship pair 12 and M1 is thevendor 12 b and M2 is thecustomer 12 a for anotherrelationship pair 12′ that they have, such that the same M1 andM2 members 20 can also have a second Customer toVendor relationship 12′ where M2 plays theCustomer role 12 a and M1 plays theVendor role 12 b. - A
relationship role 12 a,b is the specific capacity amember 20 takes when acting in asystem 26 supportedrelationship 12 with anothermember 20 who has a specific counter/associatedrole 12 a,b to thatrelationship pairing 12. It is recognised that the capabilities and features 18 between two pairedroles 12 a,b may not be the same. For example, in a Customer toVendor relationship 12, one user must always be therole 12 a ofCustomer 20 while the other user must always be therole 12 b ofVendor 20, since thecustomer 20 is the one who asks questions about and purchases items from thevendor 20, while thevendor 20 is the one that provides answers about products and facilitates sale of their products. Theadministration system 26 would define (via the matrix 15) and can assign of theallowable features 18 a,b specific to the assignedrole 12 a,b of therole pair 12. In other words, for example, thecustomer 20 would not have (i.e. thematrix 15 would not enable thesefeatures 18 b for thecustomer role 12 a) thevendor 12 b type features 18 b of offering 14 products for sale and invoicing 14 for same over thenetwork 11 with the vendor 20 (since that is what avendor 20 does), while at the same time thevendor 20 would not have (i.e. thematrix 15 would not enable thesefeatures 18 a for thevendor roles 12 b) thecustomer 12 a type features 18 a of requesting 14 product information and paying 14 invoices for purchased products over thenetwork 11 with the customer 20 (since that is what acustomer 20 does). Accordingly, in this case, it is clear that aparticular member 20 can only be thecustomer role 12 a withcorresponding features 18 a when paired to theparticular member 20 who is the correspondingvendor 12 b role with correspondingfeatures 18 b, for the relationship pairing 12 of customer-vendor for the pairedmembers 20. It is also recognised that thefeatures 18 of a selectedrelationship pair 12 can be shared between themembers 20 of thatrelationship pair 12 in arole-less relationship pair 12. - For example, referring to
FIG. 3 , thesystem 26 provides a plurality of predefined role pairs 12 for selection by each of the members 20 (e.g. a plurality of different defined role pairs 12 havingrespective role 12 a associated withrole 12 b, such that each of the defined role pairs 12 have assigned respective different feature/capability sets 18) that can be assigned to any particular pair of themembers 20. Therefore, each of the defined role pairs 12 has list of available features/capabilities 18 that are associated with theparticular role pair 12, forexample role 12 a ofrole pair 12 has a list of features/capabilities 18 a that is compatible with the list of features/capabilities 18 b of therole 12 b of therole pair 12. It is recognized that the features/capabilities 18 a may or may not be exactly the same as the features/capabilities 18 b, i.e. may be different for eachmember 20 of thepair 12 such as for vendor-customers, student-teacher, etc. This is different from the case where theroles 12 a are the same/equal such as for colleague to colleague, friend to friend, member to member. In the case where the features/capabilities 18 a are the same, this could be where therelationship role pair 12 has twoequal roles 12 a (e.g. public to public, friend to friend, colleague to colleague). In the case where the features/capabilities 18 a,b are not the same, this could be where therelationship role pair 12 has two associateddissimilar roles 12 a,b (e.g. vendor to customer, student to teacher), however, it is recognized that the dissimilar features/capabilities 18 a,b would be compatible with one another as defined by therole pair 12. It is also recognised that the features/capabilities 18 a,b assigned to theroles 12 a,b can be directional, such that there may be more assigned features/capabilities 18 a for therole 12 a as compared to the that the features/capabilities 18 b assigned to therole 12 b of therole pair 12, as further described below. - The features/
capabilities 18 assigned to theroles 12 are reflected in type ofconnections 14 that can be initiated (and responded to) by themembers 20 in their relationship role(s) 12, An example of this is where thefirst member 20 having therole 12 a could be a vendor and be able to sendvendor communications 14 listing products/services for sale, while thesecond member 20 having the pairedrole 12 b of a customer would be able to receive 14,view 14, and respond 14 to the original vendor communications 14 (e.g. order to buy offered products/services), i.e. the members are in a Vendor-Customer role pair 12 relationship, as defined in thesystem 26. It is recognized that the customer would not be able to sendvendor communications 14 to the vendor and the vendor would not be able to placeorders 14 to the customer, in this case, unless themembers 20 had theirrelationship role data 15 defining both a Vendorp-Customer role pair 12 and a Customer-Vendor role pair 12 between them, such that each member is both a customer and a vendor with respect to theother member 20 of their defined role pair(s) 12. - It is also recognized that for an
active relationship 12 in theadministration system 26, both sides of therelationship pair 12 can be cognizant of the assignedroles 12 a,b of theirother member 20 of theirmember pair 12, i.e. a vendor knows who their customer is and the customer knows who their vendor is and each is knowledgeable of the features/capabilities 18 of theothers role 12. In other words, afirst member 20 cannot hide the fact from asecond member 20 that themembers 20 have defined anddissimilar roles 12 a,b that are compatible with one another (e.g. a customer of a vendor knows that they are identified in thesystem 26 as the customer of the respective vendor and the vendor of the customer knows that they are identified in thesystem 26 as the vendor of the respective customer. It is also recognized that each of themembers 20 can have a plurality ofdifferent roles 12 a,b (of respective role pairs 12) with the same and/or different member(s) 20, such that each of the role pairs 12 (active and/or passive) have an inbound and an outbound role connection (i.e.directional roles 12 a,b) to theother member 20 associated in therole pair 12. - For example, a
first member 20 signs onto thesystem 26 and provides a user role/profile 12 a (e.g. their profession, their specialty, their country, hobbies, and any other personal defining information). Thefirst member 20 may also set up with thesystem 26 certain definedroles 12 a,b that may or may not have accepted member pair relationships 12 (e.g. thefirst member 20 can have avendor role 12 b with a confirmed/acceptedcustomer role 12 a with asecond member 20 that defines anactive pair relationship 12, and/or thefirst member 20 can register with thesystem 26 as avendor 12 b of a specific product/service and therefore haveinformation 14 available toother members 20 as passive pair relationships 12). Thesystem 26 can use the user role definitions/parameters 18 b as well as any definedroles 12 b as set up by thefirst member 20 to provide for both active and passive exchanges ofinformation 14 between the first andsecond members 20. For example, in the case where thefirst member 10 is a general physician and thesecond member 10 is a vendor for office medical supplies, thesystem 26 would use the user role/profile 12 a of general physician and the definedvendor role 12 b to inform thefirst member 20 of thesecond member 20 as a potential supplier/vendor 12 b of medical supplies and thesecond member 20 of thefirst member 20 as apotential customer 12 a of theirvendor role 12 b. The mappings between potential role pairs 12 (i.e.customer 12 a withvendor 12 b) as well as for acceptedpairs 12 can be monitored/maintained by therelationship matrix 15, as further described below. - Therefore, providing
members 20 control over the connection types (relationship role pair(s) 12) they have withother members 20 provides they feel secure in that definedrelationship 12. It is recognized that therelationship administration system 26 can have one or more default role pairs 12 that can be assigned tononmembers 20 trying to communicate 14 with one or more members/nonmembers 20 via thesystem 26. For example, eachnonmember 20 can be recognized as having apublic role profile 12 a when trying to communicate via thesystem 26 with other members/nonmembers 20, who will also be associated with apublic role profile 12 a for facilitatingcommunications 14 via thesystem 26 with the non-member 20. - Example definitions of the
various roles 12 a,b available in the plurality of relationship pairs 12 is as follows. Associate is a person who shares actively in anything as a business, enterprise, or undertaking as a partner or fellow worker. Colleague is a fellow member of a profession, staff, or academic faculty. Friend is a person attached to another by feelings of affection or personal regard and is a person who gives assistance as a patron/supporter. Teacher is a person who teaches or instructs, as a profession as an instructor. Coworker is a fellow worker. Vendor is a person or agency that sells products/services. Customer is a person who purchases goods or services from another as a buyer/patron. Student is a person formally engaged in learning, especially one enrolled in a school or college as a pupil. Manager is a person who has control or direction of an institution, business, etc., or of a part, division, or phase of it. “Co” (e.g. co-manager, co-vender, etc.) is a fellow person with potentially the same business/personal duties as another person. Delegate is a person designated to act for or represent another or others, for example as a deputy/representative. Patient is a person who is under medical care or treatment. Provider is a person or thing that provides a service (e.g. healthcare related) to another person or thing. -
Directional Relationship roles 12 a,b - It is recognised that the
relationship pairings 12 can be non-directional and/ordirectional relationship roles 12 a,b and associated non-directional and/or directional relationship features/capabilities 18 a,b. For example, if twomembers 20 are in a customer-vendor relationship pair 12, it is possible for thosemembers 20 to engage in another customer-vendor relationship pair 20. In thefirst relationship pair 12, member M1 may be the vendor and member M2 may be the customer, while in the second relationship pair, member M1 may be the customer, and member M2 may be the vendor. In this case, M1 would only be enabled for thefirst relationship pair 12 for directional outgoing vendor interactions 14 (i.e. to customer) and incoming vendor interactions 14 (e.g. from customer) in terms of the available features/capabilities 18 b for avendor 12 b. As well, M1 would only be enabled for thesecond relationship pair 12 for directional outgoing customer interactions 14 (i.e. to vendor) and incoming customer interactions 14 (e.g. from vendor) in terms of the available features/capabilities 18 b for acustomer 12 a, for example. Further, M2 would only be enabled for thefirst relationship pair 12 for directional outgoing customer interactions 14 (i.e. to vendor) and incoming customer interactions 14 (e.g. from vendor) in teens of the available features/capabilities 18 b for acustomer 12 a. As well, M2 would only be enabled for thesecond relationship pair 12 for directional outgoing vendor interactions 14 (i.e. to customer) and incoming vendor interactions 14 (e.g. from customer) in terms of the available features/capabilities 18 b for avendor 12 b, for example. - Another way to think about it is that relationship pairs can be optionally directional, from one
role 12 a,b to the other. Therefore, the capabilities and features 18 a,b between twomembers 20 may not be the same, because the direction of therelationship pair 12 matters. For example, in a Customer toVendor relationship pair 12, onemember 20 must always be theCustomer role 12 a while theother member 20 must always be theVendor role 12 b. In this case, there is one Customer-Vendor relationship pair 12, but twoseparate Relationship Roles 12 a,b in that relationship pair 12: one Customer and one Vendor. This is talking to the fact that twopeople 20 can have to customer-vendor relationships 12, one in each direction, but that they can have different features/capabilities 18 a,b because theusers 20 may customize how the accept/broadcast thosefeatures 18 a,b. - Therefore, it is recognised that each
relationship pair 12 providescapabilities 18 a,b to themembers 20. Therelationship matrix 15 is in contact with theRelationship Gate 150, to maintain an understanding of theroles 12 a,b and relationship pair(s) 12 in affect at any point in time betweenmembers 20. - Each relationship between a pair of members 20 (e.g. member with member, member with non-member, or non-member with non-member) can consist of one or more relationship pairs 12 (e.g. a
first role 12 a of thepair 12 is assigned to onemember 20 of the member pair and an associated/complimentarysecond role 12 b of thepair 12 is assigned to theother member 20 of the member pair). It is recognized that there can be both passive (one of theroles 12 a,b of thepair 12 has not been formally accepted by one of themembers 20 of the member pair 12) and active relationships in the system 26 (i.e. both of theroles 12 a,b of thepair 12 have been recognized and accepted by eachmember 20 of themember pair 12—e.g. afirst member 20 of themember pair 12 registers with theadministration system 26 in one of theroles 12 a of thepair 12 and thesecond member 20 of themember pair 12 formally accepts arole invitation 14 from thefirst member 20 for theother role 12 b of thepair 12, as defined by the administration system 26). - Referring to
FIGS. 1 and 7 , there are two types of Relationship pairs 12: Activated/Active Relationships 12 and Inherent/Passive Relationships 12.Inherent relationships 12 can exist without themember 20 ormembers 20 having to do anything specific to engage or activate therelationship 12 between one ormore members 20 accessible by the member via the administration system 26 (e.g. via the relationship gate 150). For example, arelationship pair request 14 from afirst member 20 does not have to be received from and accepted by asecond member 20, in order to establish theinherent relationship pairing 12 and (and optionalassociate roles 12 a,b) between two ormore members 20. Therelationship pair 12 is automatically put in place by theadministration system 26 whenspecific member 20actions 14 occur that would enable the use of their inherent optional relationship role(s) 12 a,b and assignedfeatures 18 a,b or as their sharedfeatures 18 of therelationship pair 12.FIG. 7 shows how the twoinherent relationships 12 are always on. - Some inherent relationship pairs 12 include: a) Member (M) to Public (P) (which exists between any
member 20 and any non-member 20; b) Member (M) to Member (M) (which exists between everymember 20; and c) Family Health Team mate (FHT) to Family Health Team (FHT) mate (which exists between allmembers 20 of a specific family health team; - Further, activated Relationship pairs 12 are started by one of the
members 20 who wants to engage in the selectedrelationship pair 12. To start anactive relationship pair 12, onemember 20 Initiates a Handshake(request 14 to enter into the relationship pair 12) to a selectedother member 20 of theadministration system 26. By executing 14 the Handshake by theother member 20, theother member 20 activates the requestedrelationship pair 12 and therefore the requesting member assumes therole 12 a and the acceptingmember 20 assumes therole 12 b of therelationship pair 12 with the associated features/capabilities 18 a,b associated with theirroes 12 a,b. - It is recognised that Most relationships can be Activated Relationship pairs 12, including a plurality of
relationship pair 12 types such as but not limited to: Friend (F) to Friend (F); Associate (As) to Associate (As); Colleague (Co) to Colleague (Co); Coworker (Cw) to Coworker (Cw); Customer (Cu) to Vendor (V)/Vendor (V) to Customer (Cu); Student (St) to Teacher (Te)/Teacher (Te) to Student (St); Report (Re) to Manager (Mg)/Manager (Mg) to Report (Re); Delegate (Dte) to Delegator (Dtr)/Delegator (Dtr) to Delegate (Dte); CoVender to CoVender(CV); CoTeacher to CoTeacher(CT); CoManger to CoManager(CM); and Patient (Pat) to Provider (Pro)/Provider (Pro) to Patient (Pat), as shown inFIG. 7 asexample roles 12 a,b. - Therefore, when two members (assume M1 and M2) are in a
relationship pair 12 with each other, there are Passive and/orActive relationship interactions 14 that may take place within the features/capabilities 18 a,b (optionally associated with theroles 12 a,b) of therelationship pair 12 of the members M1,M2. For example,Active Interactions 14 can be triggered by anaction 14 taken by member M1 or M2, such as active interactions but not limited to: Vendors request to ‘view available time’ and see the available flex calls of their Customers; Vendors booking available time for a call, since only vendors can book available time; and amember 20 changing their contact information (e.g. mobile phone number), such that this change is then shared with all of his Colleagues. In terms ofpassive interactions 14, these can happen without member M1 or M2 triggering the specific interaction. Examples ofpassive interactions 14 are such as but not limited to: the capability for assuming M1 and M2 are colleagues; and a third member (M3) to see who M1 is and that they are connected as colleagues to M2. - In an
active exchange 14, there are connectingcooperative features 18 a,b between themembers 20. Everyfeature 18 a,b can have an entry way and an exit way. In anactive exchange 14, therelationship role 12 a of theInitiator 20 must be such that thefeature 18 a can ‘Fit’ to allow the initiation of the exchange 14 (e.g. create and send meeting request), and therelationship role 12 b of theReceiver 20 must be such that thecooperative feature 18 b will Fit the receiving end (e.g. receive and accept/decline meeting request) of theexchange 14. - It is recognised that whether or not a
relationship pair 12 can exist, is available to start, and/or is maintained, etc, with respect to themembers 20 of theadministration system 26 is coordinated theRelationship Gate 150, further described below. - Referring to
FIGS. 1 and 9 , sending of interactions 14 (e.g. messages, emails, or viewing, orother network 11 enabled communications) does not always require that themember 20 be in anactive relationship pair 12, as in the case where theprofile 9 of themember 20 is being viewed by anon-member 20. - The
Relationship Gate 150 is used by theadministration system 26 to provide for allowed interactions 14 (e.g. in type, content and/or format) between anymembers 20 over thenetwork 11. Therelationship gate 150 has access to the relationship matrix 15 (seeFIG. 8 ) that stores all theavailable roles 12 a,b and/or correspondingfeatures 18 a,b to a respective member 20 (e.g. for example in the case of a non-member 24, theadministration system 26 can assign a default role(s) 12 a,b and corresponding feature(s) 18 a,b). Therelationship gate 150 can be used to restrict the transmission via thenetwork 11 of any generatedinteractions 14 that do not match with thesender member 20 and/orreceiver member 20 assignedroles 12 a,b and/or features 18 a,b (shared or not). Alternatively, or in addition to, therelationship gate 150 can be used to restrict the generation of anyinteractions 14 that do not match with thesender member 20 and/orreceiver member 20 assignedroles 12 a,b and/or features 18 a,b (shared or not). - For example, the
member 20 may generate a vendor-basedcommunication 14 and then try to send the vendor-basedcommunication 14 to a non-customer of themember 20, for which therelationship gate 150 would review theroles 12 a,b and/or features 18 a,b (shared or not) of thenon-customer member 20, determine that the vendor-basedcommunication 14 is inappropriate for thenon-customer member 20 and then block or otherwise inform (e.g. using a message that informs therole 12 a,b incompatibility of thenon-customer member 20 with a suggestion of sending an invitation instead to enter into a vendor-customer relationship role 12 with the member 20) thevendor member 20 of the inability to transmit the vendor-basedcommunication 14. In this situation, therelationship gate 150 could also modify and/or suggest (to the sending member 20) modifications to the vendor-basedcommunication 14 to include acustomer role 12 b invitation for sending to thenon-customer member 20. In an alternative embodiment, therelationship gate 150 could block themember 20 from generating amessage 14 that is not consistent (e.g. in terms of message type, content, and/or format) with any of theircurrent roles 12 a,b and/or features 18 a,b (shared or not). For example, themember 20 may want to generate a solicitation email for a new product line being sold by thevendor member 20, however the product line and materials associated therewith (e.g. invoices, ordering forms, brochures, etc.) may not be enabled in theroles 12 a,b and/or features 18 a,b (shared or not) of themember 20 in thematrix 15. Therelationship gate 150 could respond to themember 20 to inform the member of the roles12 a,b and/or features 18 a,b lacking in theiraccount 9, which needed in order to be able to generate the desired newproduct line message 14. For example, maybe the member'saccount 9 needs to be upgraded for multiple product line vendor status before the new product line can be a subject of communications by themember 20. - Accordingly, the
relationship gate 150 is used by theadministration system 26 to check whether anyrelationship pair 12, associatedroles 12 a,b, and/or features 18 a,b (shared or not) are in place, may be enabled, or are to be disabled, in order to facilitate theinteractions 14 desired by any of themembers 20 with respect to other selectedmembers 20 of thesystem 26. If, at any time, twomembers 20 are in arelationship pair 12 where the relationship pair becomes unavailable or eitherrelationship role 12 a,b becomes unavailable to one of themembers 20, then therelationship pair 12 can become cancelled from thematrix 15. For example, one of themembers 20 of therelationship pair 20 can leave theadministration system 26, thereby cancelling theiraccount 9. In this case, all of the relationship pairs 12 with thismember 20 would be cancelled and all of thecorresponding relation roles 12 a,b would be deleted or otherwise treated as inactive in the matrix by theadministration system 26. It is recognised that therelationship gate 150 could be used to update thematrix 15 for changes inroles 12 a,b, and/or features 18 a,b (shared or not), as desired. - Referring again to
FIG. 9 , or example, for Member 1 (M1) to be acustomer 12 a and Member 2 (M2) to be aVendor 12 b: 1. M1 is able to be aCustomer 12 a; 2. M2 is able to be aVendor 12 b; 3. M1 does not have anyRelationship pair 12Restrictions 18 a preventing them from initiating (or maintaining) a Relationship pair where they are theCustomer 12 a; 4. M2 does not have anyRelationship Restrictions 18 b preventing them from initiating (or maintaining) a Relationship pair where they are theVendor 12 b; 5. M1 does not have anyOrganization Restrictions 18 a preventing them from being aCustomer 12 a; 6. M2 does not have anyOrganization Restrictions 18 b preventing them from being aVendor 12 b; 7. M1 and M2 do not (in a Customer to Vendor relationship) work 18 a,b at the same Organisation; 8. M1 is not in any relationship pairs 12 that would restrict or prevent them from initiating or maintaining a Customer to Vendor relationship pair and being theCustomer 12 a; 9. M2 is not in any relationship pairs 12 that would restrict or prevent them from initiating or maintaining a Customer toVendor relationship 12 and being theVendor 12 b, for example Relationship count limits 18 a,b fall in here since amember 20 cannot initiate anew relationship pair 12 of a specific type if he or she has already used up all the availability of that relationship pair type 12). - Further to the above, it is recognised that features 18 a,b of a
particular role 12 a,b can contribute to revenue generation and enhanced relationships possible with differentiated relationship pairs 12 having uniquely characterizing role(s) 12 a,b and associatedfeatures 18 a,b (as compared to other different role(s) 12 a,b, in relationship pairs 12), such that the healthcare providers (or other industry specific members 20) can comfortably connect with both their colleagues and their vendors. Members20 may have to pay to be able to be engage in specific relationship pairs 12 and/or to gain desired features 18 a,b (e.g. feature enhancements) for their selectedroles 12 a,b. For example, a service package that amember 20 purchases from theadministration system 26 may restrict/enable 18 a,b not only the types ofrelationship roles 12 a,b themember 20 can be, but the number oftimes 18 a,b themember 20 can engage in arelationship pair 12 where they are playing thatrole 12 a,b. For example, theadministration system 26 may charge marketing professionals 20 a marketing charge (e.g. $100/month) to be able to be 18 a,b a Vendor in customer-vendor relationship pair 12. Further, the $100 package may only allow 18 a,b themember 20 to have limited number (e.g. 50) customer-vendor relationship pairs 12 where they are theVendor 12 a, while an increased value ($200/month) package may allow 18 a,b more/additional/increased (e.g. 200) customer-vendor relationship pairs 12, for example. - Referring to
FIGS. 1 , 9, and 10, in Relationship Creation or Handshaking, e.g. for active relationship pairs 12, there is a Sender M1 (or Initiator) and a Receiver M2. TheRelationship Gate 150 decides, based onmatrix data 15 for sender/receiver members 20, whether or not arelationship pair 12 is already in place, may be enabled, or is to be disabled. There matrix defined factor(s) (e.g. matrix data 15 of the relationships includingoptional role 12 a,b and/or feature 18 a,b (shared or not) for the members 20) that impact whether amember 20 can or cannot initiate a relationship and play aspecific relationship 12 with anothermember 20, such as but not limited to: 1. the Sender M1 capability to be in thespecific Relationship Role 12 a; 2. the Receiver M2 capability to be in thespecific Relationship Role 12 b; 3. if Sender M1 has anyRelationship pair 12Restrictions 18 a and/orRelationship Enhancements 18 a (which for example can be provided via paid for service packages, organization affiliation, member affiliations, etc.); 4. if Receiver M2 has anyRelationship Restrictions 18 b and/orRelationship Enhancements 18 b; 5. the Type of Organization the Sender M1 works with; 6. the Type of Organization the Receiver M2 works with; 7. whether or not the Sender M1 and Receiver M2 work at the same organization; 8. whether or not the Sender M1 shares arelationship pair 12 with any other member (e.g. M3) that would restrict the sender M1 being able to enter into thisrelationship pair 12; and/or 9. whether or not the Receiver M2 shares arelationship pair 12 with any other member (e.g. M3) that would restrict the receiver M2 being able to enter into thisrelationship pair 12. - Referring again to
FIG. 10 , assume Member M1 wishes to initiate arelationship pair 12 with Member M2, such that they have not activated any relationships previously. The Member to Public (P) is always active, but is superseded in this exchange by the Member to Member ‘Port’ 150 a (such that therelationship gate 150 can have a number of ports 150 a open and/or operable for themembers 20 depending upon theirroles 12 a,b and/or features 18 a,b. The Member to Member (M) Port is engaged between any twomembers 20. Assume thematrix 15 hasdata 15 that is compatible with thepotential initiation invitations 14 for the potential relationship pairs 12 displayed inFIG. 10 . In reviewing the relationship roles that sender M1 can initiate with M2,•Associate (As) 12 a,b is available; Colleague(Co) 12 a,b is available; CoWorker(CW) 12 a,b is unavailable with M2 because they are not at thesame organisation 18 a,b; Vendor (V) 12 a,b is unavailable with anyone; Customer (Cu) 12 a,b is available with M2 who can be aVendor 12 a,b; Teacher (Te) 12 a,b is unavailable with anyone; Student (St) 12 a,b is unavailable with M2 because M2 cannot be a Teacher to anyone; Manager (Ma) 12 a,b is unavailable with anyone; and Report (Re) 12 a,b is unavailable with M2 because M2 cannot be a Manager to anyone. - Referring to
FIGS. 1 and 11 , the features and capabilities 18 (shared or not) associated with each relationship pairing 12 has a specific number of defined features 18 as part of a minimum boundary/band feature set 22,23 (e.g. combined) for each of therelationship pair 12 types (i.e. thefeatures 18 in the minimum boundary/band feature set 22,23 must remain enabled by themembers 20 if they are to remain in the acceptedrelationship 12 selected/established between them. For example, therelationship pair 12 type “Associate to Associate” has a minimum band feature set 22 of F108 to F115 and the “Colleague to Colleague” has a minimum band feature set 23 of F100, F198,F199,F153 to F155. Themembers 20 in the “Associate to Associate”relationship pair 12 know that each of themembers 20 has these minimum number offeatures 18 in their minimum band feature set 22 for therespective relationship pair 12 type, in order to maintain transparency and trust about therelationship pair 12 themembers 20 created between each other (i.e. representative of what it means to be in therelationship 12 characterized as associate to associate). - In the event that the
relationship 12 between themembers 20 evolves to include a second enriched relationship pair 12 (e.g. Colleague to Colleague), which builds upon the first relationship pair 12 (e.g. associate to associate), theadministration system 26 manages that additional features of a respective minimum boundary/band feature set 23 for thesecond relationship pair 12 are added to the nowaggregate relationship 6, while providing that the first minimum boundary/band feature set 22 is maintained by themembers 20 in the aggregate relationship pair 6 (i.e. characterizing the combination of the associate to associate and colleague to colleague relationships). In this manner, themembers 20 in theaggregate relationship pair 6 understand that theaggregate relationship pair 6 is characterized by at least thefeatures 18 contained in both minimum boundary/band feature sets 22,23. - Also in
FIG. 9 , it is shown that when in just a “member to member”public relationship pair 12, the minimum boundary/band feature set 25 is F001, F007, F011, F014, F015 and F031-F033, such that thesefeatures 18 are all superseded (i.e. replaced, substituted) when therelationship pair 12 evolves to the associate to associate and the colleague to colleague. In other words, the relationship features 18 for associate to associate completely supersede those for the member tomember relationship pair 12. It is recognised that the banded features 18 can be optionally part of theindividual roles 12 a,b of therelationship pair 12, as desired. - Accordingly, relationships of the same name (
e.g. relationship pair 12 type), as defined by theadministration system 26, always have minimum boundary/band feature sets 22, even when they are being used bydifferent members 20. This minimum number offeatures 18 enforced in therelationship pair 12 provides for that allmembers 20 understand what a colleague is, and what a vendor is, and what a customer is, for example. Though there can be some flexibility in relationship pairs 12, meaning thatmembers 20 can have some control as to how much information (e.g. enabled features 18) they have in aspecific relationship pair 12 type, the minimum boundary/band feature sets 22 provide that no one member can deviate too far from those respective minimum features 18 of therelationship pair 12. For example, onemember 20 as acolleague role 12 a,b cannot have thesame features 18 andinformation sharing capabilities 18 a,b as anothermember 20 as avendor role 12 a,b, otherwiserelationship roles 12 a,b would cease to have any meaning in the context ofdifferent relationship pair 12 types havingdifferent features 18 a,b. - One embodiment of the defined
roles 12 a,b provides for the banding of the features/capabilities 18 a,b, such that progression from one lesser role to the next greater role between any member pair 12 (e.g. from friend to colleague) provides for a minimum number of the features/capabilities 18 a,b of thelesser role 12 a,b to be included as default features (e.g. part of the minimum boundary/band feature sets 22) for thegreater role 12 a,b. This banding provides formembers 20 to truly represent their acceptedrole 12 a,b when interacting with theother members 20 of themember pair 12 using the assigned definedrole 12 a,b. For example, amember 20 who has accepted anothermember 20 as a friend cannot simply turn offaccess 18 to theother member 20 from their contact information (e.g. phone number, email address, home address, etc.) that appropriately represents thefriend role 12 a,b. It is understood that to be an accepted friend, some member information (and any other appropriate features/capabilities 18) cannot be restricted from theother member 20 of themember pair 12 on an ad hoc basis. In other words, turning off or otherwise disabling offeatures 18 from the minimum boundary/band feature set(s) 22 would cause the statedrelationship pair role 12 a,b characteristics inherent in therelationship pair members 20. It is also understood that the evolution of the minimum boundary/band feature sets 22 for aggregate relationship pairs 6 can be hierarchical in assignment. - Referring again to
FIG. 8 , the capabilities/features/privileges/restrictions 18 are grouped as associated/assigned to the respectiveindividual relationship role 12 a,b. It is recognised that the sets/groups individual features 18 in common (e.g. overlapping sets/groups group features 18 as a whole is unique infeature 18 content to the respective role type 12 a that they are assigned. In this manner, theadministration system 26 can facilitate that arole 12 type has a uniquefirst set 22 of assigned features 18 and therefore cannot be confused with asecond role 12 type having a unique second set 23 of assigned features 18, such that the first 22 and second set 22 offeatures 18 are not identical. For example, therole type 12 a of a Colleague would have different set 23 offeatures 18 than that of an Associate, as would theaggregate role 8 of associate+colleague (seeFIG. 9 ) would have an aggregate set 22+23 offeatures 18 - It is also recognised that some
features 18 can be superseded byother features 18, either in whole or in part (e.g. to take the place of such as replace or to augment so as to make an already assignedfeature 18 greater/lesser in size, extent, or influence), during aggregation of relationship pairs 12 and theircorresponding roles 12 a,b and features sets 22,23, as further described below with respect to aggregate relationship pairs 6 (seeFIG. 9 ). - As an alternative embodiment to
relationships 12 and banding, it is also recognised that the defined online existingrelationship 12 between afirst member 20 and asecond member 20 can be defined by a plurality of existing relationship features 18 for use in managingnetwork interaction 14 on thecommunications network 11 between thefirst member 20 and thesecond member 20. The relationship features 18 are characteristic of therelationship 12, such that at least one of the corresponding relationship features 18 of therelationship 12 is used to define as permitted at least one of thenetwork interaction 14 type, the network interaction content, or the network interaction format. It is recognised that the relationship features 18 can be between thefirst member 20 and the second member 20 (i.e. each of themembers 20 do not have a definedrelationship role 12 a,b, in the relationship 12). Or, as further discussed above, it is recognised that a first portion of the relationship features 18 a characterizes thefirst relationship role 12 a and a second portion of the relationship features18 b characterizes thesecond relationship role 12 b, such that thefirst relationship role 12 a and thesecond relationship role 12 b are part of the relationship defined as therelationship pair 12 between the first andsecond members 20. In other words, theaggregate relationship pair 12, described above by example only, can be administered by theadministration system 26 as a roleless relationship 12, such that the relationship features 18 are shared between themembers 20 for managing their inter-member 20interactions 14. - Referring to
FIGS. 1 and 12 a,b, the relationship pairs 12 and the associatedroles 12 a that are assigned to arespective member 20 by theadministration system 26 can change over time, as the online relationship themember 20 has withother members 20 also grows/changes/evolves over time. Flexibility inrelationship 12 evolution management is facilitated by the ability of theadministration system 26 to aggregate relationship pairs 12.Members 20 may not always have the same relationship with each other over time, and therefore theadministration system 26 provides the environment for member relationships to alter, grow, and/or diminish in their relationship characteristics (e.g. relationship roles 12 a,b and associatedfeatures 18 a,b andinteraction 14 abilities. - Therefore,
relationships 12 andoptional relationship roles 12 a,b can change, as coordinated by theadministration system 26, and in changing some relationship features 18 and/orroles 12 a,b can supersede (either in whole or in part) one another. For example, twomembers 20 could be paired 12 as Associates but then become closer and decide to become paired 12 as Colleagues. In becoming colleagues, theirassociate relationship 12 could be superseded because all of the features andcapabilities 18 of theAssociate relationship 12 could be within theColleague relationship 12. - Further,
individual relationships 12 and thecorresponding relationship roles 12 a,b need to be able to grow, in order to provide for desired richer (e.g.additional feature 18 supported) interaction(s) 14 between themembers 20 of the evolving/growingrelationship 12. One mechanism provided by theadministration system 26 to support the evolution of relationships is the coordination of aggregate relationship pairs 6 that can involvemultiple relationship sub-pairs 12. For example, twomembers 20 could be in a colleague-colleague relationship pair 12, but also want to engage in a customer-vendor relationship pair 12 as well as a student-vendor relationship pair 12. Theadministration system 26 facilitates the management of the associatedroles 12 a,b as anaggregate role 8 and the associated features set 18 as an aggregate feature set 4 by enabling individual relationship pairs 12 that have different features andcapabilities 18 to aggregate. - An example of relationship evolution between
members 20 is Joe Smith M1 goes to University to be a Doctor. While at University, the teachers have decided to use a valuable medical industry social CRM network—administration system 26—to work with theirstudents 20. One of Joe's M1 professors is Dr. Jones M2. Joe M1 connects with Dr. Jones M2 on theadministration system 26 in a Student-Teacher relationship pair RP-ST. Joe M1 gets his residency at Toronto General, as shown inFIG. 12 a. He leaves university to start his new full time position. In leaving school, thesystem 26 asks him to confirm that his relationship pair RP-ST (as Student to Teacher) be cancelled or changed, shown deleted by stippled lines for R-T,F-T and R-S,F-S inFIG. 12 b. - Next, the final result of relationship evolution is shown in
FIG. 12 b, where first Joe M1 requests, via ahandshake 14, thatDr. Jones 20 accept new relationship pair RP-AA—an Associate to Associate. Joe M1 is now a physician at Toronto General, and he meets Dr. Jones M2 one day in the hall as Dr. Jones M2 is now performing many consultations at the hospital. They M1,M2 end up being able to become closer, and are now colleagues. They change theiradministration system 26 viainteractions 14 with one another to reflect this, i.e. to add a colleague to colleague pair RP-CC. Joe M1 decides he is no longer interested in working with the providers, and interviews with AstraZeneca to work with their medical department. They accept that, and he moves to AZ. He keeps his Colleague to Colleague relationship pair RP-CC with Dr. Jones M2, but now also requests 14 that Dr. Jones M2 accept him as a Vendor for AV products, thus further evolving their relationship in theadministration system 26 to add a vendor-customer relationship pair RP-VCust. - In view of the above example, it is recognised that the individual relationship pairs RP-AA, RP-VCust, RP-CC are aggregated to define the corresponding aggregate relationship pair 6 (an aggregation of the different individual relationship pairs 12) between the members M1,M2. Further, it is recognised that the corresponding
aggregate role 8 is an aggregated combination of the individually definedroles 12 a,b (e.g. role R-A, R-A, R-V, R-Cust, R-C, R-C) of each of the individual relationship pairs RP-AA, RP-VC, RP-CC, and the corresponding aggregate features/capabilities 4 is an aggregated combination of the individually defined features/capabilities 18 a,b (e.g. features/capabilities C-A,C-A, C-V,C-Cust, C-C, C-C) of each of theindividual relationship roles 12 a.b. In other words, theadministration system 26 provides for definedinteractions 14 between any pairedmembers 20 based on their aggregate features/capabilities 4 as defined via their correspondingaggregate role 8. For example, Joe M1 interacts 14 with Dr. Jones M2 in theiraggregate relationship pair 6 using any of the aggregate features/capabilities 18. In view of the definedinteractions 14 facilitated by thesystem 26 via the relationship gate 150 (seeFIG. 7 ), either of the members M1,M2 can recognise whatindividual role 12 a,b (and/or combinedrole 12 a,b) available in theaggregate role 8 that the member M1,M2 is using during theinteractions 14, as any of the aggregate features/capabilities 4 can retain and/or combine their individual defined characteristic features/capabilities 18 characteristics represented in theinteractions 14. - Further, in view of the above, it is recognised that certain feature(s) 18 can be such as but not limited to: unique (e.g. only provided) by a
particular role 12 a,b and therefore become additions/deletions to/from the existing/aggregate features 4 when theroles 12 a. b are aggregated (i.e. when anew role 12 a,b is added to existing role(s) 12 a,b oraggregate role 8 and/or existing role(s) 12 a,b is/are deleted/removed from the existing aggregate role 8 (or existingsingle role 12 a,b); can overlap (e.g. be in common) between two ormore roles 12 a,b and therefore become redundant aggregate feature(s) 4 when theroles 12 a. b are aggregated; can be conflicting with other existingfeatures 18 of the set ofaggregate features 4 and therefore the new and/or existingfeatures 18 can be disabled/deleted from the aggregate features 4 when theroles 12 a. b are aggregated; can supersede or be superseded (e.g. either the new or existing feature is a preferred feature 18) over existing/new feature(s) 18 in the aggregate features 4 and therefore the non-preferred features new and/or existingfeatures 18 can be disabled/deleted from the aggregate features 4; or a combination thereof. - Further, it is recognised that the process of aggregation performed by the
administration system 26 for example, to result in theaggregate relationship pair 6 and associated optionalaggregate role 8 and assigned aggregate features 4, can be defined by such as but not limited to: the combining of a selected (e.g. by themember 20 and/or requested 14 by another member 20) newoptional role 12 a,b to an existingrelationship role 12 a,b or to two or more existingroles 12 a,b (e.g. to an existing aggregate role 8) of arelationship pair role 12 a,b from two or more existingroles 12 a,b (e.g. to an existing aggregate role 8) of arelationship pair 6; and/or the amendment of an existingrelationship role 12 a,b or of at least one of two or more existingroles 12 a,b (e.g. to an existing aggregate role 8) of arelationship pair role 8. - It is recognised that the content (e.g. text, image, video, enclosures, message type (email, telephone, text message, etc.), message enclosures, content size/amount/length) and/or format (e.g. form of the content such as colour, font style, message priority, etc.) of the
interactions 14 can be defined by and their generation facilitated by the associated features/capabilities 18 a,b (e.g. of theoptional role 12 a,b or as shared by themembers 20 of the pair 12) that themember 20 is using/operating under in theadministration system 26 with selected (active and/or passive)other members 20. It is also recognised that the content and/or form of theinteractions 14 can be defined using a combination ofdifferent roles 12 a,b and their associatedfeatures 18 a,b in view of aggregation of relationship pairs 12. Therefore, the aggregate features 4 of theaggregate role 8 can cooperate together and/or separately, as selected by therespective member 20 to generate 14 and/or to respond/reply 14 to communications over thenetwork 14 between member(s) 20 that are part of the memberaggregate relationship pair 4 governed by theaggregate roles 8 a,b assigned to themembers 20 of theaggregate relationship pair 4. - For example, when Joe M1 asks 14 Dr. Jones M2 to dinner, the characteristics (e.g. text, image content and/or format) of the
interaction 14 can be defined by the particular features/capabilities 18 Joe M1 is using from hisaggregate role 8 of theaggregate relationship pair 6 with Dr. Jones M2. For instance, Joe M1 can send anemail 14 to Dr. Jones M2 requesting a meeting at a corresponding time and place. Based on the use of certain individual role(s) 12 a,b in theaggregate role 8, by Joe M1, when generating theemail 14, Joe M1 can affect the perceived tone (e.g. business, personal, or a combination thereof) of theemail 14 by selecting certain features/capabilities 18 a,b associated with selectedroles 12 a,b of his aggregatedrole 8 with Dr. Jones M2. For example, Joe M1 can select in communication withinteraction 14 building capabilities of the administration system 26 (e.g. via browser as a thin client of theadministration system 26 as a Web service), and/or via an administration system module/application 27 installed on hisdevice 101, seeFIG. 2 , (e.g. as a thick client of the administration system 26), the particular roles R-V,R-C and therefore have available all of the content/format features C-V,C-C to generate theemail 14. In this case, Joe M1 can include in theemail 14 vendor details (via the selected individual capabilities C-V of the selected individual role R-V) of his products with marketing and/or order materials (as email enclosures) and can also have theemail 14 type foiniatted (via the selected individual capabilities C-C of the selected individual role R-C in the role 8) to be perceived as a colleague meeting invitation. This would provide for Dr. Jones M2 to understand that the proposed meeting will be a combination of business and personal interaction between them, e.g. a soft sell environment with potential for extended interaction in the colleague context. On the contrary, Joe M1 can include in theemail 14 only vendor details (via the selected individual capabilities C-V of the selected individual role R-V in the role 8) of his products with marketing and/or order materials (as email enclosures) with corresponding formatting (via the selected individual capabilities C-C of the selected individual role R-C in the role 8). This would provide for Dr. Jones M2 to understand that the proposed meeting will be a strictly business interaction between them, e.g. a harder sell environment with little/no time for extended interaction inother role 12 a,b contexts of theaggregate role 8 of theaggregate relationship 6. It is recognised that both Dr. Jones M2 and Joe M1 are cognizant of the extents (i.e. list of possibleindividual roles 12 a,b and associated individual features 18 a,b) of theiraggregate relationship pair 6. - As well, further to the above example, Dr. Jones M2 can also include in his response communication 14 (e.g. email and/or telephone call) the appropriate type of response as dictated by the individual role(s) 12 a,b used to generate the
original email 14. For example, in the strict business sense, therelationship gate 150 may disallow return communication 14 (to the email 14) in the form of a telephone call, as this would not be available as a feature/capability 18 in a customer role R-Cust in response to received product solicitation emails 14 (i.e. Joe M1 only used his role R-V to generate the email 14). On the other hand, in the event where Joe M1 used his role R-V to generate theemail 14 along with his role R-C as part of hisaggregate role 8, therelationship gate 150 could allow Dr. Jones M2 to informally reply 14 to theoriginal email 14 using atelephone call 14 as part of the features C-C afforded by Dr. Jones M2 role R-C of his respectiveaggregate role 8. - In view of
FIGS. 1 and 12 a,b and the above evolution example, it is recognised that aggregation ofrelationship pair 12 types (i.e. anymember 20 assuming theroles 12 a and associated features/capabilities 18 a of a plurality of relationship pair types 12) can be used to represent electronically the definition of theAggregate relationship role 8 for amember 20, representing the composite/aggregation of individually definedroles 12 a,b that amember 20 has between two or moreother members 20 of theadministration system 26. Accordingly, theAggregate relationship role 8 provides for anymember 20 to evolve their aggregated relationship pairs 12 over time as an assembly/combination of separate parts/portions of features/capabilities 18 a defined for a number of respective different definedrelationship roles 12 a of a number ofdifferent relationship pair 12 types. It is recognised that theroles 12 a,b as part of theaggregate relationship role 8 can affect the growth and/or shrinkage in size and/or effect of the capabilities, features, andrestrictions 18 associated with each overall aggregate relationship 12 (i.e. a combination/aggregation of different relationship pairs 12) between pairs ofmembers 20. Therefore, the provision and coordination of aggregate relationship pairs 6 by theadministration system 26 between pairs ofmembers 20 can provide for incremental increase/decrease in the size and/or effect of the associatedroles 12 a,b, and corresponding features/capabilities 18 a,b as a collection from separate/individual definedroles 12 a,b and corresponding features/capabilities 18 a,b aggregated within theaggregate relationship pair 6. - As an alternative embodiment, it is also recognised that the defined online existing
relationship 12 between afirst member 20 and asecond member 20 can be defined by a plurality of existing relationship features 18 for use in managingnetwork interaction 14 on thecommunications network 11 between thefirst member 20 and thesecond member 20. The relationship features 18 are characteristic of therelationship 12, such that at least one of the corresponding relationship features 18 of therelationship 12 is used to define as permitted at least one of thenetwork interaction 14 type, the network interaction content, or the network interaction format. It is recognised that the relationship features 18 can be between thefirst member 20 and the second member 20 (i.e. each of themembers 20 do not have a definedrelationship role 12 a,b, in the relationship 12). Or, as further discussed above, it is recognised that a first portion of the relationship features 18 a characterizes thefirst relationship role 12 a and a second portion of the relationship features 18 b characterizes thesecond relationship role 12 b, such that thefirst relationship role 12 a and thesecond relationship role 12 b are part of the relationship defined as therelationship pair 12 between the first andsecond members 20. In other words, theaggregate relationship pair 12, described above by example only, can be administered by theadministration system 26 as a roleless relationship 12, such that the relationship features 18 are shared between themembers 20 for managing their inter-member 20interactions 14. - Referring to
FIGS. 1 and 13 , shown is arelationship network environment 10 for facilitatingcommunications 14 between members andnonmembers 20,24 (e.g. using acomputing device 101—seeFIG. 2 ) via therelationship administration system 26.Relationship data 15 is maintained by arelationship engine 100 of thesystem 26 for one ormore pairs 12 defined for a pair of the members/nonmembers communications 14 between the members/nonmembers relationship administration system 26 in view of the particular features/capabilities defined in therelationship data 15 of the pair(s) 12 defined for the member pair. Therelationship engine 100 provides for initializing, maintaining, and modifying the defined pair(s) 12 associated with a selected pair of themembers 20, as well as managing theinteractions 14 based on thedata 15. - For example, evolving a defined online existing
relationship 12 between afirst member 20 and asecond member 20 is performed by theengine 100, such that the online existingrelationship 12 is defined by a plurality of existing relationship features 18 for use in managingnetwork interaction 14 on acommunications network 11 between thefirst member 20 and thesecond member 20. Theengine 100 facilitates receiving by a selection module 162 a new online relationship 12 (for example submitted by one of the members 20) having new relationship features 18, such that thenew features 18 are different from the existing relationship features 18. The new relationship features 18 are characteristic of thenew relationship 12. Theengine 100 aggregates the existing relationship features 18 (and optionally for theaggregate role 8 by aggregating the new and existingroles 12 a,b) and the new relationship features 18 by anaggregation module 160 as aggregate relationship features 4, which are a combination of the existing relationship features 18 and the new relationship features 18, in order to define theaggregate relationship 6. Theengine 100 stores the aggregate relationship features 4 in astorage 210 of theadministration system 26 asrelationship data 15 representing theaggregate relationship 6 defined by the relationship features 4 for example by theaggregator module 160. - A further optional operation is by done a
banding module 164 for defining a minimum number (e.g. sets 22,23) ofaggregate features 4 of theaggregate relationship 6 that must be maintained, as discussed above. A further optional operation is by arole module 166 for defining theaggregate role 8 a,b for each of themembers 20 of theaggregate relationship 6 that is confirmed by the member (s) 20. It is also recognised that therole module 166 can be used to define any directional and inherent/passive nature of theroles 8 a,b. - Further, the
engine 100 has therelationship gate module 150 configured for accessing therelationship data 15 in order to determine whether a selectednetwork interaction 14 from one of themembers 20 is permitted in view of at least one of the corresponding aggregate relationship features 4 of theaggregate relationship 6. Therelationship gate module 150 also facilitates the selectednetwork interaction 14 between themembers 20 when determined as permitted, such that the at least one of the corresponding aggregate relationship features 4 of theaggregate relationship 6 is used to define as permitted at least one of thenetwork interaction 14 type, the network interaction content, or the network interaction format. - It is also recognized that
multimember pairings 12 could be implemented by thesystem 26, for example where each of a plurality of members is paired to a respective member (e.g. a many to one pairing) or a respective member is paired to a plurality of members (e.g. a one to many pairing). This type of pairing provides for the setup of group settings, such as a plurality of customers that are serviced by a vendor, a plurality of vendors that are selected to service a particular customer, a manager that has a number of employees, etc. In this manner,communications 14 between the members in group settings can be performed in parallel, such that an offer from one vendor can be communicated 14 simultaneously to the each of the plurality of customers associated with the vendor, via the respective defined vendor customer role pairs 12 between the vendor and each of the customers of the plurality of customers of thesystem 26. Also, in the case of multiple vendors for a particular customer, each of the vendors could be made aware (via the system 26) of an offer proposed by one of the vendors to the customer (e.g. in a open bid process in a Request for Proposal situation). Further, it is also recognized that a many to many member group can be set up, such as in the case of a group of friends, a group of colleagues, etc. In this manner,communications 14 sent to one of the members of the group would be communicated to each of the other members of the group. - However, in each of the above multimember pairing examples, there can exists defined
role 12 a,b between any two member pair of the plurality ofmembers 20, i.e. in the colleague group example, each of the members of the group would have a colleague-colleague definedrole 12 a,b with each of the other members of the group. A further embodiment is where there is a relationship defined as a three (or more) person “pairing” such that there are three ormore roles 12 a,b,c, with associated features/capabilities 18 a,b,c to define the complete set ofinteractions 14 between the multi-person “pairing” 12. In this manner, each of the members of the multi-person pairing (also know as a member set) has a subset of the total features/capabilities 18 a,b,c (some features/capabilities 18 a,b,c can be overlapping between the members of the member set. For example, a relationship member set of a teacher, a tutor, and a student can be implemented in thesystem 26, such that each member of the member set is connected to each other as defined by the individual relationship roles defined in theirrelationship data 15. For example, the teacher, tutor, student combination could contain theindividual pairings 12 of student-teacher, teacher-student, student-tutor, tutor-student, teacher-tutor, and tutor-teacher, such that each of theroles 12 a,b,c of the member setpairing 12 would have the associated features/capabilities 18 a,b,c. For example, the tutor and the teacher could share 14 exam results and other evaluation criteria/comments of the student (which are blocked 14 from view from the student), the tutor could receive and respond 14 to laboratory questions from the student, however these questions would not be communicated 14 to the teacher until first reviewed/commented on by the tutor, etc. - In the manner as discussed above by example, the format, content, mode, and other features/capabilities of the communications 14 (including information visible on the Web page/
profile page 11 of the member account) between members is monitored and/or otherwise maintained/structured by thesystem 26. - The following is a list, for example only, of the configuration of the
relationship data 15 between any pair of members of the system 26: -
- Users choose relationships (i.e. pair(s) 12) to have with another users;
- Some relationships are aggregated/combined/Some are hierarchical;
- Relationships can be removed/downgraded/upgraded;
- A relationship connection can use two one
way connections 12 a,b, e.g. the vendor has avendor customer connection 12 a with the customer and the customer has a customer-vendor connection 12 b with the vendor). Therefore, the user offering any relationship uses a complimentary relationship in reverse. So to be in a relationship, the other user accepts the complimentary relationship to have back. To accommodate the creation of ‘two relationships’, each user adopts arelationship role 12 a,b in any two way relationship 12 (also would apply in member sets having more than two members); - Relationships are impacted by time, and can require checks/changes/upgrades/downgrades/etc;
- Events may trigger relationship checks/changes;
- User roles may impact relationship;
- User relationships with other users/organizations may impact potential for relationships with another user;
- User may alter, within limits, relationship permissions by customizing the available customizable features/capabilities of the defined
role pairing 12. (There can be minimum permissions and maximum permissions associated with each relationship, so as to maintain a band of commonality with each relationship so users become used to what it means to be involved in that relationship.); - Capability to start/maintain a relationship may be impacted by:
- User role of Initiator
- User role of Receiver
- Service package of Initiator
- Service package or Receiver
- Organization Environment of Initiator
- Organization Environment of Receiver;
- Connections or “pipes”(e.g. one-way connection of the two way relationship) may be used to transfer information/features;
- Some “pipes” may be active. Some may be passive; and
- Some relationship pipes are always in place, depending on the user role. (For example, a base user always has ‘Public’ pipes in place displaying a limited amount of information to the public).
- Referring to
FIGS. 1 , 12 b, 13, and 14, amethod 300 for evolving a defined online existingrelationship 12 between afirst member 20 and asecond member 20 is provided, such that the online existingrelationship 12 is defined by a plurality of existing relationship features 18 for use in managingnetwork interaction 14 on acommunications network 11 between thefirst member 20 and thesecond member 20. The method 300 includes: step 302 receiving by the selection module 162 a new online relationship 12 having new relationship features 18 such that the new features 18 are different from the existing relationship features 18, the new relationship features 18 being characteristic of the new relationship 12; step 304 aggregating the existing relationship features 18 (and optionally for the aggregate role 8) and the new relationship features 18 by the aggregation module 160 as aggregate relationship features 4 as a combination of the existing relationship features 18 and the new relationship features 18 in order to define an aggregate relationship 6; step 306 storing the aggregate relationship features 4 in a storage 210 of the administration system 26 as relationship data 15 representing the aggregate relationship 6 defined by the relationship features 4; and step 308 of accessing the relationship data 15 by the relationship gate 150 in order to determine whether a selected network interaction 14 from one of the members20 is permitted in view of at least one of the corresponding aggregate relationship features 4 of the aggregate relationship 6 and facilitating the selected network interaction 14 between the members 20 when determined as permitted, such that the at least one of the corresponding aggregate relationship features 4 of the aggregate relationship 6 is used to define as permitted at least one of the network interaction 14 type, the network interaction content, or the network interaction format. - A further
optional step 310 is by abanding module 164 for defining a minimum number offeatures 4 of therelationship 6 that must be maintained. A further optional step 312 is by arole module 166 for defining theaggregate role 8 a,b for each of themembers 20 of therelationship 6 that must be confirmed by the member(s) 20. It is also recognised that therole module 166 can be used to define any directional and inherent/passive nature of theroles 8 a,b. - Referring to
FIGS. 1 and 2 , each of the above-describedmembers 20 andadministration systems 26 can be implemented on one or more respective computing device(s) 101. Thedevices 101 in general can include anetwork connection interface 200, such as a network interface card or a modem, coupled viaconnection 218 to adevice infrastructure 204. Theconnection interface 200 is connectable during operation of thedevices 101 to the network 11 (e.g. an intranet and/or an extranet such as the Internet), which enables thedevices 101 to communicate with each other as appropriate. Thenetwork 11 supports thecommunication 14 of the data between theadministration system 26 andmembers 20, and also supports thecommunication 14 of the data between themembers 20. - Referring again to
FIG. 2 , thedevices 101 can also have auser interface 202, coupled to thedevice infrastructure 204 byconnection 222, to interact with a user (e.g. vendor 20,customer 20,nonmember 20, etc.). Theuser interface 202 can include one or more user input devices such as but not limited to a QWERTY keyboard, a keypad, a track wheel, a stylus, a mouse, a microphone and the user output device such as an LCD screen display and/or a speaker. If the screen is touch sensitive, then the display can also be used as the user input device as controlled by thedevice infrastructure 204. For example, theuser interface 202 for thedevices 101 used by themembers 20 can be configured to interact with themembers 20 web browsers (applications 16) to access 14 themember information 15 available on the websites/accounts 9 of themembers 20. For thedevices 101 used by themembers 20, theuser interfaces 202 can be used to access the administration system 26 (e.g. via a website) to register with the system 26 (i.e. set up/modify their account) as well as to provide information for display on theiraccount 9. For thedevices 101 used by the administration system 26 (e.g. using the relationship engine 100), theuser interfaces 202 can be used to the administration to configure therelationship data 15 of member pairing(s) 12 based on information and/or registration data of themembers 20. - Referring again to
FIG. 2 , operation of thedevice 101 is facilitated by thedevice infrastructure 204. Thedevice infrastructure 204 includes one ormore computer processors 208 and can include an associated memory 210 (e.g. a random access memory) for storing ofrelationship data 15 and forprocessing communications 14 communicated between themembers 20 and between theadministration system 26 and themembers 20. Thecomputer processor 208 facilitates performance of thedevice 101 configured for the intended task (e.g.members 20, administration system 26) through operation of thenetwork interface 200, theuser interface 202 and other application programs/hardware 16 of thedevice 101 by executing task related instructions, These task related instructions can be provided by an operating system, and/orsoftware applications 16 located in thememory 210, and/or by operability that is configured into the electronic/digital circuitry of the processor(s) 208 designed to perform the specific task(s). Further, it is recognized that thedevice infrastructure 204 can include a computerreadable storage medium 212 coupled to theprocessor 208 for providing instructions to theprocessor 208 and/or to load/update client applications 16. The computerreadable medium 212 can include hardware and/or software such as, by way of example only, magnetic disks, magnetic tape, optically readable medium such as CD/DVD ROMS, and memory cards. In each case, the computerreadable medium 212 may take the form of a small disk, floppy diskette, cassette, hard disk drive, solid state memory card, or RAM provided in thememory module 210. It should be noted that the above listed example computerreadable mediums 212 can be used either alone or in combination. For example, theapplications 16 can include browsers used by themembers 20 to access the Web site of theadministration system 26 and/or to communicate 14 information betweenmembers 20 of thesystem 26 - Further, it is recognized that the
computing devices 101 can include theexecutable applications 16 comprising code or machine readable instructions for implementing predetermined functions/operations including those of an operating system, relationship configuration system(s), for example, in response to user command or input. Theprocessor 208 as used herein is a configured device and/or set of machine-readable instructions for performing operations as described by example above. As used herein, theprocessor 208 may comprise any one or combination of, hardware, firmware, and/or software. Theprocessor 208 acts upon information by manipulating, analyzing, modifying, converting or transmitting information for use by an executable procedure or an information device, and/or by routing the information with respect to an output device. Theprocessor 208 may use or comprise the capabilities of a controller or microprocessor, for example. Accordingly, any of the functionality (e.g. engine 100) provided by the systems and process of FIGS. 1,2,3 may be implemented in hardware, software or a combination of both. Accordingly, the use of aprocessor 208 as a device and/or as a set of machine readable instructions is hereafter referred to generically as a processor/module for sake of simplicity. Further, it is recognized that theadministration system 26 can include one or more of the computing devices 301 (comprising hardware and/or software) for implementing theengine 100, as desired. - It will be understood that the
member 20client computing devices 101 may be, for example, personal computers, personal digital assistants, mobile phones, and content players. Server computing devices 101 (e.g. for theadministration system 26 and/or the member 20) may additionally include a secondary storage element such as the memory (e.g. database). Each server, although depicted as a single computer system, may be implemented as a network of computer processors, as desired. - While illustrative embodiments of the invention are disclosed herein, it will be appreciated that numerous modifications and other embodiments may be devised by those of ordinary skill in the art and the invention is not to be understood to be limited to such illustrated embodiments. Therefore, it will be understood that the appended claims are intended to cover all such expedient modifications and embodiments that come within the spirit and scope of the present invention, including those readily attainable by those of ordinary skill in the art from the disclosure set forth herein, or by routine experimentation therefrom based on the guidance herein.
Claims (24)
1. A method for evolving a defined online existing relationship between a first member and a second member, the online existing relationship defined by a plurality of existing relationship features for use in managing network interaction on a communications network between the first member and the second member, the method comprising:
receiving a new online relationship having new relationship features such that the new features are different from the existing relationship features, the new relationship features being characteristic of the new relationship;
aggregating the existing relationship features and the new relationship features as aggregate relationship features a combination of the existing relationship features and the new relationship features in order to define an aggregate relationship;
storing the aggregate relationship features in a storage as relationship data representing the aggregate relationship defined by the relationship features; and
accessing the relationship data in order to determine whether a selected network interaction from one of the members is permitted in view of at least one of the corresponding aggregate relationship features of the aggregate relationship, and facilitating the selected network interaction between the members when determined as permitted;
wherein said at least one of the corresponding aggregate relationship features of the aggregate relationship is used to define as permitted at least one of the network interaction type, the network interaction content, or the network interaction format.
2. The method of claim 1 , wherein the aggregate relationship features are shared between the first member and the second member.
3. The method of claim 2 , wherein a first portion of the aggregate relationship features is assigned to an aggregate first relationship role of the aggregate relationship for the first member and a second portion of the aggregate relationship features is assigned to an aggregate second relationship role of the aggregate relationship for the second member.
4. The method of claim 3 , wherein the aggregate first relationship role and the second aggregate relationship role are different, such that the first portion of the aggregate relationship features characterizes the aggregate first relationship role and the second portion of the aggregate relationship features characterizes the aggregate second relationship role, such that the aggregate first relationship role and the aggregate second relationship role are part of the aggregate relationship defined as an aggregate relationship pair between the first and second members.
5. A method for evolving a defined online existing relationship pair between a first member and a second member, the online existing relationship pair defined by a first existing relationship role assigned to the first member having a plurality of first existing role features for use in managing network interaction on a conununications network between the first member and the second member, and a second existing relationship role assigned to the second member having a plurality of second existing role features for use in managing the network interaction between the first member and the second member, the method comprising:
receiving a new online relationship pair having a new first relationship role and a second new relationship role, such that the corresponding first new role features and the second new role features are different from the first existing role features and the second existing role features, the first new role features and second new role features being characteristic of the new relationship pair;
aggregating the first existing role features and the first new role features as aggregate first role features being a combination of the first existing role features and the first new role features in order to define an aggregate first role;
aggregating the second existing role features and the second new role features as aggregate second role features being a combination of the second existing role features and the second new role features in order to define an aggregate second role;
storing the aggregate first role and the aggregate second role with their associated aggregate features in a storage as relationship data representing an aggregate relationship pair defined by the aggregate roles and their corresponding aggregate role features; and
accessing the relationship data in order to determine whether a selected network interaction from one of the members is permitted in view of at least one of the corresponding aggregate role or aggregate role features of at least one of the aggregate first role or aggregate second role of the aggregate relationship pair, and facilitating the selected network interaction between the members when determined as permitted;
wherein said at least one of the corresponding aggregate role or aggregate role features of at least one of the aggregate first role or aggregate second role of the aggregate relationship pair is used to define as permitted at least one of the network interaction type, the network interaction content, or the network interaction format.
6. The method of claim 5 , wherein the step of aggregating the first existing and first new role features involves the addition of a new feature from the first new role features to the first existing role features.
7. The method of claim 5 , wherein the step of aggregating the first existing and first new role features involves the deletion of an existing feature from the existing role features.
8. The method of claim 5 , wherein the step of aggregating the first existing and first new role features involves the substitution of a new feature from the first new role features exchange an existing feature of the existing role features.
9. The method of claim 6 , wherein the network interaction is selected from the group comprising: a network message and a network action associated with a profile of one of the members.
10. The method of claim 6 further comprising the step of defining a minimum number of the existing first role features to remain as part of the aggregate first role features.
11. The method of claim 10 further comprising the step of defining a minimum number of the new first role features to become part of the aggregate first role features.
12. The method of claim 10 further comprising the step of defining in the relationship data that the aggregate relationship pair is an active relationship pair that requires formal acceptance by the second member of the new second relationship role.
13. The method of claim 10 further comprising the step of defining in the relationship data that the aggregate relationship pair is a passive relationship pair that does not require formal acceptance by the second member of the new second relationship role.
14. The method of claim 10 further comprising the step of defining the first new relationship role and the second new relationship role as directional roles, such that the first member must assume the first new relationship role in order for the second member to assume the second new relationship role.
15. The method of claim 14 , wherein the first new role features and the second new role features are different from one another
16. The method of claim 6 further comprising the step of defining in the relationship data that the aggregate relationship pair is an active relationship pair that requires formal acceptance by the second member of the new second relationship role.
17. The method of claim 6 further comprising the step of defining in the relationship data that the aggregate relationship pair is a passive relationship pair that does not require formal acceptance by the second member of the new second relationship role.
18. The method of claim 10 further comprising the step of defining the first new relationship role and the second new relationship role as directional roles, such that the first member must assume the first new relationship role in order for the second member to assume the second new relationship role.
19. The method of claim 18 , wherein the first new role features and the second new role features are different from one another
20. A method for evolving a defined online existing relationship pair between a first member and a second member, the online existing relationship pair defined by a plurality of existing relationship features for use in managing network interaction on a communications network between the first member and the second member, the method comprising:
receiving a new online relationship pair having corresponding new relationship features different from the existing relationship features, the new relationship features being characteristic of the new relationship pair;
combining the existing relationship features and the new relationship features to generate combined relationship features by adding a new feature from the new relationship features to the existing relationship features, such that a minimum number of the existing relationship features remain as part of the combined relationship features;
storing the combined relationship features in a storage as relationship data representing the new relationship pair for the members defined by the corresponding respective combined relationship features; and
accessing the relationship data in order to determine whether a selected network interaction from one of the members is permitted in view of at least one of the corresponding combined relationship features, and facilitating the selected network interaction between the members when determined as permitted;
wherein at least one of the corresponding combined relationship features of the new relationship pair is used to define as permitted at least one of the network interaction type, the network interaction content, or the network interaction format.
21. A method for evolving a defined online existing relationship pair between a first member and a second member, the online existing relationship pair defined by a first existing relationship role assigned to the first member having a plurality of first existing role features for use in managing network interaction on a communications network between the first member and the second member, and a second existing relationship role assigned to the second member having a plurality of second existing role features for use in managing the network interaction between the first member and the second member, the method comprising:
receiving a new online relationship pair having corresponding first new role features and the second new role features different from the first existing role features and the second existing role features, the first new role features and second new role features being characteristic of the new relationship pair;
combining the first existing role features and the first new role features to generate combined first role features by adding a new feature from the first new role features to the first existing role features, such that a minimum number of the existing first role features remain as part of the combined first role features;
combining the second existing role features and the second new role features to generate combined second role features by adding a new feature from the second new role features to the second existing role features, such that a minimum number of the existing second role features remain as part of the combined second role features;
storing the combined role features in a storage as relationship data representing the new relationship pair for the members defined by the corresponding respective combined role features; and
accessing the relationship data in order to determine whether a selected network interaction from one of the members is permitted in view of at least one of the corresponding combined role features, and facilitating the selected network interaction between the members when determined as permitted;
wherein at least one of the corresponding combined role features of the new relationship pair is used to define as permitted at least one of the network interaction type, the network interaction content, or the network interaction format.
22. The method of claim 21 further comprising the step of defining a minimum number of the new first role features to become part of the combined first role features.
23. The method of claim 21 further comprising the step of defining a minimum number of the new second role features to become part of the combined second role features.
24. A method for defining an online relationship pair between a first member and a second member, the relationship pair including a first relationship role assigned to the first member having a plurality of first role features for use in managing network interaction on a communications network between the first member and the second member, and a second relationship role assigned to the second member having a plurality of second role features for use in managing the network interaction between the first member and the second member, the method comprising:
assigning the first relationship role to the first member such that the first role features are characteristic of the first relationship role;
assigning the second relationship role to the second member such that the second role features are characteristic of the second relationship role, such that the second member must confirm the second relationship role in order for the first member to be able to use the first relationship role in the network interaction between the first and second members;
storing the first role and the second role with their associated role features in a storage as relationship data representing the relationship pair; and
accessing the relationship data in order to determine whether a selected network interaction from one of the members is permitted in view of at least one of the corresponding relationship roles or role features of at least one of the first role or second role of the relationship pair, and facilitating the selected network interaction between the members when determined as permitted;
wherein said at least one of the corresponding relationship roles or role features of at least one of the first role or second role of the relationship pair is used to define as permitted at least one of the network interaction type, the network interaction content, or the network interaction format.
Priority Applications (8)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US12/619,451 US20110035444A1 (en) | 2009-08-06 | 2009-11-16 | Relationship security in online social and professional networks and communities |
CA2807603A CA2807603C (en) | 2009-08-06 | 2010-08-06 | Relationship and security in online social and professional networks and communities |
EP10805918.9A EP2462720B1 (en) | 2009-08-06 | 2010-08-06 | Relationship and security in online social and professional networks and communities |
CN201080041686.9A CN102640452B (en) | 2009-08-06 | 2010-08-06 | For relation and the safe method of online social and specialized network and community |
CA3084695A CA3084695C (en) | 2009-08-06 | 2010-08-06 | Relationship and security in online social and professional networks and communities |
PCT/CA2010/001216 WO2011014959A1 (en) | 2009-08-06 | 2010-08-06 | Relationship and security in online social and professional networks and communities |
US13/223,947 US8364753B2 (en) | 2009-08-06 | 2011-09-01 | Relationship and security in online social and professional networks and communities |
US14/608,764 USRE47205E1 (en) | 2009-08-06 | 2015-01-29 | Relationship and security in online social and professional networks and communities |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US27201009P | 2009-08-06 | 2009-08-06 | |
US12/619,451 US20110035444A1 (en) | 2009-08-06 | 2009-11-16 | Relationship security in online social and professional networks and communities |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/223,947 Continuation US8364753B2 (en) | 2009-08-06 | 2011-09-01 | Relationship and security in online social and professional networks and communities |
Publications (1)
Publication Number | Publication Date |
---|---|
US20110035444A1 true US20110035444A1 (en) | 2011-02-10 |
Family
ID=43535616
Family Applications (3)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US12/619,451 Abandoned US20110035444A1 (en) | 2009-08-06 | 2009-11-16 | Relationship security in online social and professional networks and communities |
US13/223,947 Ceased US8364753B2 (en) | 2009-08-06 | 2011-09-01 | Relationship and security in online social and professional networks and communities |
US14/608,764 Active USRE47205E1 (en) | 2009-08-06 | 2015-01-29 | Relationship and security in online social and professional networks and communities |
Family Applications After (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/223,947 Ceased US8364753B2 (en) | 2009-08-06 | 2011-09-01 | Relationship and security in online social and professional networks and communities |
US14/608,764 Active USRE47205E1 (en) | 2009-08-06 | 2015-01-29 | Relationship and security in online social and professional networks and communities |
Country Status (5)
Country | Link |
---|---|
US (3) | US20110035444A1 (en) |
EP (1) | EP2462720B1 (en) |
CN (1) | CN102640452B (en) |
CA (2) | CA2807603C (en) |
WO (1) | WO2011014959A1 (en) |
Cited By (21)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8271894B1 (en) * | 2011-08-23 | 2012-09-18 | Google Inc. | Social computing personas for protecting identity in online social interactions |
CN103167030A (en) * | 2013-03-07 | 2013-06-19 | 北京山海树科技有限公司 | System and method for detecting and building relations in communication system |
US8949940B1 (en) | 2011-10-12 | 2015-02-03 | Mahasys LLC | Aggregating data from multiple issuers and automatically organizing the data |
US20160028581A1 (en) * | 2012-09-07 | 2016-01-28 | Oracle International Corporation | Role-driven notification system including support for collapsing combinations |
US9467355B2 (en) | 2012-09-07 | 2016-10-11 | Oracle International Corporation | Service association model |
US20160321576A1 (en) * | 2009-10-12 | 2016-11-03 | Mood Enterprises Ltd | System for representing an organization |
US9542400B2 (en) | 2012-09-07 | 2017-01-10 | Oracle International Corporation | Service archive support |
US9621435B2 (en) | 2012-09-07 | 2017-04-11 | Oracle International Corporation | Declarative and extensible model for provisioning of cloud based services |
US9838370B2 (en) | 2012-09-07 | 2017-12-05 | Oracle International Corporation | Business attribute driven sizing algorithms |
US20170364841A1 (en) * | 2016-06-16 | 2017-12-21 | Adp, Llc | Dynamic Organization Structure Model |
US10015185B1 (en) * | 2016-03-24 | 2018-07-03 | EMC IP Holding Company LLC | Risk score aggregation for automated detection of access anomalies in a computer network |
US10142174B2 (en) | 2015-08-25 | 2018-11-27 | Oracle International Corporation | Service deployment infrastructure request provisioning |
US10148530B2 (en) | 2012-09-07 | 2018-12-04 | Oracle International Corporation | Rule based subscription cloning |
US10187399B2 (en) * | 2015-04-07 | 2019-01-22 | Passport Health Communications, Inc. | Enriched system for suspicious interaction record detection |
US20190045013A1 (en) * | 2017-08-05 | 2019-02-07 | Piiipo Inc. | System and method for forming a network with integrated managerial positions and task placement |
US11075791B2 (en) | 2012-09-07 | 2021-07-27 | Oracle International Corporation | Failure handling in the execution flow of provisioning operations in a cloud environment |
US11151246B2 (en) | 2019-01-08 | 2021-10-19 | EMC IP Holding Company LLC | Risk score generation with dynamic aggregation of indicators of compromise across multiple categories |
US11570295B2 (en) * | 2021-04-13 | 2023-01-31 | First Orion Corp. | Providing enhanced call content based on call number association |
US11622039B2 (en) | 2021-04-13 | 2023-04-04 | First Orion Corp. | Providing enhanced call content |
US11683415B2 (en) | 2021-04-13 | 2023-06-20 | First Orion Corp. | Providing enhanced call content to a mobile device |
US11792240B2 (en) | 2021-04-13 | 2023-10-17 | First Orion Corp. | Enhanced call content delivery with message code |
Families Citing this family (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8661359B2 (en) * | 2010-01-12 | 2014-02-25 | Microsoft Corporation | Relevance oriented graphical representation of discussion messages |
US9477698B2 (en) * | 2012-02-22 | 2016-10-25 | Salesforce.Com, Inc. | System and method for inferring reporting relationships from a contact database |
CN107133716A (en) * | 2017-03-31 | 2017-09-05 | 上海银澎信息科技有限公司 | For the method and apparatus for the supply chain for creating supply and marketing |
CN110020341B (en) * | 2017-08-30 | 2022-09-16 | 腾讯科技(深圳)有限公司 | Member role determination method, device and storage medium |
CN112115381A (en) * | 2020-09-28 | 2020-12-22 | 北京百度网讯科技有限公司 | Construction method and device of convergence relationship network, electronic equipment and medium |
AU2022370457A1 (en) * | 2021-10-18 | 2024-04-18 | Bumble Ip Holdco Llc | Role-based social network |
CN113839779B (en) * | 2021-11-29 | 2022-03-18 | 中国电子科技集团公司第三十研究所 | Private key amplification processing method, device, equipment and storage medium based on FHT |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20090024747A1 (en) * | 2007-07-20 | 2009-01-22 | International Business Machines Corporation | System and method for visual representation of a social network connection quality |
US20100198742A1 (en) * | 2009-02-03 | 2010-08-05 | Purplecomm, Inc. | Online Social Encountering |
US20100205066A1 (en) * | 2007-08-23 | 2010-08-12 | Yuan Der Ho | Sharing information on a network-based social platform |
US20100235886A1 (en) * | 2009-03-16 | 2010-09-16 | International Business Machines Corporation | Automated relationship management for electronic social networks |
Family Cites Families (23)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6092064A (en) * | 1997-11-04 | 2000-07-18 | International Business Machines Corporation | On-line mining of quantitative association rules |
US8117281B2 (en) * | 2006-11-02 | 2012-02-14 | Addnclick, Inc. | Using internet content as a means to establish live social networks by linking internet users to each other who are simultaneously engaged in the same and/or similar content |
US7685016B2 (en) * | 2003-10-07 | 2010-03-23 | International Business Machines Corporation | Method and system for analyzing relationships between persons |
US7526464B2 (en) * | 2003-11-28 | 2009-04-28 | Manyworlds, Inc. | Adaptive fuzzy network system and method |
US8015119B2 (en) * | 2004-01-21 | 2011-09-06 | Google Inc. | Methods and systems for the display and navigation of a social network |
US7647256B2 (en) * | 2004-01-29 | 2010-01-12 | Novell, Inc. | Techniques for establishing and managing a distributed credential store |
US7885901B2 (en) * | 2004-01-29 | 2011-02-08 | Yahoo! Inc. | Method and system for seeding online social network contacts |
US8010619B1 (en) * | 2004-04-07 | 2011-08-30 | Cisco Technology Inc. | Methods and apparatus for integrating social network metrics and reputation data |
US8849862B2 (en) * | 2004-05-21 | 2014-09-30 | Rsvpro, Llc | Architectural frameworks, functions and interfaces for relationship management (AFFIRM) |
CN101233538A (en) * | 2005-05-31 | 2008-07-30 | 电子湾有限公司 | User created social networks |
US7937480B2 (en) * | 2005-06-02 | 2011-05-03 | Mcafee, Inc. | Aggregation of reputation data |
US7689537B2 (en) * | 2005-08-10 | 2010-03-30 | International Business Machines Corporation | Method, system, and computer program product for enhancing collaboration using a corporate social network |
US7827208B2 (en) * | 2006-08-11 | 2010-11-02 | Facebook, Inc. | Generating a feed of stories personalized for members of a social network |
CN101495991A (en) * | 2005-12-14 | 2009-07-29 | 费斯布克公司 | Systems and methods for social mapping |
DE602006014246D1 (en) * | 2006-03-06 | 2010-06-24 | Alcatel Lucent | Condition control for transmitting messages |
US9253183B2 (en) * | 2006-11-16 | 2016-02-02 | Mark Stephen Meadows | Systems and methods for authenticating an avatar |
US8214497B2 (en) * | 2007-01-24 | 2012-07-03 | Mcafee, Inc. | Multi-dimensional reputation scoring |
US20080228698A1 (en) * | 2007-03-16 | 2008-09-18 | Expanse Networks, Inc. | Creation of Attribute Combination Databases |
US7904461B2 (en) * | 2007-05-01 | 2011-03-08 | Google Inc. | Advertiser and user association |
US8180807B2 (en) * | 2007-11-27 | 2012-05-15 | At&T Intellectual Property I, L.P. | System and method of determining relationship information |
US8078682B1 (en) * | 2008-10-17 | 2011-12-13 | Intuit Inc. | Method and system for managing contact information among relationships |
US8392357B1 (en) * | 2008-10-31 | 2013-03-05 | Trend Micro, Inc. | Trust network to reduce e-mail spam |
US9015597B2 (en) * | 2009-07-31 | 2015-04-21 | At&T Intellectual Property I, L.P. | Generation and implementation of a social utility grid |
-
2009
- 2009-11-16 US US12/619,451 patent/US20110035444A1/en not_active Abandoned
-
2010
- 2010-08-06 WO PCT/CA2010/001216 patent/WO2011014959A1/en active Application Filing
- 2010-08-06 CA CA2807603A patent/CA2807603C/en active Active
- 2010-08-06 EP EP10805918.9A patent/EP2462720B1/en active Active
- 2010-08-06 CA CA3084695A patent/CA3084695C/en active Active
- 2010-08-06 CN CN201080041686.9A patent/CN102640452B/en active Active
-
2011
- 2011-09-01 US US13/223,947 patent/US8364753B2/en not_active Ceased
-
2015
- 2015-01-29 US US14/608,764 patent/USRE47205E1/en active Active
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20090024747A1 (en) * | 2007-07-20 | 2009-01-22 | International Business Machines Corporation | System and method for visual representation of a social network connection quality |
US20100205066A1 (en) * | 2007-08-23 | 2010-08-12 | Yuan Der Ho | Sharing information on a network-based social platform |
US20100198742A1 (en) * | 2009-02-03 | 2010-08-05 | Purplecomm, Inc. | Online Social Encountering |
US20100235886A1 (en) * | 2009-03-16 | 2010-09-16 | International Business Machines Corporation | Automated relationship management for electronic social networks |
Cited By (30)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20160321576A1 (en) * | 2009-10-12 | 2016-11-03 | Mood Enterprises Ltd | System for representing an organization |
US8375331B1 (en) * | 2011-08-23 | 2013-02-12 | Google Inc. | Social computing personas for protecting identity in online social interactions |
US8271894B1 (en) * | 2011-08-23 | 2012-09-18 | Google Inc. | Social computing personas for protecting identity in online social interactions |
US8914749B1 (en) | 2011-08-23 | 2014-12-16 | Google Inc. | Social computing personas for protecting identity in online social interactions |
US9154467B1 (en) | 2011-08-23 | 2015-10-06 | Google Inc. | Social computing personas for protecting identity in online social interactions |
US8949940B1 (en) | 2011-10-12 | 2015-02-03 | Mahasys LLC | Aggregating data from multiple issuers and automatically organizing the data |
US10212053B2 (en) | 2012-09-07 | 2019-02-19 | Oracle International Corporation | Declarative and extensible model for provisioning of cloud based services |
US20160028581A1 (en) * | 2012-09-07 | 2016-01-28 | Oracle International Corporation | Role-driven notification system including support for collapsing combinations |
US9501541B2 (en) | 2012-09-07 | 2016-11-22 | Oracle International Corporation | Separation of pod provisioning and service provisioning |
US9542400B2 (en) | 2012-09-07 | 2017-01-10 | Oracle International Corporation | Service archive support |
US9621435B2 (en) | 2012-09-07 | 2017-04-11 | Oracle International Corporation | Declarative and extensible model for provisioning of cloud based services |
US9646069B2 (en) * | 2012-09-07 | 2017-05-09 | Oracle International Corporation | Role-driven notification system including support for collapsing combinations |
US9838370B2 (en) | 2012-09-07 | 2017-12-05 | Oracle International Corporation | Business attribute driven sizing algorithms |
US11075791B2 (en) | 2012-09-07 | 2021-07-27 | Oracle International Corporation | Failure handling in the execution flow of provisioning operations in a cloud environment |
US10009219B2 (en) | 2012-09-07 | 2018-06-26 | Oracle International Corporation | Role-driven notification system including support for collapsing combinations |
US9467355B2 (en) | 2012-09-07 | 2016-10-11 | Oracle International Corporation | Service association model |
US10148530B2 (en) | 2012-09-07 | 2018-12-04 | Oracle International Corporation | Rule based subscription cloning |
CN103167030A (en) * | 2013-03-07 | 2013-06-19 | 北京山海树科技有限公司 | System and method for detecting and building relations in communication system |
US10187399B2 (en) * | 2015-04-07 | 2019-01-22 | Passport Health Communications, Inc. | Enriched system for suspicious interaction record detection |
US10142174B2 (en) | 2015-08-25 | 2018-11-27 | Oracle International Corporation | Service deployment infrastructure request provisioning |
US10015185B1 (en) * | 2016-03-24 | 2018-07-03 | EMC IP Holding Company LLC | Risk score aggregation for automated detection of access anomalies in a computer network |
US10657482B2 (en) * | 2016-06-16 | 2020-05-19 | Adp, Llc | Dynamic organization structure model |
US20170364841A1 (en) * | 2016-06-16 | 2017-12-21 | Adp, Llc | Dynamic Organization Structure Model |
US20190045013A1 (en) * | 2017-08-05 | 2019-02-07 | Piiipo Inc. | System and method for forming a network with integrated managerial positions and task placement |
US11151246B2 (en) | 2019-01-08 | 2021-10-19 | EMC IP Holding Company LLC | Risk score generation with dynamic aggregation of indicators of compromise across multiple categories |
US11570295B2 (en) * | 2021-04-13 | 2023-01-31 | First Orion Corp. | Providing enhanced call content based on call number association |
US11622039B2 (en) | 2021-04-13 | 2023-04-04 | First Orion Corp. | Providing enhanced call content |
US11683415B2 (en) | 2021-04-13 | 2023-06-20 | First Orion Corp. | Providing enhanced call content to a mobile device |
US11792240B2 (en) | 2021-04-13 | 2023-10-17 | First Orion Corp. | Enhanced call content delivery with message code |
US11949813B2 (en) | 2021-04-13 | 2024-04-02 | First Orion Corp. | Providing enhanced call content based on call number association |
Also Published As
Publication number | Publication date |
---|---|
CA2807603C (en) | 2020-08-25 |
EP2462720A1 (en) | 2012-06-13 |
US20120110079A1 (en) | 2012-05-03 |
USRE47205E1 (en) | 2019-01-15 |
EP2462720B1 (en) | 2020-07-08 |
CA3084695C (en) | 2023-04-18 |
CA3084695A1 (en) | 2011-02-10 |
CN102640452B (en) | 2016-03-02 |
CN102640452A (en) | 2012-08-15 |
WO2011014959A1 (en) | 2011-02-10 |
EP2462720A4 (en) | 2015-01-28 |
US8364753B2 (en) | 2013-01-29 |
CA2807603A1 (en) | 2011-02-10 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
USRE47205E1 (en) | Relationship and security in online social and professional networks and communities | |
US11720979B2 (en) | Computing device for facilitating electronic communication among users in a network including professional acquaintances | |
US20210312513A1 (en) | Coordinating products and services for customers | |
US20130290198A1 (en) | Estate and life event organization and management system | |
Inbar et al. | Lowering the line of visibility: incidental users in service encounters | |
US20020099568A1 (en) | System and method for facilitating the coordination of care of an individual and dissemination of information | |
US20030130866A1 (en) | System and method for facilitating the care of an individual and dissemination of infromation | |
US20120197662A1 (en) | System and Method for Facilitating Home Care Activities | |
US20140164080A1 (en) | Organizational tools and or a collaboration system utilizing the same therein | |
US20140164081A1 (en) | Organizational tools and or a collaboration system utilizing the same therein | |
US20160342741A1 (en) | Service-oriented, integrative networking platform, system and method | |
Sullivan et al. | Sustaining primary care teams in the midst of a pandemic | |
WO2019015786A1 (en) | System and method of coordinating products and services for customers | |
Haddow et al. | Stakeholder perspectives on new ways of delivering unscheduled health care: the role of ownership and organizational identity | |
Scheckler et al. | Service coordination in HUD housing during the COVID-19 pandemic: Bridging the gap | |
Hladky | Comparison of home-office IS/ICT support in the banking sector in the USA and the Czech Republic |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |