Prohibited Content Propagation using a Social Network Data Structure

Abstract

A method for prohibiting email content propagation that receives, at a server, an email message. At the server, at least one email address associated with the email message which is designated not to receive a content of the email message is identified. At the server, the email message is modified by selectively removing a content of the email message to be conveyed to the at least one email address. The server conveys the modified email message to the at least one email address. The server conveys the email message to one or more recipient email addresses except the at least one email address. Consequently, the server has sent a submitted message to multiple email addresses, while modifying the content sent to a subset of the addresses that received the email message.

Description

BACKGROUND

The present invention relates to the field of email distribution and, more particularly, to controlling email propagation within a social network utilizing proximity restrictions.

Electronic mail (email) has become an integral part of communications for many industries and enterprises. As such, email content protection is often the center of much concern within organizations. One aspect of content protection that continues to plague email users is control over which parties can receive an email once it is sent by a sender. For example, a recipient of an email can forward the email to any party which they choose. That is, the sender loses control over the email once it is communicated to recipients. As such, this can be a compromise of email conveyed content and/or security for companies and individuals. For example, an employee can accidentally forward a sensitive company email to a family member. Further, many integrity issues for individuals have arisen as a result of this -problem.

These problems are further compounded when emails are communicated within a social network. In a social network, each member of the social network can be potentially connected to many other members. Currently, email solutions do not consider relationships between a sender and a recipient when conveying an email to a recipient. In many instances, email is intended for a select group of individuals which are often the recipients within the email sender's social network. Frequently, individuals outside the sender's social network are not aware of secure communication occurring within the social network. For instance, when a party not within the same social network receives an email, information within the email can often pose potential security problems for the sender and individuals within the social network. As such, it would be beneficial if email distribution can be controlled within a social network after it is sent.

BRIEF SUMMARY

One aspect of the disclosure discloses a system, method, and computer program product that receives, at a server, an email message. At the server, at least one email address associated with the email message which is designated not to receive a content of the email message is identified. At the server, the email message is modified by selectively removing a content of the email message to be conveyed to the at least one email address. The server conveys the modified email message to the at least one email address. The server conveys the email message to one or more recipient email addresses except the at least one email address. Consequently, the server has sent a submitted message to multiple email addresses, while modifying the content sent to a subset of the addresses that received the email message.

Another aspect of the disclosure is for a method, computer program product, and system for controlling email propagation within a social network utilizing proximity restrictions. A message header of an email message can be identified. The message header can comprise of an exemption field which specifies one or more email addresses that is prohibited from receiving the email message. The sending email address can be associated with a sender node and the one or more email addresses is associated with a prohibited node, The sender node and the prohibited node can be arbitrarily linked within a network that is a social structure comprising of one or more individuals and organizations which can be connected by one or more specific type of interdependency. The network can be modeled as a graph which can be a mathematical structure modeling pairwise relations between nodes and edges. The email message can be conveyed to multiple email addresses except the one or more email address associated with the exemption field.

Another aspect of the disclosure is for a system, method, and computer program product for prohibiting email propagation based on proximity comprising of a processor, a volatile memory, a bus connecting said processor, non-volatile memory, and volatile memory to each other, wherein the volatile memory comprises computer usable program code execute-able by the processor. The computer usable program code can comprise of an email message. The email message can include a message header including an exemption field which is associated with one or more email addresses prohibited from receiving the email message. The one or more email addresses can be associated with a prohibited node which can be a component of a network. The network can be modeled as a graph which can be a mathematical structure modeling pairwise relations between nodes and edges, A proximity engine can be configured to determine a distance metric between a sender node and a recipient node of a network, compare the distance metric to a threshold value, and perform a programmatic action in response to the comparing. A notification engine can convey a notification to a sender node and another node responsive to a communication action performed on the email message, where the communication action violates a policy setting associated with a policy. A policy can be configured to identify one or more nodes prohibited from receiving the email message and one prohibited communication action associated with the one or more nodes based on the proximity from the sender node.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

FIG. 1 is a flowchart illustrating a method for controlling email propagation within a social network utilizing proximity restrictions in accordance with an embodiment of inventive arrangements disclosed herein.

FIG. 2 is a flowchart illustrating a method for controlling email propagation within a social network utilizing server-based proximity restrictions in accordance with an embodiment of inventive arrangements disclosed herein.

FIG. 3 is a schematic diagram illustrating a system for prohibiting email propagation within a social network based on proximity restrictions in accordance with an embodiment of inventive arrangements disclosed herein.

FIG. 4 is a schematic diagram illustrating an email header for prohibiting email propagation within a social network based on proximity restrictions in accordance with an embodiment of inventive arrangements disclosed herein.

FIG. 5 is a schematic diagram illustrating an interface 305 for prohibiting email propagation within a social network based on proximity restrictions in accordance with an embodiment of inventive arrangements disclosed herein.

DETAILED DESCRIPTION

The present disclosure is a solution for controlling email propagation within a social network utilizing proximity restrictions. n the solution, a proximity policy can be associated with an email message enabling the email to remain under the control of the sender after it is conveyed. The proximity policy can specify the nodes (e.g., members) within a social network that the email message is allowed to be communicated. For instance, a user can prohibit an email message from being forwarded to someone outside their immediate social network (e.g., one degree of separation). Further, the proximity policy can be utilized to notify a sender if the policy was violated, enabling the sender to maintain control and awareness of the email after it is sent.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will he further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

The corresponding structures, materials, acts, and equivalents of all means or step plus function elements in the claims below are intended to include any structure, material, or act for performing the function in combination with other claimed elements as specifically claimed. The description of the present invention has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the invention in the faun disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the invention. The embodiment was chosen and described in order to best explain the principles of the invention and the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.

As will be appreciated by one skilled in the art, the present invention may be embodied as a system, method or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.” Furthermore, the present invention may take the form of a computer program product embodied in any tangible medium of expression having computer usable program code embodied in the medium,

Any combination of one or more computer usable or computer readable medium(s) may be utilized. The computer-usable or computer-readable medium may be, for example but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, device, or propagation medium. More specific examples (a non-exhaustive list) of the computer-readable medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CDROM), an optical storage device, a transmission media such as those supporting the Internet or an intranet, or a magnetic storage device. Note that the computer-usable or computer-readable medium could even be paper or another suitable medium upon which the program is printed, as the program can be electronically captured, for instance, via optical scanning of the paper or other medium, then compiled, interpreted, or otherwise processed in a suitable manner, if necessary, and then stored in a computer memory, in the context of this document, a computer-usable or computer-readable medium may be any medium that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. The computer-usable medium may include a propagated data signal with the computer-usable program code embodied therewith, either in baseband or as part of a carrier wave. The computer usable program code may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc.

Computer program code for carrying out operations of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the “C” programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).

The present invention is described below with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable medium that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable medium produce an article of manufacture including instruction means which implement the function/act specified in the flowchart and/or block diagram block or blocks.

The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

FIG. 1 is a flowchart illustrating a method 100 for controlling email propagation within a social network utilizing proximity restrictions in accordance with an embodiment of inventive arrangements disclosed herein. In method 100, an email within a social network can be identified which can be selectively conveyed to recipients based on the proximity, Proximity can include, but is not limited to, betweenness, centrality, closeness, cohesion, degree, density, eigenvector centrality, path length, and the like. For example, an email can be limited to only three degrees of separation within a social network. That is, recipients greater than three degrees away from a sender of an email can be prohibited from receiving the email.

In step 105, an email within a social network can be identified, Identification of the email can be automatically performed and/or manually performed. In step 110, a proximity policy associated with the email can be determined. The proximity policy can be determined utilizing one or more mechanisms including manual identification and automated identification processes. In one embodiment, header control information can be used to indicate a proximity policy associated with the email. For instance, the header control information can include a “Not To” field which can indicate the location of one or more appropriate proximity policy. In one instance, tags associated with an email can be utilized to programmatically identify one or more appropriate policies.

In step 115, a recipient of the email is selected. The recipient can be selected from one or more fields including, but not limited to, the “to” field, the “cc” field, the “bcc” field, and the like. That is, the recipient email address can be identified through analysis of the header control information within the email. The email address can be used to identify a recipient within the social network. In one embodiment, the email address can be used to determine uniquely identifiable information (e.g., user id) of a recipient to establish the recipient position within a social network. In step 120, the recipient centrality within the network is determined. The centrality can be determined utilizing one or more client-side and/or server-side functionality. Centrality can be determined using a brute-force algorithm, path deteiiuination algorithms, and the like. In step 125, the recipient centrality is compared with a centrality value associated with the proximity profile. Comparison can include, direct comparison of centrality values, threshold value approximation, and the like. For instance, if the centrality value of the recipient is less than the centrality value of the proximity profile, the email can be permitted to be communicated to the recipient.

In step 130, if the recipient is prohibited from receiving the email based on the comparing step, the method can continue to step 135, else proceed to step 155. In step 135, the recipient can be omitted. In one instance, the recipient can be removed from the email prior to communication of the email. For instance, the email address of the recipient can be removed from the email header. In step 140, the sender of the email can be optionally notified of recipient omission. In step 145, the sender can optionally perform a responsive action to the recipient omission. In step 150, if there are more recipients associated with the email, the method can proceed to step 115, else proceed to step 160. In step 155, the email can be conveyed to appropriate recipients who do not violate the proximity policy associated with the email. In step 160, the method can end.

Drawings presented herein are for illustrative purposes only and should not be construed to :limit the invention in any regard. Social network can refer to a social structure comprising of individuals and/or organizations (e.g., nodes), which are connected by one or more specific types of interdependency, including, but not limited to, friendship, kinship, common interest, financial exchange, likes, dislikes, relationships of beliefs, knowledge, prestige, and the like. In one embodiment, the social network can be represented within a computing network as a graph, wherein the graph is a mathematical structure modeling pairwise relations between nodes (e.g., members) and edges (interdependency). Social network can include internal social network, external social network, and the like. For instance, social network can be a network of employees within a corporation. Social network can include, but is not limited to, LINKEDIN, FACEBOOK, MYSPACE, ORKUT, FRIENDSTER, TWITTER, and the like. It should be appreciated, method 100 can be performed in real-time or near real-time.

FIG. 2 is a flowchart illustrating a method 200 for controlling email propagation within a social network utilizing server-based proximity restrictions in accordance with an embodiment of inventive arrangements disclosed herein. Method 200 presents one scenario for managing email distribution via proximity policies. In method 200, an email from a sender node (e.g., member) within a social network can retain control of the email distribution once the email has been communicated to recipient nodes (e.g., connected members). That is, a member of social network can restrict which members within the social network can participate in an email dialogue. As such, the proximity policy can govern an email exposure throughout the lifespan of the email. The email can be associated with a proximity policy which can enable a sender node to control which recipient nodes within the social network can receive the email. For instance, Alice can assign a proximity policy to her email to Bob, who can be prohibited from forwarding the email to anyone outside Alice's social network. The proximity policy can be user-defined or automatically established based on historic data, organizational policy and/or email distribution configuration settings.

In step 205, an email can be received by an email server from a sender node within a social network. In step 210, a proximity policy associated with the email can be identified. In step 215, prohibited nodes within the network which are disallowed from receiving the email can be determined based on the proximity policy. In one embodiment, the proximity policy can define which nodes (e.g., prohibited nodes) and/or group of nodes (e.g., prohibited social networks) can be blacklisted from receiving the email. In another embodiment, the proximity policy can establish centrality values for limiting email exposure. For instance, the policy can permit an email to be delivered to anyone not close to the sales department. In step 220, the email can be conveyed to recipient nodes within the network according to the proximity policy. That is, the email can be conveyed to recipient nodes and prohibited nodes can remain unaware of the email.

In step 225, if a communication action is performed by a recipient node on the email which violates the proximity policy, the method can continue to step 230, else return to step 210. The communication action can include, but is not limited to, forwarding, reply to all, sending, and the like. For example, if Bob attempts to send a carbon copy of Alice's email to Fred, who is outside of Alice's social network, a proximity policy violation can be triggered. In step 230, the communication action can be disallowed, In one instance, the communication action can be logged within an auditing system. In step 235, a notification policy violation can be presented to the recipient node performing the communication action. The notification can be presented within a user interface such as an email application. For instance, a graphical user interface can present a dialog indicating that the communication action associated with a prohibited node is prohibited.

In step 240, a policy violation notification can be communicated to the sender node. In one instance, the policy violation notification can be communicated comprising of information including, but not limited to, timestamp associated the communication action, the prohibited node associated with the attempt, the communication action performed by the node, and the like. In step 245, the sender node can optionally perform a responsive action to the policy violation. In one instance, the responsive action can be initiating contact with the recipient node which violated the proximity policy. In step 250, the method can end,

Drawings presented herein are for illustrative purposes only and should not be construed to limit the invention in any regard, Method 200 can be performed within the context of system 300. Steps 205-245 can repeat for each instance of an email that is communicated throughout a social network.

FIG. 3 is a schematic diagram illustrating a system 300 for prohibiting email propagation within a social network based on proximity restrictions in accordance with an embodiment of inventive arrangements disclosed herein. System 300 can be present within the context of method 100 and 200. In system 300, proximity policy 336 can permit distribution control of email 318, 331 to one or more clients 310 based on proximity settings associated with the proximity policy 336. Email 318, 331 can be communicated to email server 330 which can be utilized to propagate email based on proximity policy 336. Turning to FIG. 4, in one embodiment 474, proximity policy 336 can be stored within server 330 which can be indicated using a Uniform Resource Locator (URI) 486 associated with header information 482. For instance, URL 486 can identify policy 354 associated with email 352. In another instance 472 proximity policy 336 can be stored within header information 480 of the email message as one or more email addresses 482.

Email 318, 331 can be a message associated with the Simple Mail Transfer Protocol (SMTP), Post Office Protocol (POP), Internet Message Access Protocol (IMAP), Hypertext Transport Protocol (HTTP), and the like. Email 318, 331 can be stored within a data store including but not limited to, hard drive, network attached storage (NAS), storage attached network (SAN), and the like. In one instance, email 318, 331 can be stored within an mbox file format. Email 318, 331 can be a user and/or automatically generated message comprising of a message header and a message body. In one embodiment, the message header can be associated with exemption field 314 which can be used to prohibit one or more nodes within network 342 from receiving email 318, 331. Message header can include control information including, but not limited to, one or more prohibited address (e.g., 482), an originator's email address, one or more recipient addresses, subject information, message id, and the like. Email body can include plain text and/or Hypertext Markup Language (HTML) content. Email 318, 331 can include multi-media content attachments (e.g., multipurpose internet mail extension s).

As used herein, client 310 can be a computing device able to send and receive email 331. Client 310 can be mapped to a node within a social network 342 (e.g., network 370) such that client 310 can be a sender node, recipient node, or a prohibited node. Client 310 can include, but is not limited to, desktop computer, laptop, mobile phone, portable digital assistant, multimedia device, and the like. Client 310 can be communicatively linked to email server 330 via network 370. In one instance, client 310 can be associated with an interface 312.

Interface 312 can be a user interface able to permit composition and/or presentation of email 331 (e.g., mail user agent). Interface 312 can be a screen from a client-side email application such as an email client. Interface 312 can be a component of MOZILLA THUNDERBIRD, MUTT, and the like. In one instance, interface 312 can be component of a Web-based email application. In another instance, interface 312 can be a remotely executing application. Interface 312 can comprise of exemption field 314 which can permit distribution control of emails (e.g., email 318) sent from interface 312.

Exemption field 314 can be associated with proximity policy 336 which can be used to specify which clients 310 (e.g., nodes) within social network 342 can receive email 318. In one embodiment, exemption field 314 can present one or more existing proximity policies which can be applied to email 318. In another instance exemption field 314 can permit a user to create policies to be applied to email 318.

Email server 330 can be one or more hardware/software components able to prohibit communication of an email 318, 331 to a prohibited node. Email server 330 can be a mail submission agent, mail transfer agent, mail delivery agent, mail exchange, and the like. For example, email server can be a software email server application such as POSTFIX. Email server 330 can comprise of, but is not limited to, email 331, proximity engine 332, notification engine 334, proximity policy 336, configuration settings 338, and data store 340. Email server 330 can be associated with one or more entities including, but not limited to, an Internet service provider (ISP), a corporation, and the like. In one instance, email server 330 can be an IBM LOTUS DOMINO server. In another instance, email server 330 can be an SENDMAIL SMTP server

Proximity engine 332 can be one or more hardware/software components for determining the proximity of two or more nodes within a social network 342. Engine 332 can establish proximity metrics including, but not limited to, betweenness, centrality, closeness, cohesion, degree, density, eigenvector centrality, path length, and the like. Proximity metrics established by the engine can be used to generate proximity policies, validate proximity policies, and/or resolve proximity conflicts. Proximity engine 332 can utilize network 342 data to determine proximity between nodes. For instance, relationship data 350 can be used to determine Alice is connected to Joe and Fred through a marketing department relationship. In one embodiment, proximity engine 332 can respond to real-time changes within a social network. For instance, if Fred joins Alice's social network, Fred can participate in an email which was previously prohibited to Fred. In one configuration of the embodiment, engine 332 can retroactively apply proximity policy 336 when a change in a social network occurs.

In one embodiment, proximity engine 332 can use presence information to prohibit communication of an email to a recipient. In the embodiment, location information (e.g., global positioning system data) of a node (e.g., user) can be used to dynamically restrict email messages from being conveyed to the node.

Notification engine 334 can be one or more hardware/software components able to generate a notification 360 responsive to a proximity policy violation. Engine 334 can convey notification 360 when proximity policy 336 is violated by a node (e.g., client 310). In one embodiment, engine 334 can store policy violations which can be accessed during auditing processes. In one instance, notification engine 334 can operate in real-time to generate policy violation warnings to users of interface 312.

Notification 360 can be a message identifying one or more proximity policy violations associated with an email 318, 331. Notification 360 can be an email, Short Message Service (SMS) message, voice message, instant message (IM) and the like. Notification 360 can be customized via proximity profile 336 and/or configuration settings 338. For instance, notification 360 can generate an email notification to all participants of an email conversation when the proximity policy of the email is violated.

Proximity policy 336 can be one or more rulesets for establishing prohibited nodes within a social network 342 which are disallowed from receiving email 318, 331. Proximity policy 336 can be applied arbitrarily to any portion of a social network. For instance, policy 336 can be applied to subgroups (e.g., cliques) within a social network. In one embodiment, proximity policy 336 can be associated with metrics for limiting email communication. For example, a forwarding threshold value can be utilized to restrict the number of times an email can be forwarded. In one embodiment, policy 336 can be associated with an expiration value which can enable the policy 336 to be enforced for a set period of time. For example, a policy can restrict emails from being forwarded outside of a development team's social network prior to a product release date. Further, proximity policy 336 can be associated with administrative settings permitting authorized parties to view and/or modify policy 336.

In one instance, proximity policy 336 can be used to selectively expose content of an email based on the proximity of a recipient node from a sender node. In one configuration of the instance, attachments can be selectively removed based on policy settings. For example, when the email 331 is delivered to a recipient outside of a sender's social network, image attachments associated with the email 331 can be removed. In another configuration of the instance, portions of the message body of the email 331 can be omitted when the email 331 is communicated to selected recipients.

Configuration settings 338 can be one or more local and/or global email settings for enabling system 300 functionality. Configuration settings 338 can include, but are not limited to, permitted proximity values, administrative settings, and the like. In one instance, settings 338 can allow customize proximity values to be used. For instance, settings 338 can allow physical proximity values to be used to control email propagation. In another instance, settings 338 can permit organizational proximity policies to override individual defined proximity policies.

Social network 342 can be one or more social structures associated with system 300. Social network 342 information can be stored within data store 340. In one instance social network 342 can be associated with a directory service. For instance, social network 342 can be associated with an IBM TIVOLI DIRECTORY SERVER. In the instance, network 342 information can be queried to determine proximity information for establishing node proximity.

In one instance, data store 340 can be a relational database including, but not limited to, relational database management system (RDBMS), object database management system (©DBMS), and the like. In another instance, data store 340 can be a NAS, SAN, and the like.

Drawings presented herein are for illustrative purposes only and should not be construed to limit the invention in any regard. System 300 functionality can be encapsulated within a middleware software including, but not limited to, IBM WEBSPHERE. System 300 can be one or more components of a distributed computing system, network computing system, and the like. In one instance, system 300 functionality can be accessible through a Web-based service. In one embodiment, components 332-338 can be integrated with a client-side email application. Email 318, 331 can be stored within client 310 and/or within server 330. In one embodiment, system 300 functionality can be a component of a client-side email application.

FIG. 5 is a schematic diagram illustrating an interface 505 for prohibiting email propagation within a social network based on proximity restrictions in accordance with an embodiment of inventive arrangements disclosed herein. In interface 505, a user can specify one or more nodes (e.g., members) of a social network which can be prohibited from receiving an email based on a distance metric setting associated with the email 510. Prohibited nodes can be user specified or automatically determined as shown in section 510 and suggestion 522. Interface 505 can be one or more screens of an email application. In one instance, the application can be a client-side application permitting selective control of email distribution within a social network. For example, interface 505 can be a screen from an IBM LOTUS NOTES application.

In section 510, a user can utilize an exemption field 512 and/or a slider element 514 to specify prohibited nodes within a social network. Section 510 can be used to establish a proximity policy for an email associated with the interface 505. For instance, a user can establish a proximity policy for an email by utilizing field 512 and/or element 514. In one instance, exemption field 512 and slider element 514 can be linked. In one configuration of the embodiment, manipulation of the slider element 514 can automatically populate field 512. In another configuration of the embodiment, exemption field 512 can be used to set which nodes can be prohibited while slider element 514 can be used to specify additional prohibited nodes based on a distance from a sender node. In one embodiment, field 512 and element 514 can be used in an mutually exclusive fashion.

Exemption field 512 can be a user interface element permitting user established control of an email via user input. Exemption field 512 can be a text field used for identifying prohibited nodes within the social network. Field 512 can accept a variety of user input including, canonical names, usernames, email addresses, keywords, relationship information and the like.

Slider element 514 can be utilized to specify a distance metric from a sender node to which the email cannot be delivered. Element 514 can include a range from one degree of separation (e.g., friend of a friend) to six degrees of separation (e.g., everyone in the social network). In one instance, element 514 can be automatically positioned based on input within exemption field 512. Element 514 can be used to specify a maximum and/or minimum distance that the email can be propagated. In another instance, the slider can be used to specify the “levels” of forwarding or “reply to all” which are allowed.

In one embodiment, prohibited nodes can be automatically determined based on content of an email within interface 505. Based on a previously established proximity policy, text 520 can trigger pop-up 522 to be presented. Pop-up 522 can present a user with an option to automatically prohibit appropriate nodes from receiving the email based on the text 520. For example, when text 520 comprises of the keyword “Widget A”, John Soft can be automatically identified as a candidate who cannot receive the email. In one instance, pop-up 522 can be used to automatically add a prohibited node to exemption field. 512. For instance, when a user selects “Yes”, the pop-up 522 can trigger John Soft to be programmatically removed from the “To” field and placed within the “Not To” field 512.

Drawings presented herein are for illustrative purposes only and should not be construed to limit the invention in any regard. Interface 505 can be a component of a graphical user interface (GUI), voice user interface (VUI), mixed-mode interface, and the like. Interface elements within interface 505 can include, but are not limited to, text field, sliders, drop down boxes, radio buttons, checkboxes, and the like. In one instance, section 510 can graphically present a list of each node associated with a sender node which can be excluded. In the instance, each node can be associated with a checkbox for selecting the node to exclude. For instance, a checkbox can be presented next to a profile picture of a member within a social network that can be disallowed from receiving an email composed within interface 505.

The flowchart and block diagrams in the FIGS. 1-3 illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

Claims

1. (canceled)

2. A method comprising: receiving, at a server, from a first client device, a message comprising metadata indicating a proximity policy and a social network policy, the proximity policy specifying a location requirement to access the message, the social network policy specifying a social network connection degree threshold requirement of a social network data structure to access the message;receiving, at the server, from a second client device, a request to forward the message to a third client device; anddetermining, by the server, whether to forward the message to the third client device based at least in part on whether a user of the third client device satisfies the social network policy and whether a location of the third client device satisfies the proximity policy.

3. The method of claim 2, further comprising: conveying, by the server, the message to the third client device based at least in part on whether the user of the third client device satisfies the social network policy and whether the location of the third client device satisfies the proximity policy.

4. The method of claim 2, further comprising: determining that the user of the third client device satisfies the social network policy and that the location of the third client device satisfies the proximity policy; andin response to determining that the user of the third client device satisfies the social network policy and that the location of the third client device satisfies the proximity policy, conveying, by the server, the message to the third client device.

5. The method of claim 2, further comprising: identifying a first set of user nodes, from the social network data structure, that is allowed to access the message based on the first set of user nodes satisfying the social network connection degree threshold requirement relative to the first client device;determining that the second client device is part of the first set of user nodes; andin response to determining that the second client device is part of the first set of user nodes, sending the message to the second client device.

6. The method of claim 5, further comprising: identifying a second set of user nodes, from the social network data structure, that is allowed to access the message based on the first set of user nodes satisfying the location requirement relative to the first client device;determining that the third client device is part of the first set of user nodes and the second set of user nodes; andin response to determining that the third client device is part of the first set of user nodes and the second set of user nodes, forwarding the message to the third client device.

7. The method of claim 2, wherein determining whether to forward the message to the third client device comprises: determining whether the user of the third client device satisfies the social network connection degree threshold requirement relative to a user of the first client device and whether the location of the third client device satisfies the proximity policy relative to a location of the first client device.

8. The method of claim 2, wherein the proximity policy indicates a maximum number of times the message can be forwarded, wherein the method comprises:determining a number of times the message has been forwarded; anddetermining, by the server, whether to forward the message to the third client device based on determining that the number of times the message has been forwarded and the maximum number of times the message can be forwarded.

9. The method of claim 2, wherein the proximity policy or the social network policy comprises an expiration value that indicates a set period of time for enforcing the proximity policy or the social network policy.

10. The method of claim 2, further comprising: determining that the user of the third client device does not satisfy the social network policy or that the location of the third client device does not satisfy the proximity policy; andin response to determining that the user of the third client device does not satisfy the social network policy or that the location of the third client device does not satisfy the proximity policy, restricting the message from being forwarded to the third client device.

11. The method of claim 2, further comprising: determining that the user of the third client device does not satisfy the social network policy or that the location of the third client device does not satisfy the proximity policy; andin response to determining that the user of the third client device does not satisfy the social network policy or that the location of the third client device does not satisfy the proximity policy, redacting a portion of the message prior to forwarding the redacted message to the third client device.

12. A system comprising: one or more processors of a server; anda memory storing instructions that, when executed by the one or more processors, cause the server to perform operations comprising:receiving, at the server, from a first client device, a message comprising metadata indicating a proximity policy and a social network policy, the proximity policy specifying a location requirement to access the message, the social network policy specifying a social network connection degree threshold requirement of a social network data structure to access the message;receiving, at the server, from a second client device, a request to forward the message to a third client device; anddetermining, by the server, whether to forward the message to the third client device based at least in part on whether a user of the third client device satisfies the social network policy and whether a location of the third client device satisfies the proximity policy.

13. The system of claim 12, wherein the operations comprise: conveying, by the server, the message to the third client device based at least in part on whether the user of the third client device satisfies the social network policy and whether the location of the third client device satisfies the proximity policy.

14. The system of claim 12, wherein the operations comprise: determining that the user of the third client device satisfies the social network policy and that the location of the third client device satisfies the proximity policy; andin response to determining that the user of the third client device satisfies the social network policy and that the location of the third client device satisfies the proximity policy, conveying, by the server, the message to the third client device.

15. The system of claim 12, wherein the operations comprise: identifying a first set of user nodes, from the social network data structure, that is allowed to access the message based on the first set of user nodes satisfying the social network connection degree threshold requirement relative to the first client device;determining that the second client device is part of the first set of user nodes; andin response to determining that the second client device is part of the first set of user nodes, sending the message to the second client device.

16. The system of claim 15, wherein the operations comprise: identifying a second set of user nodes, from the social network data structure, that is allowed to access the message based on the first set of user nodes satisfying the location requirement relative to the first client device;determining that the third client device is part of the first set of user nodes and the second set of user nodes; andin response to determining that the third client device is part of the first set of user nodes and the second set of user nodes, forwarding the message to the third client device.

17. The system of claim 12, wherein determining whether to forward the message to the third client device comprises: determining whether the user of the third client device satisfies the social network connection degree threshold requirement relative to a user of the first client device and whether the location of the third client device satisfies the proximity policy relative to a location of the first client device.

18. The system of claim 12, wherein the proximity policy indicates a maximum number of times the message can be forwarded, wherein the operations comprise:determining a number of times the message has been forwarded; anddetermining, by the server, whether to forward the message to the third client device based on determining that the number of times the message has been forwarded and the maximum number of times the message can be forwarded.

19. The system of claim 12, wherein the proximity policy or the social network policy comprises an expiration value that indicates a set period of time for enforcing the proximity policy or the social network policy.

20. The system of claim 12, wherein the operations comprise: determining that the user of the third client device does not satisfy the social network policy or that the location of the third client device does not satisfy the proximity policy; andin response to determining that the user of the third client device does not satisfy the social network policy or that the location of the third client device does not satisfy the proximity policy, restricting the message from being forwarded to the third client device or redacting a portion of the message prior to forwarding the redacted message to the third client device.

21. A non-transitory machine-readable storage device embodying instructions that, when executed by a server, cause the server to perform operations comprising: receiving, at the server, from a first client device, a message comprising metadata indicating a proximity policy and a social network policy, the proximity policy specifying a location requirement to access the message, the social network policy specifying a social network connection degree threshold requirement of a social network data structure to access the message;receiving, at the server, from a second client device, a request to forward the message to a third client device; anddetermining, by the server, whether to forward the message to the third client device based at least in part on whether a user of the third client device satisfies the social network policy and whether a location of the third client device satisfies the proximity policy.