SECRET INTEREST GROUPS IN ONLINE SOCIAL NETWORKS

FIELD OF THE INVENTION

The invention relates to creation of secret interest groups in online social networks. More precisely, the invention relates to creation of a secret interest group framework with cryptographic algorithms and protocols.

BACKGROUND OF THE INVENTION

Online Social Networks (OSNs) are becoming one of the most prominent communication technologies. Platforms such as Facebook now count millions of users that share information every day.

A problem, which is particularly felt among OSNs, is identity theft and identity spoofing. The root of the problem lies in the fact that in OSNs there is little or no verification of whether a person that joins the social network is really who he or she claims to be. Furthermore, social network users base their decision on whether to accept a friendship request on name, pictures, and fragments of text, which is information that is often easily retrievable from elsewhere on the internet. It is therefore relatively simple for an impostor to set up a profile on an OSN, pretending to be somebody else, and then to convince other users to accept friendship requests, and consequently to share their private information with the impostor.

SUMMARY OF THE INVENTION

Various embodiments of computer implemented methods and systems for secret interest groups in social networks are described herein. In some embodiments, the method includes receiving a friendship request from a first OSN user to a second OSN user and capturing the friendship request by a proxy server. The method also includes extracting cryptographic information of the first and the second user by the proxy server to be used for computation of a cryptographic handshake to verify the membership of the first and the second user to a same secret interest group (SIG). Then, the method continues with creating a modified request from the friendship request by the proxy server through notifying the second user that the first user is a member of the same SIG as the second user when the cryptographic handshake is accomplished and forwarding the modified request to an OSN server. The method further includes receiving a response to the modified request from the second user via the OSN server and sending a message to the first user affirming the co-membership of the second user when the second user has accepted the modified request.

In another embodiment of the invention, the system includes one or more OSN servers within an OSN and at least two OSN users communicating via the OSN. The system also includes a proxy server in communication with the one or more OSN servers, the proxy server having a processor to execute instructions for modifying a friendship request between the at least two OSN users by computing a cryptographic handshake to verify the membership of the at least two OSN users to the same secret interest group (SIG).

These and other benefits and features of embodiments of the invention will be apparent upon consideration of the following detailed description of preferred embodiments thereof, presented in connection with the following drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

The claims set forth the embodiments of the invention with particularity. The invention is illustrated by way of example and not by way of limitation in the figures of the accompanying drawings in which like references indicate similar elements. The embodiments of the invention, together with its advantages, may be best understood from the following detailed description taken in conjunction with the accompanying drawings.

FIG. 1A is a block diagram with an exemplary illustration of the structure and the entities of an Online Social Network (OSN).

FIG. 1B is a block diagram with an exemplary illustration of the structure and the entities of an OSN and a Secret Interest Group (SIG) using the OSN potentialities.

FIG. 2 is a flow diagram describing a method for verification of personalities in OSNs.

FIG. 3 illustrates the operation of a proxy upon a friendship request in an exemplary OSN.

FIG. 4 illustrates the operation of a proxy upon a friendship response in an exemplary OSN.

FIG. 5 is a block diagram with an exemplary illustration of a system for creating SIGs in OSNs.

FIG. 6 is a block diagram of an embodiment of the invention for creating SIGs in OSNs.

DETAILED DESCRIPTION

Embodiments of techniques for secret interest groups in online social networks are described herein. In the following description, numerous specific details are set forth to provide a thorough understanding of embodiments of the invention. One skilled in the relevant art will recognize however, that the invention can be practiced without one or more of the specific details, or with other methods, components, materials, etc. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the invention.

Reference throughout this specification to “one embodiment”, “this embodiment” and similar phrases, means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, the appearances of these phrases in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

Typically users communicate through Online Social Networks (OSNs) to exchange information, photos, meet people and the like. FIG. 1A represents the structure and the entities in such an environment. Users 110 are the actual beneficiaries of the capabilities of an OSN 130. An OSN provider 120 hosts the network. Communication between at least two of the users 110 starts after sending a friendship request, accompanied by identifying information, also provided by the requester. The true identities of the users 110 are not verified so a number of intruders 140 with fake profiles are inevitably part of the OSN 130. The intruders 140 set up profiles in the OSN 130 pretending to be somebody else and thus may be able to convince some of the users 110 to accept friendship requests. Then the users 110 are prone to share their private information with the intruders 140. To improve the security of the process of sending friendship requests in OSN 130, users 110 may be asked to provide credentials along with the friendship request. Such credentials cannot be self generated, but rather generated and maintained after verification by a third party. It is unrealistic to expect a central entity like the OSN provider 120 to handle the credentials for free, but at the same time the users 110 are not likely to pay for such service.

One other solution could be that users 110 create a Secret Interest Group (SIG) 150 outside of the OSN 130, as presented in FIG. 1B, issue group membership credentials and present such credentials upon sending friendship requests within the OSN 130. Thus SIG 150, which is a user created group, could be created to discuss confidential or privacy sensitive topics. In one aspect, members of SIG 150 are able to handle joining and leaving of members and to grant or revoke administration privilege to members. In another aspect SIG members may grant credentials to secure the relationship with other members of the SIG 150 in the OSN 130.

In some embodiments, the implementation of the SIG 150 in an OSN 130 is performed by algorithms that deal with authentication, handshaking, and encryption of content among users 110 of the OSN 130. The OSN 130 is used as a transport layer for cryptographic messages. In some embodiments, the SIG 150 is not maintained or administered by a central entity but rather any entitled user may be able to act as a central entity and also the algorithms may be subject to a threshold (thresholdized) in the sense that to be performed successfully, they need the cooperation of a minimum number of entitled users. Thus, the role of the central entity is split and spread among entitled users. For example, the creation of a new SIG 150 is the task of an initial set of SIG managers that create the SIG and handle the joining of the first SIG members. The initial set of SIG managers may reserve the ability of handling the joining of other members to themselves only, or may endorse other members with this capability as well. The difference between SIG managers and SIG members is that the SIG managers are not only SIG members but they are also responsible for appointing new SIG managers and to allow new members to join the SIG. Hence, for joining a SIG, at any point in time the set of SIG managers must be non-empty; and only a set of SIG managers may appoint new SIG managers. To enhance the security of SIGs, one SIG manager alone may not able to perform the task of appointing new SIG managers and handling the joining of new members, instead, the procedures require a minimum number of SIG managers to be involved. In some embodiments, prior to being allowed to join the SIG, a potential member may undergo offline verification carried out by a SIG manager. The purpose of such verification is to ensure that all members are consistent with the SIG joining policy. This procedure is group specific and may require different controls depending on the nature of the SIG.

For example, in a SIG revolving around political militancy; party membership, background check, or face-to-face interview may be the check that a user is required to pass before being admitted in the group. For a SIG representing a project consortium, it may be sufficient to send the membership or managerial credentials using the consortium email address. SIG members and SIG managers receive membership credentials and managerial credentials to certify their roles. An additional requirement may be that no coalition of less than a set number of SIG members or SIG managers may be able to grant a new credential, either membership or managerial. The existence of credentials presumes that they may also be revoked. In some embodiments, proactive techniques may be used for revocation. Proactive techniques include use of time limits embedded in the credentials. This means the credential will expire after some time or after a number of usages. In other embodiments reactive techniques may be used for revocation of credentials by publishing a revocation handle to an authenticated public site. If a single SIG manager credential falls into an intruder's hands, it will not be a problem, because an intruder would need to get hold of at least the set minimum number of SIG managerial credentials. The loss of a SIG membership credential is somehow thornier than the loss of SIG managerial credentials since SIG membership credentials may be used directly to authenticate oneself to another SIG member or to access content of a SIG member. That is why for the SIG membership credentials, the reactive approach for revocation may be more suitable since such credentials can be revoked immediately after determination of abuse.

Another part concerns the operation of the credentials granted to SIG members inside an OSN during communication between SIG members. If a SIG member eventually wants to add another alleged SIG member to his list of friends through the standard OSN invitation process, or to exchange content or to chat in a secure way, mutual authentication of the two SIG members and encryption of the content for fellow SIG members may be performed by means of granted credentials. Since the SIGs are by definition secret or privacy sensitive, the invitation process is crucial because a legitimate member (the inviter, the invitee or both) does not yet know whom he is interacting with. In some embodiments, the authentication problem may be solved by secret handshakes. Secret handshakes are known as mechanisms designed to prove group membership between fellow group members. Also non-members may not be able to either impersonate group members or to recognize legitimate group members. Besides, the communications between group members may be designed so as to ensure untraceability of any two protocol exchanges. The purpose of these protocols is to model real handshakes between group members in cryptography. Upon handshake between two SIG members, due to the nature of SIGs, users may be reluctant to disclose their affiliation to the SIG even when interacting with another legitimate SIG member. In some embodiments, Oblivious Signature-Based Envelopes (OSBEs) are used to allow two users of an OSN, owning a credential to perform a secret handshake and share a key if they both own the signature of the same message under the same public key.

Let p and q be large prime numbers such that q divides p−1; g is a generator of the subgroup of order q of Z_p; and h is a one way hash function in the range {1, . . . , q−1}. Secret sharing allows a set of n parties to possess shares of a secret value, such that any t shares can be used to reconstruct the secret, but any t−1 shares provide no information about the secret. This approach may be used either for “Share”, which means n users to share a random secret without a dealer, so that t are in principle able to reconstruct the secret, or for “Redistribute”, which means t shareholders to compute n′ new, unrelated shares of the same secret, so that t′ new shareholders can reconstruct the secret. In both algorithms the secret is actually never reconstructed, and—since there is no dealer—none of the shareholders knows the secret. custom-character is an access structure, wherein a secret is shared among a population of users in the set , with ||=n, so that any subset ε with ||=t can reconstruct the secret.

Share: this algorithm is executed by each P_ibelonging to an authorized set custom-character ε with cardinality t. Each P_ipicks a random

$r_{i} \overset{R}{} ℤ_{q},$

forms a random polynomial f_i(u)=r_i+a_i,1u+ . . . +a_i,t−1u^t−1and sends f_i(j) mod q to each P_jε custom-character /P_i; the (unknown) shared secret is R=r_j. Every P_iε computes its share of the secret R_i=f_j(i); additionally, each P_ibroadcasts g^rⁱmod p; this way, everybody can compute g^Rmod p;

Redistribute: this algorithm is executed by each P_ibelonging to an authorized set ε with cardinality t. The objective is to generate new shares for the new access structure custom-character . Each P_icomputes a random polynomial formed as f_i(u)=R_i+a_i,1u+ . . . +a_i,t′−1u^t′−1, where R_iis the local share of the secret possessed by P_i; each P_isends f_i(j) mod q to each P_iε/P_i; then, each P_ican locally generate its new share R′_iby Lagrange interpolation;

Using these two algorithms, threshold signatures may be generated. A variant of the Digital Signature Standard (DSS) scheme follows. Let the secret signing key be xεZ_qand the public key be g^xmod p. The scheme has two algorithms:

Sign: given the message m and a random number

$e \overset{R}{} ℤ_{q},$

compute the signature (w,v) such that w=(g^emod p) mod q and v=wx+h(m)e mod q;

Verify: (w,v) is a valid signature on the message m if

w=(g^vh(m)⁻¹(g^x)^−wh(m)⁻¹mod p) mod q;

A threshold signature scheme leverages on the aforementioned secret sharing techniques in order to share the secret key among n parties, thus distributing the signing capabilities over n parties, so that any subset of t can jointly compute a signature, whereas no t−1 can. A threshold version of the aforementioned DSS signature variant follows. The variant assumes that the “Share” algorithm has been executed to create an access structure custom-character and that any principal in has a share x_iof the unknown private key x. In addition, the public key g^xis publicly known. The “Verify” algorithm remains the same, whereas the “Sign” algorithm becomes:

Sign: this algorithm is executed by each P_ibelonging to an authorized set custom-character ε with cardinality t; each P_ihas a local share x_iof the secret signing key x. All the P_iengage in the Share algorithm, generating the value g^emod q and a local share e_iof the (unknown) random value e; then, each P_isends the value v₁=g^ex_i+h(m)e_imod q to the requester of the signature along with the value g^emod q; the first part of the signature is w=g^emod q; given the set of shares {v₁, iε custom-character }, the second part of the signature v can be computed through Lagrange interpolation.

The Share algorithm is executed twice, once prior to signing to generate the public key and shares of the private key, and a second time to generate the first part of the signature and shares of its discrete log.

An OSBE scheme allows two parties to share a key if a predefined party among the two possesses a signature on an agreed-upon message. At first, a message m is chosen; the OSBE round happens between a party P1, who might have a signature (w,v) on m and P2. The OSBE round proceeds as follows:

OSBERound: P1 sends w to P2; P2 generates

$r \overset{R}{} ℤ_{q},$

sends g′ to P1 and computes K₂=((g^x)^ww^h(m))^r; P1 computes K₁=(g^r)^v; K₁=K₂, i.e. P1 and P2 will share a key if P1's signature on m was correct.

Below a SIG members handshake and relative challenge-response protocol that occur upon friendship invitation is presented:

U₁→U₂w₁=g^e¹,g^r¹

U₂→U₁g^r²,w₂=g^e²

U
₁computes K₁=((g^x)^w²w₂^h(M^SIG⁾)^r1K′₁=(g^r²)^v¹and k₁=H(K₁∥K′₁)

U
₂computes K′₂=((g^x)^w¹w₁^h(M^SIG⁾)^r²K₂=(g^r¹)^v²and k₂=H(K₂∥K′₂)

U
₂
→U
₁
E
_k
₂(N)

U
₁
→U
₂
E
_k
₁(N+1)

The SIG members handshake presented above is an algorithm that may be executed by two SIG members that want to authenticate one another as members of a SIG. The two members engage in two separate instances of the OSBE round algorithm, acting in turn as both P1 and P2 over the two executions, at the end of which, each party obtains two keys. Thus the two users, U₁holding the signature (w₁,v₁) and U₂holding the signature (w₂,v₂) engage in the OSBE round sessions establishing two keys each. The two parties then have to prove to one another the knowledge of both keys simultaneously. They engage in a challenge-response protocol to prove to one another knowledge of the keys computed. Thus U₁, upon receiving the last message is already able to tell whether interaction is with a legitimate SIG member.

FIG. 2 is a flow diagram 200 describing a method for verification of personalities in OSNs. The method starts at block 210 with receiving a friendship request from a first OSN user to a second OSN user. A proxy server captures the friendship request at block 220. The friendship request consists of information about both the inviter and the invitee. Thus, in block 230, the proxy server extracts cryptographic information for the first and the second OSN users in order to try to compute a cryptographic handshake, which would verify the membership of both the first and the second user to a same Secret Interest Group (SIG). In some embodiments, the cryptographic information is extracted from an “about me” section of the users in their OSN profiles. The cryptographic information may be held as a string that has no other use except for accomplishing secret cryptographic handshakes. It is expected that the cryptographic information cannot be self-generated. In some embodiments, the cryptographic information of the users is issued by a central entity as a credential for a specific SIG membership. In yet another embodiment, the credential is a signature and oblivious signature based envelopes are used for performing the cryptographic handshake. In some embodiments, a cooperation of a minimum number of entitled users is necessary in order to act as a central entity for issuing the credentials. The operation of issuing credentials in a distributed fashion instead of by a sole entity with authority minimizes the risk of an improper grant of membership, hence an improper grant of a credential.

In some embodiments, the central entity issues a credential after checking the member's compliance with a secret interest group joining policy. In some embodiments the credentials are not issued for lifetime, but a credential revocation is set. In some embodiments, the revocation is set by embedding a time-limit in the credential itself. In another embodiment, the credentials are revoked by publishing a revocation handle to an authenticated public list.

Turning back to FIG. 2, at block 240 the proxy server creates a modified request from the friendship request by adding a notification, that the first user is a member of the same SIG as the second user, when the cryptographic handshake is accomplished. Then, at block 250, the modified request is forwarded to an OSN server to reach the invitee. Next, at block 260, a response to the modified request is received by the second user via the OSN server. Finally, at block 270, a confirmation message is sent to the first user affirming the co-membership of the second user when the second user has accepted the modified request.

FIG. 3 illustrates the operation of a proxy upon a friendship request in an exemplary OSN. There are three participants in this kind of communication—the inviter 310 sending the friendship request, the proxy server 320, and the OSN server 330. The communication between these participants is performed by messages. A friendship request 340 is triggered by the inviter 310. The request is for adding a new friend. It is sent through the browser of the inviter 310. The Uniform Resource Locator (URL) is “http://www.OSNserver.com/ajax/profile/connect.php” and the relevant parameters are “profile_id=xyz”. This message is not forwarded immediately to the receiver i.e. the OSN server 330. Instead, the proxy server 320 looks up the profile of the invitee “profile_id” and extracts the invitee part of a cryptographic handshake. The proxy server 320 looks up the profile of the invitee by means of “GET http://www.OSNserver.com/ajax/profile.php?id=xyz” (message 345), wherein the receiver is the OSN server 330, and extracts cryptographic information gathered in the ‘about me’ section of the invitee “<dt> About me: </dt> <dd>g^e1g^r1</dd>” (message 350) for cryptographic handshake. The proxy server 320 derives the key which is used to encrypt a random nonce N: “pick g^e2, g^r2N, compute K₂”, and then creates its own message 355 “POST http://www.OSNserver.com/ajax/profile/connect.php” to the OSN server 330 with form parameters “profile_id=xyz&message=g^e2, g^r2, E_k2(N)” containing the handshake message and encrypted nonce. If the invitee accepts the friendship request, the inviter 310 is notified in a number of ways, depending on whether the inviter 310 is online or not at the moment of the acceptance. The proxy server 320 intercepts this event in all its possible forms depending on the type of the response. For example, in messages 360 and 365, the browser is notified through an infinite javascript loop, that originates AJAX requests to fetch the updates. Message 360: “GET http://0.channel04.OSNserver.com/x/ . . . /true/p_—. . . =0” is transferred from the inviter 310 to the OSN server 330 through the proxy server 320. The response 365 contains in its payload the string “<a href=“http://www.OSNserver.com/profile.php?id=xyz\”> . . . </a> accepted your friend request” serving as the status update fetched by the aforementioned infinite loop. The message confirmation is not sent back directly to the browser, but the proxy server 320 searches in the inviter's OSN inbox for a message from the invitee with response to the friendship request (messages 370, 375, 380, and 385). First, message 370: “GET http://www.OSNserver.com/inbox/” is for searching the inviter's inbox; then a message 375 containing the list of messages in the inviter 310's inbox is sent back from the OSN server 330 back to the proxy server 320. If the invitee is also running an instance of the proxy 320, then the message will contain “thread ID”: {“subject”: “AAAproxy”,“snippet”: “ . . . ”,“originalAuthor”:xyz . . . ”. By the following message 380: “GET http://www.OSNserver.com/gigaboxx/endpoint/ReadThread.php?tid=thread ID” the proxy server 320 fetches the message marked with the thread ID specified in the response message 375, associated to the code “AAAproxy”. The response message 385 containing a message: “ . . . “message”: “M” . . . ”; the proxy server 320 checks whether M=E_k2(N+1). If the check fails, the standard acceptance of message 365 is forwarded back to the inviter 310. Otherwise, a modified confirmation message that highlights the membership of the invitee to the same SIG as the inviter, for example message 395 containing “<a href=“http://www.OSNserver.com/profile.php?id=xyz\”> . . . —certified SIG member</a> accepted your friend request”, is sent to the browser of the inviter 310 as a response for the update message 390: “GET http://0.channel04.OSNserver.com/x/ . . . /true/p . . . =0”.

FIG. 4 illustrates the operation of a proxy upon a friendship response in an exemplary OSN. There are three participants in this kind of communication: the invitee 410 receiving the friendship request, the proxy server 420, and the OSN server 430. The communication between these participants is performed by messages. At first, the proxy server 420 publishes the invitee's cryptographic information in the “About me” section of the invitee's profile (messages 440 and 445). Message 440: “POST http://www.OSNserver.com/ajax/profile/editinfo.php” with form parameters “ . . . about me=g^e1, g^r1” containing the cryptographic information is sent by the proxy server 420 to the OSN server 430. The confirmation response by the OSN server 430 is message 445: “200 OK”. The operation begins with the invitee 410 visiting a page with a pending friendship request (message 450). This visit is performed through the browser of the invitee 410 by message 450:

“GET http://www.OSNserver.com/reqs.php”. The message 450 is sent to the OSN server 430 via the proxy 420. The page is fetched as shown by message 455: the string “<a href=“http://www.OSNserver.com/profile.php?id=xyz”> . . . </a> <span class=“msg_content”>ĝe2, ĝr2, M</span>” is contained in the message coming from the OSN server 430 to the proxy server 420 and then the message that the inviter has included in the invitation is decoded by “check authenticity of M, decrypt N=D_k1(M), compute M′=E_k1(N+1)”, which is attempting to accomplish the cryptographic handshake and generate the handshake message M′ to be sent to the inviter. In case of successful handshake, the inviter is proved to be a SIG member. In this case, the html message 460: “<a href=“http://www.OSNserver.com/profile.php?id=xyz\”> . . . —certified SIG member</a> <span class=“msg_content”>—crypto handshake omitted—</span>” that is sent to the invitee 410, is a modified message, so as to notify, that the inviter is a SIG member. If the invitee 410 decides to accept the friendship request, the acceptance message (message 465 containing form parameters “ . . . id=xyz”, the id of the inviter) is not forwarded right away. Message 465 is not forwarded right away; instead the modified by the proxy 420 sends message 467 “POST http://www.OSNserver.com/gigaboxx/endpoint/MessageComposerEndpoint.php” with form parameters “ . . . status=M′&subject=AAAproxy&ids[0]=xyz” that the OSN server receives; M′ is the aforementioned message M′. If the considered OSN uses captcha to prevent automated actions by proxy servers, the OSN server 430 sends captcha request 470 containing “for (;;); {“error”: . . . , “errorSummary”: “Security Check Required” . . . ”; the captcha challenge cannot be solved by the proxy server 420 and hence the proxy server transfers the captcha challenge 470 directly to the invitee 410 to have it solved. Then the proxy server 420 receives message 475: “POST http://www.OSNserver.com/reqs.php” with form parameters “captcha response= . . . &id=xyz” with the solution to the captcha from the invitee 410 and sends a modified response 477:

“POST http://www.OSNserver.com/gigaboxx/endpoint/MessageComposerEndpoint.php” with form parameters “ . . . status=M′&subject=AAAproxy&ids[0]=xyz” to the OSN server. Then after receiving the confirmation of the security check from the OSN server 430 by means of message 480: “200 OK”, the proxy server 420 is able to accept the original friendship request and forwards the response of the OSN server 430 back to the invitee 410 (messages 485, 490, and 495). Message 485: “POST http://www.OSNserver.com/ajax/reqs.php” with form parameters “ . . . id=xyz” is sent by the proxy server 420 to the OSN server 430 to finally notify to the OSN server 430 that the invitee 410 has accepted the friendship request; this is the actual forwarding of message 465 that had previously been delayed by the proxy server 420. The response 490: ““msg”: “You are now friends with <a href=“http://www.OSNserver.com/profile.php?id=xyz”> . . . ”, that is confirmation for the friendship, is received by the proxy server 420 from the OSN server 430 and then transferred to the invitee 410 as message 495 identical to message 490.

FIG. 5 represents a block diagram with an exemplary illustration of a system for creating SIGs in OSNs. A proxy server 540 serves as a mediator between the communication of users 530 requesting friendship and the OSN server 510. The OSN server 510 is part of the OSN 520. The intended use is the following: a SIG member runs the proxy server 540, which intercepts only requests towards the specific OSN server 510. The proxy server 540 modifies requests and responses, running cryptographic handshake upon membership invitation and chat events; notification of success or failure of the cryptographic handshake is provided to the user through modifications of the HTML that is displayed in the browser. In some embodiments, the proxy server 540 is a java http proxy server.

Some embodiments of the invention may include the above-described methods being written as one or more software components. These components, and the functionality associated with each, may be used by client, server, distributed, or peer computer systems. These components may be written in a computer language corresponding to one or more programming languages such as, functional, declarative, procedural, object-oriented, lower level languages and the like. They may be linked to other components via various application programming interfaces and then compiled into one complete application for a server or a client. Alternatively, the components maybe implemented in server and client applications. Further, these components may be linked together via various distributed programming protocols. Some example embodiments of the invention may include remote procedure calls being used to implement one or more of these components across a distributed programming environment. For example, a logic level may reside on a first computer system that is remotely located from a second computer system containing an interface level (e.g., a graphical user interface). These first and second computer systems can be configured in a server-client, peer-to-peer, or some other configuration. The clients can vary in complexity from mobile and handheld devices, to thin clients and on to thick clients or even other servers.

The above-illustrated software components are tangibly stored on a computer readable medium as instructions. The term “computer readable medium” should be taken to include a single medium or multiple media that stores one or more sets of instructions. The term “computer readable medium” should be taken to include any physical article that is capable of undergoing a set of physical changes to physically store, encode, or otherwise carry a set of instructions for execution by a computer system which causes the computer system to perform any of the methods or process steps described, represented, or illustrated herein. Examples of computer-readable media include, but are not limited to: magnetic media, such as hard disks, floppy disks, and magnetic tape; optical media such as CD-ROMs, DVDs and holographic devices; magneto-optical media; and hardware devices that are specially configured to store and execute, such as application-specific integrated circuits (“ASICs”), programmable logic devices (“PLDs”) and ROM and RAM devices. Examples of computer readable instructions include machine code, such as produced by a compiler, and files containing higher-level code that are executed by a computer using an interpreter. For example, an embodiment of the invention may be implemented using Java, C++, or other object-oriented programming language and development tools. Another embodiment of the invention may be implemented in hard-wired circuitry in place of, or in combination with machine readable software instructions.

FIG. 6 is a block diagram of an exemplary computer system 600. The computer system 600 includes a processor 605 that executes software instructions or code stored on a computer readable medium 655 to perform the above-illustrated methods of the invention. The computer system 600 includes a media reader 640 to read the instructions from the computer readable medium 655 and store the instructions in storage 610 or in random access memory (RAM) 615. The storage 610 provides a large space for keeping static data where at least some instructions could be stored for later execution. The stored instructions may be further compiled to generate other representations of the instructions and dynamically stored in the RAM 615. The processor 605 reads instructions from the RAM 615 and performs actions as instructed. According to one embodiment of the invention, the computer system 600 further includes an output device 625 (e.g., a display) to provide at least some of the results of the execution as output including, but not limited to, visual information to users and an input device 630 to provide a user or another device with means for entering data and/or otherwise interact with the computer system 600. Each of these output devices 625 and input devices 630 could be joined by one or more additional peripherals to further expand the capabilities of the computer system 600. A network communicator 635 may be provided to connect the computer system 600 to a network 650 and in turn to other devices connected to the network 650 including other clients, servers, data stores, and interfaces, for instance. The modules of the computer system 600 are interconnected via a bus 645. Computer system 600 includes a data source interface 620 to access data source 660. The data source 660 can be access via one or more abstraction layers implemented in hardware or software. For example, the data source 660 may be accessed through network 650. In some embodiments the data source 660 may be accessed via an abstraction layer, such as, a semantic layer.

A data source is an information resource. Data sources include sources of data that enable data storage and retrieval. Data sources may include databases, such as, relational, transactional, hierarchical, multi-dimensional (e.g., OLAP), object oriented databases, and the like. Further data sources include tabular data (e.g., spreadsheets, delimited text files), data tagged with a markup language (e.g., XML data), transactional data, unstructured data (e.g., text files, screen scrapings), hierarchical data (e.g., data in a file system, XML data), files, a plurality of reports, and any other data source accessible through an established protocol, such as, Open DataBase Connectivity (ODBC), produced by an underlying software system (e.g., ERP system), and the like. Data sources may also include a data source where the data is not tangibly stored or otherwise ephemeral such as data streams, broadcast data, and the like. These data sources can include associated data foundations, semantic layers, management systems, security systems and so on.

The above descriptions and illustrations of embodiments of the invention, including what is described in the Abstract, is not intended to be exhaustive or to limit the invention to the precise forms disclosed. While specific embodiments of, and examples for, the invention are described herein for illustrative purposes, various equivalent modifications are possible within the scope of the invention, as those skilled in the relevant art will recognize. These modifications can be made to the invention in light of the above detailed description. Rather, the scope of the invention is to be determined by the following claims, which are to be interpreted in accordance with established doctrines of claim construction.

SECRET INTEREST GROUPS IN ONLINE SOCIAL NETWORKS

Information

Publication Number

Date Filed

Date Published

Inventors

CPC

US Classifications

International Classifications

Abstract

Description

Claims