WO2018102912A1

WO2018102912A1 - Systems and methods for controlling network access by delegate users

Info

Publication number: WO2018102912A1
Application number: PCT/CA2017/051356
Authority: WO
Inventors: Pierre Antoine Roberge; Martin Philip CRAWFORD; Fedja STEVANOVIC; Glenn Alfred BARRETT
Original assignee: Rocket Piggy Corp.
Priority date: 2016-12-09
Filing date: 2017-11-14
Publication date: 2018-06-14

Abstract

Data messaging systems and methods in which binary or granular permissions or rules can be specified for a delegate user to allow messages to be delivered or displayed to the delegate user, or to allow for messages to be transmitted by the delegate user, or to enforce messages to be reviewed by a primary user under certain conditions, or to prevent transmission or display of messages in still other conditions. Binary or granular permissions or rules may be specified globally, and have effect for multiple communication services.

Description

SYSTEMS AND METHODS FOR CONTROLLING NETWORK ACCESS BY

DELEGATE USERS

Fietd

[1] The described embodiments relate to access control in networked communication systems and, in particular, to the provision of access to delegate users in a networked communication system.

Introduction

[2] Online communication systems enable individuals to communicate using a wide variety of devices, and from a wide variety of locations. In the past decade, social networking services have expanded the types of online communication systems available. These social networking services have been very popular, often enhancements over, or even supplanting, prior communications systems.

[3] At its most basic, a communication system allows individuals to communicate using a common protocol. Generally, social networking services operate in isolation from one network to another, requiring individuals to use separate clients to communicate with users on each service.

[4] Moreover, in some contexts, it may be desirable to limit the communication of certain individuals. For example, in the case of children, parents or guardians may wish to limit or review the communications of their children with other parties or businesses. Alternatively, many social networks do not allow children under a predetermined age to enroll and obtain an account, leaving the child without a means of communicating with family members even if approved by a parent of guardian.

[5] Social networking and other communication services generally make little or no effort to enable parents or guardians to review or limit the communications of their children. Most often, such services simply require in their terms of service that each user be of a minimum age, although online age verification can be easily avoided by children. In some cases, services may provide limited opportunity for parents or guardians to decide whether a third party can communicate with a child (e.g., by offering the binary selection of allowing or disallowing communication with certain contacts). Such services generally do not allow for alternative or more complex treatments of the message prior to transmission to the child. Moreover, such choices must be made and configured separately for each social networking service.

Summary

[6] In a first broad aspect, there is provided a network access control method for providing and managing access to an inbound message by a delegate user, the method comprising: receiving, at a server, an inbound message from a first network system server, the inbound message received via a first application programming interface associated with the first network system server; processing the inbound message to determine the delegate user to which the inbound message is to be delivered and identifying one or more user accounts associated with the delegate user; determining one or more rules set by a primary user of the user account and, based on the one or more rules, processing the inbound message to determine whether it is to be delivered to the delegate user.

[7] The method may further comprise receiving, at the server, a second inbound message from a second network system server, the second inbound message received via a second application programming interface associated with the second network system server.

[8] The method may further comprise, prior to receiving the inbound message, a user device transmitting the message to the first network system server.

[9] In some cases, the inbound message comprises a recipient identifier. In some cases, the recipient identifier is an identifier used by the first network system to identify the user.

[10] The network access control method of claim 1 , wherein the inbound message comprises a delegate indication, the method further comprising the server determining whether the delegate indication is previously associated with the user account.

[11] The method may further comprise the network access control server, prior to receiving the inbound message, associating the delegate indication with the user account.

[12] The method may further comprise, prior to receiving the inbound message, receiving one or more rules associated with the delegate user and associating the one or more rules with the user account. [13] In some cases, the rules comprise a network identifier rule. In some cases, the rules comprise a message type rule. In some cases, the rules comprise a message direction rule. In some cases, the rules comprise a message frequency rule. In some cases, the rules comprise a keyword rule. In some cases, the rules comprise a time rule. In some cases, the rules comprise a a date rule. In some cases, the rules comprise a location rule.

[14] The method may further comprise determining, based on the one or more rules, that the inbound message can be transmitted to a delegate user device.

[15] The method may further comprise determining, based on the one or more rules, that the inbound message is not to be relayed to a delegate user device.

[16] The method may further comprise transmitting a block notification to a primary user device.

[17] The method may further comprise determining, based on the one or more rules, that the inbound message is to be held for further processing.

[18] The method may further comprise transmitting the inbound message to a primary user device for review.

[19] The method may further comprise transmitting a notification of the inbound message to a primary user device for review.

[20] The method may further comprise receiving an approved authorization from the primary user device and, based on the approved authorization, permitting transmission of the inbound message to the delegate user device.

[21] The method may further comprise transmitting the inbound message to a delegate user device based on the approved authorization.

[22] The method may further comprise receiving a declined authorization from the primary user device and, based on the declined authorization, preventing relaying of the message to the delegate user.

[23] In another broad aspect, there is provided a network access control method for providing and managing access to an outbound message by a delegate user, the method comprising: receiving, at a server, an outbound message from a delegate user device, the outbound message comprising a recipient identifier; processing the outbound message to determine a first network system server to which the message is to be delivered; transmitting the processed outbound message to the first network system server via a first application programming interface associated with the first network system server. [24] In some cases, the outbound message comprises a recipient identifier, the method further comprising the server determining the user account with which the delegate user device is associated. In some cases, the recipient identifier is an identifier used by the first network system to identify the user.

[25] In some cases, the outbound message comprises a delegate indication, further comprising the server determining whether the delegate indication is previously associated with the user account.

[26] The method may further comprise, the network access control server, prior to receiving the outbound message, associating the delegate indication with the user account.

[27] The method may further comprise evaluating the outbound message based on one or more rules.

[28] The method may further comprise, prior to receiving the outbound message, receiving one or more rules associated with the delegate user and associating the one or more rules with the user account.

[29] In some cases, the rules comprise a network identifier rule. In some cases, the rules comprise a network user identifier rule. In some cases, the rules comprise a message type rule. In some cases, the rules comprise a message direction rule. In some cases, the rules comprise a message frequency rule. In some cases, the rules comprise a keyword rule. In some cases, the rules comprise a time rule. In some cases, the rules comprise a date rule. In some cases, the rules comprise a location rule.

[30] The method may further comprise determining, based on the one or more rules, that the outbound message can be transmitted by the delegate user device.

[31] The method may further comprise determining, based on the one or more rules, preventing relaying of the inbound message to a delegate user device.

[32] The method may further comprise determining, based on the one or more rules, that the outbound message is to be held for further processing.

[33] The method may further comprise transmitting the outbound message to a primary user device for review.

[34] The method may further comprise transmitting a notification of the outbound message to a primary user device. [35] The method may further comprise receiving an approved authorization from the primary user device and, based on the approved authorization, permitting relaying of the outbound message to a first network system server.

[36] The method may further comprise transmitting the outbound message to the first network system server based on the approved authorization.

[37] The method may further comprise receiving a declined authorization from the primary user device and, based on the declined authorization, preventing transmission of the outbound message.

[38] In yet another broad aspect, there is provided a network access control system for providing access to a user account by a delegate user, the system comprising: a network interface; a memory unit; and a processing unit coupled to the memory unit and the network interface, the processing unit being configured to carry out the methods described herein.

[39] In still another broad aspect, there is provided a non-transitory computer readable medium storing computer executable instructions, the instructions when executed by a computer process for causing the computer process to carry out the methods described herein.

Brief Description of the Drawings

[40] A preferred embodiment of the present invention will now be described in detail with reference to the drawings, in which:

FIG. 1 is a schematic block diagram of a network access control system in accordance with at least some embodiments;

FIG. 2A is a schematic block diagram of a platform architecture implemented by network access control system of FIG. 1 ;

FIG. 2B is an example database schema for use by network access control system of FIG. 1 ;

FIG. 3A is a simplified process flow diagram for receiving an inbound message in an example network access control system in accordance with at least some embodiments;

FIG. 3B is a simplified process flow diagram for transmitting an outbound message in an example network access control system in accordance with at least some embodiments; and FIG. 4 is a simplified process flow diagram for creating a contact in a network access control system in accordance with at least some embodiments.

Description of Exemplary Embodiments

[41] It will be appreciated that for simplicity and clarity of illustration, where considered appropriate, reference numerals may be repeated among the figures to indicate corresponding or analogous elements or steps. In addition, numerous specific details are set forth in order to provide a thorough understanding of the exemplary embodiments described herein. However, it will be understood by those of ordinary skill in the art that the embodiments described herein may be practiced without these specific details. In other instances, well-known methods, procedures and components have not been described in detail since these are known to those skilled in the art. Furthermore, it should be noted that this description is not intended to limit the scope of the embodiments described herein, but rather as merely describing one or more exemplary implementations.

[42] It should also be noted that the terms "coupled" or "coupling" as used herein can have several different meanings depending in the context in which these terms are used. For example, the terms coupled or coupling may be used to indicate that an element or device can electrically, optically, or wirelessly send data to another element or device as well as receive data from another element or device.

[43] The example embodiments of the systems and methods described herein may be implemented as a combination of hardware or software. In some cases, the example embodiments described herein may be implemented, at least in part, by using one or more computer programs, executing on one or more programmable devices comprising at least one processing element, a data storage element (including volatile memory, non-volatile memory, storage elements, or any combination thereof) and a network interface (e.g., Bluetooth™, IEEE 802.11 , or other networking protocols). These devices may also have zero or more input devices (e.g. a keyboard, mouse, touchscreen, or the like), and at least one output device (e.g. an LED indicator, a display screen, a printer, a wireless radio, or the like) depending on the nature of the device.

[44] It should also be noted that there may be some elements that are used to implement at least part of one of the embodiments described herein that may be implemented via software that is written in a high-level computer programming language such as one that employs an object-oriented paradigm. Accordingly, the program code may be written in Java, C++ or any other suitable programming language and may comprise modules or classes, as is known to those skilled in object oriented programming. Alternatively, or in addition thereto, some of these elements implemented via software may be written in assembly language, machine language or firmware as needed. In either case, the language may be a compiled or interpreted language.

[45] At least some of these software programs may be stored on a storage media (e.g. a computer readable medium such as, but not limited to, ROM, magnetic disk, optical disc) or a device that is readable by a general or special purpose programmable device. The software program code, when read by the programmable device, configures the programmable device to operate in a new, specific and predefined manner in order to perform at least one of the methods described herein.

[46] Furthermore, at least some of the programs associated with the systems and methods of the embodiments described herein may be capable of being distributed in a computer program product comprising a computer readable medium that bears computer usable instructions for one or more processors. The medium may be provided in various forms, including non-transitory forms such as, but not limited to, one or more diskettes, compact disks, tapes, chips, and magnetic and electronic storage.

[47] The described embodiments generally may provide a user with the ability to communicate to or from any supported networked communication service or social networking service, from a single client program on a single device. In some embodiments, the described embodiments may provide a user with the ability to communicate to or from any supported networked communication service or social networking service, from a one or more client programs on one or more devices. The described embodiments may improve the operation of certain devices, for example, by enabling a device to manage communications of delegate users with contacts that may be using disparate communication or social networks. For example, a primary user may set one or more rules to define permissible communications with a delegate user. These rules may be agnostic as to the specific social network a particular contact uses (although in some cases, rules can be specific to a social network), allowing the primary user to create a single set of consistent rules, and reducing the processing and storage requirements for the system that must enforce the rules for possibly millions of communications in realtime. In some cases, the described embodiments may also be used to facilitate regulatory compliance and protection, for example, by an organization for its employees.

[48] Moreover, the described embodiments generally may provide a user the ability to set binary or granular permissions or rules for one or more delegate user, that allow for messages to be delivered or displayed to a delegate user - or that allow for messages to be transmitted by a delegate user - if certain conditions are met, or to enforce messages to be reviewed by one or more primary user under certain conditions, or to prevent transmission or display of messages in still other conditions. In addition, the described embodiments allow the user to set binary or granular permissions or rules one time and have those rules enforced for multiple communication or social networking services.

[49] In general, messages may refer to messages with text, binary or multimedia content, such as messages, comments, transactions, status updates, etc. Messages may also refer to meta-messages relating to social network activity, such as "likes", "follows", "shares", etc. Each type of message may also be referred to as an interaction.

[50] Referring now to FIG. 1A, there is illustrated a schematic block diagram of a network access control system in accordance with at least some embodiments.

[51] In the example of FIG. 1A, network access control system 100 has a network access control server 110, a primary user device 1 12, a delegate user device 1 14, one or more network system servers 122a to 122n and one or more user devices 132a to 132n.

[52] Each of the devices and servers of network access control system 100 is generally equipped for data communication, and the connections shown between the devices and servers. For example, primary user device 112 can communicate with network access control server 110 via a data communication network such as the Internet (not shown). The data communication network can be constructed using various networking technologies and topologies. For example, portions of the network may be mobile data networks. Although not explicitly described in each case, communications between the various elements of system 100 generally involve session-level security, such as Transport Layer Security (TLS). [53] In some embodiments, delegate user device 114 may communicate with network access control server 110 via primary user device 112, with primary user device 112 acting as a communication gateway to network access control server 110. In some other embodiments, delegate user device 1 14 may communicate directly with network access control server 110 via a network.

[54] Each of primary user device 112, delegate user device 1 14 and user devices 132a to 132n may be a computing device, such as a smartphone, tablet computer, laptop or desktop computer or other device.

[55] Each of network access control server 1 10 and network system server 122a to 122n is a computer, such as a computer server. Network access control server 110 may act as the gateway between one or more network system servers 122a to 122n, and primary user device 112 and delegate user device 114.

[56] Network system servers 122a to 122n provide a communication or social networking service. In some embodiments, one or more network system servers 122a to 122n may provide a communication service such as e-mail or instant messaging.

[57] Each server and computing device described herein generally has a processor, volatile memory and non-volatile storage memory, at least one network interface. Depending on its configuration, each server and computing device may have input devices such as a keyboard, trackpad or touchscreen, output devices such as a display and speakers, and various other input/output devices as will be appreciated.

[58] Moreover, each server may be constructed from multiple devices, as in a server farm, which may be in geographically diverse locations, and accessed via a load balancer. Such arrangements are sometimes referred to as a "cloud" service. For example, network access control server 1 10 may be constructed of multiple edge node servers, which replicate and serve data in geographically diverse locations. The functionality described herein as provided by a particular server (e.g., network access control server 1 10) may be divided among multiple physical devices, which are then logically linked or merged from the third-party perspective. In some cases, one or more server may be a virtual machine, which operates in a host environment using virtualized hardware.

[59] Although the described embodiments generally refer to a primary user device and a delegate user device, in some embodiments, the primary user device or the delegate user device, or both, may be web-enabled devices and the network access control server 1 10 may perform some or all of the functions of the primary user device or delegate user device described herein. In such embodiments, the network access control server 1 10 may provide a web interface, which can be accessed by a computing device with a web browser to display the messages or review interfaces to the respective end user.

[60] Referring now to FIG. 2A, there is illustrated a schematic block diagram of a platform architecture implemented by network access control system 100 of FIG. 1.

[61] A primary user client application 212 is computer executable program code executed by, e.g., primary user device 112 of system 100, and is configured to communicate via a user application programming interface (API) 260 of the network access control module 210. Similarly, a delegate user client application 214 is computer executable program code executed by, e.g., delegate user device 114 of system 100, and is configured to communicate via user API 260 of the network access control module 210.

[62] Network access control module 210 is implemented, for example, via computer executable program code stored in a memory and executed by, e.g., network access control server 110. In particular, a processor 270 of the network access control server execute program code stored in a memory 272, and may store or retrieve data in database 240, or may process data (e.g., rules retrieved from rule records), as described herein. Network access control module 210 generally provides the user API 260 for interfacing with primary user client 212 and delegate user client 214 and to carry out the functions described further herein.

[63] Network access control module 210 further provides a database 240, which stores user account database 242, network system database 244, rules database 246 and log database 248.

[64] User account database 242 stores account information, such as unique user identifiers, names, and contact information for primary users and also for delegate users. Such account information may also be referred to as "profiles."

[65] Network database 244 stores credentials and identifiers of primary users for one or more of network system servers 122a to 122n. Credentials may be, for example, usernames, passwords, tokens and the like. In some embodiments, only primary users have accounts with network system servers 122a to 122n, i.e., delegate users may not have accounts of their own. In some alternative embodiments, delegate users may have accounts of their own with network system servers 122a to 122n.

[66] Rules database 246 stores one or more rules, which can be created by primary users and applied to messages to and from delegate users.

[67] Log database 248 stores records of each message managed by network access control module 210.

[68] Network access control module 210 also provides one or more network system adapter modules 252a to 252n. Each network system adapter module serves to process inbound messages from, and outbound messages to, a respective network system. In particular, each network system adapter module is configured to interoperate with a respective network API 222a to 222n of a corresponding network system server. For example, one network system adapter may interoperate with a first social networking platform, another network system adapter may interoperate with a second social network platform, and yet another network system adapter may interoperate with a messaging platform, and so on.

[69] Referring now to FIG. 2B, there is illustrated an example database schema, which can be used with database 240 of FIG. 2A.

[70] Database schema 280 has primary user profile records 282, delegate user profile records 284, network records 286, contact records 288 and rule records 290.

[71] A primary user profile record 282 can be created by a primary user, and can contain a name and e-mail address of the primary user, for example, and be linked zero-to-many to delegate user profile records 284 and network records 286. In some cases, multiple primary user records can be linked to a single delegate user profile record. For example, a first primary user (e.g., mother) may grant permission to another user (e.g., father) to have primary user rights for a particular delegate user (e.g., child).

[72] A delegate user profile record 284 can be created by a primary user for each delegate user, and each such record can also can contain a name and, optionally, e- mail address for a delegate user. Likewise, multiple delegate user records can be linked to a single primary user record, or to multiple primary user records.

[73] A network record 286 can be created by the primary user, and contain a network system identifier and the credentials of the primary user identified in the linked primary user record profile 282 for that network system. For example, if the network system is a social networking service, the credentials may be the user's authentication credentials for that social networking service.

[74] Each of the primary user profile record 282, the delegate user profile record 284 and the network record 286 can be linked zero-to-many with contact records 288. Contact records can be created by primary users. For example, the primary user may create contact records based on existing connections in one or more network systems (e.g., by finding "friends" on a social networking system). In other cases, the primary user may provide contact information for a target connection. In some cases, the primary user may first send an invitation message to the contact, the invitation message may contain, or may be, an invitation URL, which itself may contain a unique token. The unique token may be used by network access controller server 110 to identify the primary user that created the invitation message. The invitation URL or invitation message can then be sent to the contact via the network system or via other channels (e.g., e-mail). The contact can navigate to the invitation URL to verify the connection and, if necessary, to authorize communications via a respective network system API.

[75] In some cases, delegate users may be permitted to create contact records, although this may be subject to review and approval by a primary user. In some cases, the network access control server may prevent delegate users from creating a contact record where it would be prohibited by law, even if authorized by a primary user.

[76] Each contact record 288 identifies an individual that is connected with the primary user on one or more network system. In the context of social networks, the contact may be an individual or organization that the primary user "follows," "likes", "friended", or has in their contact list. In some cases, if an individual has multiple network system accounts, the contact record may contain a priority ranking for outbound messages.

[77] Rule records 290 may be linked zero-to-many to delegate user profile record 284. Rule records 290 can contain rule expression definitions for managing messages by a delegate user, a rule priority for resolving conflicts with other rules, along with rule resolution definitions, as described further herein.

[78] Rules may be conditional rules or criteria rules. Conditional rules generally are evaluated using the logical AND operator, such that all conditional rules must be met for the rule expression to evaluate as TRUE. Criteria rules generally are evaluated using the logical OR operator, such that one or more criteria rules is sufficient for the rule expression to evaluate as TRUE. If both conditional rules and criteria rules are present in a rule record, then the results of each are evaluated using a logical AND operation. That is, the rule expression evaluates as TRUE if all conditional rules are TRUE and one or more criteria rule is TRUE.

[79] In some embodiments, conditional rules may be used to determine when a rule is to be triggered, while criteria rules may be used to determine what to do with a message once the rule is triggered. In some cases, conditional rules may be the only rules specified in some rule records. In some other cases, criteria rules may be the only rules specified in some rule records.

[80] Examples of conditional rules that can be specified include, but are not limited to, a network system to which the rule applies, a contact to which the rule applies (e.g., a particular individual or individuals), and a direction to which the rule apples (e.g., inbound messages vs. outbound messages). Examples of criteria rules that can be specified include, but are not limited to, a frequency (e.g., number of messages permitted per day, per week, etc.) and matching keywords (e.g., profanity).

[81] Two example rule definitions are shown in Table 1 :

Table 1

[82] In some other embodiments, rule expression can be specified in different fashion, for example with the use of regular expressions. [83] Rule resolution definitions may be used to determine an action to take depending on the result of the rule expression evaluation. For example, rule resolution definitions can include, but are not limited to, allowing a message, blocking a message or holding a message for review by the primary user (or another primary user connected to the delegate user).

[84] In the event of an allowed message, the message may be allowed to propagate further (e.g., to the delegate user) and may be logged to log database 248.

[85] In the event of a blocked message, the message may be logged to log database 248. In some cases, a primary user may be notified when a message is blocked.

[86] In some embodiments, a primary user may be notified of all communications to or from a delegate user, regardless of approval, blocking, or review.

[87] In the event of held message, the message may be logged to log database 248, then optionally the primary user can be notified of the held message and given the opportunity to allow or block the message.

[88] Each rule record can be assigned to one or more delegate user profile records.

[89] Referring now to FIG. 3A, there is illustrated a simplified process flow diagram for receiving an inbound message, for example an inbound message, in a network access control system, such as network access control system 100 of FIG. 1. In the example, of network access control system 100, flow 300 may be performed by network access control server 1 10 when a user device 132a to 132n attempts to transmit an inbound message to delegate user device 114.

[90] Flow 300 begins at 302 with a user device, such as user device 132a to 132n transmitting an inbound message via its respective network system server 122a to

122n.

[91] At 304, network access control server 1 10 receives the inbound message from a network system server. The inbound message can be received via an API associated with the network system server, such as network APIs 222a to 222n. In some cases, the inbound message may be delivered directly to the network access control server, e.g., without the use of a network system server. Optionally, the inbound message can be logged in a log database 248 at 310. [92] Next, the network access control server 110 can process the inbound message as described herein. For example, the inbound message can include an indication of the delegate user to which it is directed. In some cases, the indication can be a recipient identifier, which may be a foreign identifier (e.g., a social networking service username) used by the originating network system server to identify the delegate user, or else may be an identifier provided by the network access control server. In some cases, the indication can be a name or e-mail address of the delegate user. In some cases, the recipient identifier may identify the primary user instead. At 306, the network access control server 110 can determine a user account associated with the recipient of the message (e.g., delegate user), for example, by using database 240 and searching network records 244 to determine the primary user record linked to the delegate user record. If there is more than one primary user record linked to the delegate user record, a priority ranking may be taken into account to determine which primary user record is to be used. In other cases, all linked primary users may be allowed to approve, block or review inbound messages, and the first response can be used by the network access control server - in some cases, this may be defined by a rule record.

[93] At 308, the network access control server 110 can determine whether any rule records are linked to the record of the inbound message recipient. For example, if the message specifies a delegate identifier, the rule records associated with the delegate record identified at 306 can be identified and retrieved.

[94] At 312, the network access control server 1 10 can evaluate one or more rules retrieved at 308, and as described herein. For example, the network access control server 110 may evaluate multiple rules according to their priority and the first filter to match its conditional and criteria rules can proceed to its defined rule resolution.

[95] If, based on the one or more rules, the rule resolution determines that the inbound message can be delivered, the message can be transmitted to the delegate user device at 322. Likewise, if, based on the one or more rules, the rule resolution determines that the inbound message is not to be delivered, the message can be blocked from further transmission to the delegate user device at 330.

[96] In some case, the rules may be a time of day or date rule, which can impose a delay before the inbound message is transmitted to delegate user (e.g., no messages to be transmitted after 7:00 pm and before 8:00 am). [97] If, based on the one or more rules, the rule resolution determines that the inbound message is to be held for review by a primary user, it may be held and the inbound message itself may be transmitted to the primary user device for review. In some cases, only a notification is transmitted and the primary user may retrieve the inbound message for review. In other cases, the primary user may be notified of all inbound messages independently of the result of the evaluation.

[98] Although the embodiment shown in flow 300 shows the primary user reviewing and authorizing or declining messages, in some cases the primary user may authorize one or more other primary users to review the messages of delegate users. In such cases, notifications of held messages may be transmitted to the authorized primary user device and the authorized primary user device may provide approve authorizations or decline authorizations.

[99] At 320, the primary user device may transmit an authorization and, based on the authorization, the inbound message may be transmitted to the delegate user device at 322. Otherwise, if the primary user device transmits a non-authorization, the inbound message may be blocked from transmission to the delegate user device, thus preventing review of the message by the delegate user.

[100] Process flow 300 may be repeated for each additional inbound message that is received. As described herein, the same process flow may be repeated for multiple originating network system servers.

[101] Referring now to FIG. 3B, there is illustrated a simplified process flow diagram for transmitting an outbound message, for example an outbound message, in a network access control system, such as network access control system 100 of FIG. 1. In the example, of network access control system 100, flow 350 may be performed by network access control server 1 10 when a delegate user device 114 attempts to transmit an outbound message to a user device 132a to 132n.

[102] Flow 350 begins at 352 with a delegate user device, such as delegate user device 1 14 transmitting an outbound message to network access control server 1 10.

[103] At 354, network access control server 1 10 receives the outbound message from the delegate user device. Optionally, the inbound message can be logged in a log database 248 at 360.

[104] Next, the network access control server 1 10 can process the outbound message as described herein. For example, the outbound message can include a recipient identifier for identifying a message recipient. At 356, the network access control server 1 10 can determine the corresponding network system recipient identifier, for example, by using database 240 and searching contact records 288 and linked network records 286 to determine the destination to which the outbound message is to be delivered.

[105] At 358, the network access control server 1 10 can determine whether any rule records are linked to the record of the outbound message sender. For example, if the message is sent by a delegate user, the rule records associated with the delegate user profile record can be retrieved.

[106] At 362, the network access control server 110 can evaluate one or more rules retrieved at 358, and as described herein. For example, the network access control server 110 may evaluate multiple rules according to their priority and the first filter to match its conditional and criteria rules can proceed to its defined rule resolution.

[107] If, based on the one or more rules, the rule resolution determines that the outbound message can be delivered, the message can be transmitted to the appropriate network system server at 372. Likewise, if, based on the one or more rules, the rule resolution determines that the outbound message is not to be delivered, the message can be blocked from further transmission to a network system server at 380.

[108] If, based on the one or more rules, the rule resolution determines that the outbound message is to be held for review by a primary user, it may be held and the outbound message itself may be transmitted to the primary user device for review. In some cases, only a notification is transmitted and the primary user may retrieve the outbound message for review.

[109] Although the embodiment shown in flow 350 shows the primary user reviewing and authorizing or declining messages, in some cases the primary user may authorize one or more authorized primary users to review the messages of other delegate users. In such cases, notifications of held messages may be transmitted to the authorized primary user device and the authorized primary user device may provide approve authorizations or decline authorizations.

[110] At 370, the primary user device may transmit an authorization and, based on the authorization, the outbound message may be transmitted to the intended user device at 372 (e.g., a user device 132a to 132n associated with a contact record). Otherwise, if the primary user device transmits a non-authorization, the outbound message may be blocked from transmission to a network system server.

[111] Process flow 350 may be repeated for each additional outbound message that is received. As described herein, the same process flow may be repeated for multiple destination network system servers.

[112] Referring now to FIG. 4, there is illustrated a simplified process flow diagram for creating a contact record in a network access control system, such as network access control system 100 of FIG. 1. For example, the contact record may be for a user of a third-party network system (which users may operate one or more user device 132a to 132n), for which a primary user wishes to create one or more rules for communicating with a delegate user.

[113] Flow 400 begins at 405 with a primary user selecting via a user device, such as user device 132a to 132n, a contact to be connected to a delegate user. If the primary user has previously connected a network system, then the contact may be selected from among a plurality of contacts within the connected network system. Otherwise, or alternatively, the primary user may provide contact information for the desired contact, such as a name, e-mail address or phone number.

[114] At 410, the primary user selects one or more delegate user that is to be connected to the contact, transmitting an inbound message via its respective network system server 122a to 122n.

[115] At 412, the primary user may create one or more rule records and associate them with the delegate user record. Optionally, the one or more rule records can contain an identification of the new contact, thus creating a link between the delegate user, the contact and the rule. In some cases, the primary user may select previously-created rule records and associate them with the delegate user record, the newly-created contact, or both.

[116] At 415, the user device of the primary user transmits the contact identification and delegate selection to the network access control server. In some cases, the user device may also transmit an invitation setting, which can be used by the network access control server to determine whether to proactively transmit an invitation notification.

[117] At 420, the network access control server determines whether the contact identification corresponds to a known contact within the network access control system. If the contact is known, then the network access control server may determine whether the contact has previously activated or used a program application that is configured to receive and process requests from network access control server. For example, if the contact is a "XYZ" social network user, and the contact has enabled their "XYZ" social network messenger application for use with the network access control server (e.g., by installing a plugin), then the network access control server may transmit a contact invitation notification via the "XYZ" social network messenger application.

[118] If the contact has enabled a program application to receive and process requests from network access control server, then an invitation can be transmitted at 452 and, if accepted by the contact at 455, the network access control server may be authenticated to access the contact's network system account at 460 via a respective network system API. For example, for a first social network user, network access control server may be authorized via the OAuth2 protocol.

[119] At 465, the authenticated contact and the selected delegate users are connected by network access control server, for example, by creating and linking appropriate records in database 240.

[120] Optionally, at 477, the primary user may create one or more additional rule records - or identify previously created rule records - and link them with the delegate user record. The one or more rule records can identify the newly-created contact, thus creating an association between the delegate user, the contact and the rule.

[121] Finally, network access control server may update and proceed to further processing at 480.

[122] If the contact is not using a suitable application at 450, or if the contact is unknown at 420 but the primary user has requested the network access control server to send an invitation as determined at 425, then the network access control server may generate and transmit an invitation notification (e.g., e-mail) at 435.

[123] If the primary user did not request the invitation to be sent, then the network access control server determines this at 425 and instead generates a link (e.g., URL), which can be transmitted back to the user device of the primary user and provided to a prospective contact out-of-band (not shown). For example, the link may be transmitted in an e-mail message, mailed, communicated verbally or otherwise.

[124] At 440, the network access control server receives an invitation reply, for example, via a web server at a link generated at 435 or 430. [125] At 470, the network access control server determines whether the invitation reply declines the contact invitation, in which case the process flow ends and the network access control server updates its database accordingly at 480.

[126] if the invitation reply accepts the contact invitation, then the contact may be authenticated, or invited to provide authentication details, for accessing the contact's network system account via the respective network system API and a contact record is created by network access control server at 475, before connecting the newly- created contact record and delegate records at 465 and proceeding to 480.

[127] The present invention has been described here by way of example only, while numerous specific details are set forth herein in order to provide a thorough understanding of the exemplary embodiments described herein. However, it will be understood by those of ordinary skill in the art that these embodiments may, in some cases, be practiced without these specific details. In other instances, well-known methods, procedures and components have not been described in detail so as not to obscure the description of the embodiments. Various modification and variations may be made to these exemplary embodiments without departing from the spirit and scope of the invention, which is limited only by the appended claims.

Claims

We claim:

1. A network access control method for providing and managing access to an inbound message by a delegate user, the method comprising:

receiving, at a server, an inbound message from a first network system server, the inbound message received via a first application programming interface associated with the first network system server;

processing the inbound message to determine the delegate user to which the inbound message is to be delivered and identifying one or more user accounts associated with the delegate user;

determining one or more rules set by a primary user of the user account and, based on the one or more rules, processing the inbound message to determine whether it is to be delivered to the delegate user.

2. The network access control method of claim 1 , further comprising receiving, at the server, a second inbound message from a second network system server, the second inbound message received via a second application programming interface associated with the second network system server.

3. The network access control method of claim 1 or claim 2, further comprising, prior to receiving the inbound message, a user device transmitting the message to the first network system server.

4. The network access control method of any one of claims 1 to 3, wherein the inbound message comprises a recipient identifier.

5. The network access control method of claim 4, wherein the recipient identifier is an identifier used by the first network system to identify the user.

6. The network access control method of any one of claims 1 to 5, wherein the inbound message comprises a delegate indication, the method further comprising the server determining whether the delegate indication is previously associated with the user account.

7. The network access control method of claim 6, further comprising, the network access control server, prior to receiving the inbound message, associating the delegate indication with the user account.

8. The network access control method of any one of claims 1 to 7, further comprising, prior to receiving the inbound message, receiving one or more rules associated with the delegate user and associating the one or more rules with the user account.

9. The network access control method of claim 8, wherein the rules comprise at least one of a network identifier rule, a message type rule, a message direction rule, message frequency rule, a keyword rule, a time rule, a date rule, and a location rule.

10. The network access control method of claim 8, further comprising determining, based on the one or more rules, that the inbound message can be transmitted to a delegate user device.

1 1. The network access control method of claim 8, further comprising determining, based on the one or more rules, that the inbound message is not to be relayed to a delegate user device.

12. The network access control method of claim 11 , further comprising transmitting a block notification to a primary user device.

13. The network access control method of claim 8, further comprising determining, based on the one or more rules, that the inbound message is to be held for further processing.

14. The network access control method of claim 8 or claim 13, further comprising transmitting the inbound message to a primary user device for review.

15. The network access control method of claim 8 or claim 13, further comprising transmitting a notification of the inbound message to a primary user device for review.

16. The network access control method of claim 14 or claim 15, further comprising receiving an approved authorization from the primary user device and, based on the approved authorization, permitting transmission of the inbound message to the delegate user device.

17. The network access control method of claim 16, further comprising transmitting the inbound message to a delegate user device based on the approved authorization.

18. The network access control method of claim 14 or claim 15, further comprising receiving a declined authorization from the primary user device and, based on the declined authorization, preventing relaying of the message to the delegate user.

19. A network access control method for providing and managing access to an outbound message by a delegate user, the method comprising:

receiving, at a server, an outbound message from a delegate user device, the outbound message comprising a recipient identifier;

processing the outbound message to determine a first network system server to which the message is to be delivered;

transmitting the processed outbound message to the first network system server via a first application programming interface associated with the first network system server.

20. The network access control method of claim 19, wherein the outbound message comprises a recipient identifier, the method further comprising the server determining the user account with which the delegate user device is associated.

21. The network access control method of claim 20, wherein the recipient identifier is an identifier used by the first network system to identify the user.

22. The network access control method of any one of claims 19 to 21 , wherein the outbound message comprises a delegate indication, further comprising the server determining whether the delegate indication is previously associated with the user account.

23. The network access control method of claim 22, further comprising, the network access control server, prior to receiving the outbound message, associating the delegate indication with the user account.

24. The network access control method of any one of claims 19 to 23, further comprising evaluating the outbound message based on one or more rules.

25. The network access control method of claim 24, further comprising, prior to receiving the outbound message, wherein the one or more rules comprise one or more rules associated with the delegate user, and associating the one or more rules with the user account.

26. The network access control method of claim 24 or claim 25, wherein the rules comprise at least one of a network identifier rule, a network user identifier rule, a message type rule, a message direction rule, a message frequency rule, a keyword rule, a time rule, a date rule, and a location rule.

27. The network access control method of any one of claims 24 to 26, further comprising determining, based on the one or more rules, that the outbound message can be transmitted by the delegate user device.

28. The network access control method of any one of claims 24 to 26, further comprising determining, based on the one or more rules, preventing relaying of the inbound message to a delegate user device.

29. The network access control method of any one of claims 24 to 26, further comprising determining, based on the one or more rules, that the outbound message is to be held for further processing.

30. The network access control method of any one of claims 24 to 26 or claim 29, further comprising transmitting the outbound message to a primary user device for review.

31. The network access control method of any one of claims 24 to 26 or claim 29, further comprising transmitting a notification of the outbound message to a primary user device.

32. The network access control method of any one of claims 29 to 31 , further comprising receiving an approved authorization from the primary user device and, based on the approved authorization, permitting relaying of the outbound message to a first network system server.

33. The network access control method of claim 32, further comprising transmitting the outbound message to the first network system server based on the approved authorization.

34. The network access control method of any one of claims 29 to 31 , further comprising receiving a declined authorization from the primary user device and, based on the declined authorization, preventing transmission of the outbound message.

35. A network access control system for providing access to a user account by a delegate user, the system comprising:

a network interface;

a memory unit; and

a processing unit coupled to the memory unit and the network interface, the processing unit being configured to carry out the method of any one of claims 1 to 34.

36. A non-transitory computer readable medium storing computer executable instructions, the instructions when executed by a computer process for causing the computer process to carry out the method of any one of claims 1 to 34.