|Publication number||US7673004 B1|
|Application number||US 11/031,419|
|Publication date||Mar 2, 2010|
|Priority date||Aug 31, 2004|
|Publication number||031419, 11031419, US 7673004 B1, US 7673004B1, US-B1-7673004, US7673004 B1, US7673004B1|
|Inventors||Alex Sherstinsky, Joseph Petviashvili, Eugene Mandel, Jonathan Christensen|
|Original Assignee||Face Time Communications, Inc.|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (33), Non-Patent Citations (1), Referenced by (9), Classifications (14), Legal Events (4)|
|External Links: USPTO, USPTO Assignment, Espacenet|
This application claims priority from U.S. Provisional Patent Application No. 60/606,190 filed Aug. 31, 2004 entitled METHOD AND APPARATUS FOR SECURE IM COMMUNICATIONS USING AN IM MODULE which is hereby incorporated by reference, as if set forth in full in this document, for all purposes.
The present application incorporates by reference for all purposes the entire contents of the following U.S. patent application Ser. No. 10/212,129, entitled MANAGEMENT CAPABILITIES FOR REAL-TIME MESSAGING NETWORKS, filed on Jul. 31, 2002.
The present invention generally relates to instant messaging (IM) and more specifically to systems and methods for providing secure IM communications over IM networks.
With the advent on the Internet, users have been provided with a fast electronic means of communicating with each other. For example, instant messaging (IM) allows users to interact in real-time by trading text messages or any other messages (e.g., file transfers, images, etc.) through the Internet. IM is commonly performed over public instant messaging (PIM) networks. For example, a Yahoo! IM client can send text messages to other Yahoo! IM clients through a public instant messaging network maintained by Yahoo!. These IM communications are typically not encrypted (and hence not secure).
When IM communications are not secure, the text messages (also known as “IMs”, for short) can be intercepted by unintended parties. For example, IMs may be sniffed by third parties as the messages traverse a PIM network. Accordingly, entities, such as businesses, may not wish to adopt IM applications for the fear that privacy/confidentiality may be compromised during IM communications among their employees and between the employees and customers, partners, family, friends, and others. Thus, these businesses are unable to take advantage of the convenience and efficiency that instant messaging provides.
One method that has been developed for sending encrypted IMs is encrypting an IM at an IM client. This solution includes many disadvantages. For example, it is very time consuming and error prone to configure every IM client in a business organization with the special module that encrypts IMs sent from the IM client and decrypts IMs received by the IM client. Additionally, it is very expensive to procure and maintain a certificate used for encrypting IM messages for each IM client installation.
The present invention generally relates to techniques for securing IM communications. In one embodiment, systems and methods are provided for enabling secure communications between IM modules. In one embodiment, an IM is received from a first IM client for a username associated with a second IM client at a first IM module. It is determined if the second IM client can receive IMs through a second IM module that is capable of receiving secure (e.g., authenticated and encrypted) communications from the first IM module. If the second IM module is capable of receiving secure communications from the first IM module, an encrypted IM is sent from the first IM module to the username associated with the second IM client. The encrypted IM is received at the second IM module, which decrypts the IM and sends the decrypted IM to the username at the second IM client.
In one embodiment, a method for enabling secure IM communication is provided. The method comprises: receiving an IM from a first IM client for a username at a first IM module; determining if a second IM client associated with the username receives IMs through a second IM module that is capable of receiving secure IM communications from the first IM module; if the second IM module is capable of receiving secure IM communications from the first IM module, encrypting at least a portion of the IM at the first IM module; and sending the encrypted at least a portion of the IM to the username, wherein the second IM module receives the encrypted at least a portion of the IM, decrypts at least a portion of the IM, and sends the decrypted at least a portion of the IM to the username associated with the second IM client.
In another embodiment, a system for enabling secure IM communications is provided. The system comprises: a plurality of IM clients; a first IM module coupled to a first set of IM clients in the plurality of IM clients, wherein the first IM module receives IMs sent from and destined for an IM client in the first set of IM clients; a second IM module coupled to a second set of IM clients in the plurality of IM clients, wherein the second IM module receives IMs sent from and destined for a second IM client in the second set of IM clients; wherein the first IM module is configured to receive an IM from the first IM client, encrypt at least a portion of the IM, and send the encrypted at least a portion of the IM to a username associated with the second IM client, wherein the second IM module is configured to receive the encrypted at least a portion of the IM, decrypt at least a portion of the encrypted IM, and send the decrypted at least a portion of the IM to the username associated with the second IM client.
In yet another embodiment, an IM module configured to send and receive secure IM communications is provided. The IM module comprises: a receiver configured to receive an IM from a first IM client for a username at a first IM module; a secure communication analyzer configured to determine if a second IM client associated with the username receives IMs through a second IM module that is capable of receiving secure IM communications from the IM module; an encrypting processor configured to encrypt at least a portion of the IM at the first IM module if the second IM module is capable of receiving secure IM communications from the IM module; and a communicator configured to send the at least a portion of the IM to the username, wherein the second IM module receives the encrypted at least a portion of the encrypted IM, decrypts the at least a portion of the IM, and sends the decrypted at least a portion of the IM to the username associated with the second IM client.
A further understanding of the nature and the advantages of the inventions disclosed herein may be realized by reference of the remaining portions of the specification and the attached drawings.
IM clients 104 are used to send and receive instant message communications with other IM clients 104. IM clients 104 may be installed on any computing device, such as a personal computer (PC), pocket PC, personal digital assistant (PDA), RIM Blackberry device, telephone, cellular phone, pager, etc.
In one embodiment, IM clients 104 may send IMs that include textual messages. Additionally, IMs may include other information, such as pictures, HyperText Markup Language (HTML) information, etc. In one embodiment, IM clients 104 are IM clients of any network implementation. For example, the network implementations may include MSN, AIM, Yahoo!, ICQ, SMS, IBM Lotus IM (also known as “SameTime”), Microsoft Exchange 2000, Microsoft Office Live Communications Server (LCS), Reuters Messaging, Jabber, and the like. In one embodiment, IM clients 104 of a particular network implementation can communicate with IM clients 104 of the same network implementation.
Network 106 is any network that can support instant messaging. In one embodiment, network 106 includes one or more public IM networks. For example, if an IM client 104 is a Yahoo! IM client, IM from Yahoo! IMs clients are sent through a Yahoo! public IM network. The same is true for AOL IM (AIM for short) clients that communicate. For example, AOL maintains a public IM network (AIM) where IMs from AOL IM (AIM) clients are transmitted.
In one embodiment, network 106 is a network that is located outside of a firewall for a company. For example, network 106 may be a public IM network (AIM, MSN, Yahoo!), running on top of the Internet, or in some cases, a proprietary IM network, running over an extranet (e.g., a VPN built on top of the Internet). These networks are public in nature in that information sent through the network may be compromised.
IM clients 104 communicate by sending messages to usernames. For example, a username may be “Bob”. A user sends an IM to a user associated with the username “Bob” by addressing the IM to the username “Bob”. Typically, in order to communicate through instant messaging, a user has to be logged in to the IM network with an IM client 104. By logging in, an IM client 104 that is being used for the username “Bob” may be determined and IMs can be routed to the IM client 104. IMs are then sent to the username “Bob” and received at the IM client 104 being used.
IM module 102 is configured to receive and forward instant messages from IM clients 104. In one embodiment, IM module 102 is configured to receive and send instant messages to and from certain IM clients 104 that are connected to it. For example, IM module 102-1 is connected to IM clients 104-1. In one embodiment, all communications to and from IM clients 104-1 are sent through IM module 102-1.
IM module 102 is configured to forward IMs to a username where the IM is received at another IM client 104. These forwarded IMs are received at another IM module 102 and then forwarded to the IM client 104. For example, an IM sent from IM client 104-1 to a username associated with IM client 104-2 is first received at IM module 102-1. IM module 102-1 is then configured to send the IM to IM client 104-2. The IM, however, is received at IM module 102-2, which then forwards the IM to IM client 104-2. As will be described in more detail below, the IM sent from IM module 102-1 to IM module 102-2 is sent as an encrypted (secure) communication. For example, IM module 102-1 and IM module 102-2 negotiate the encryption parameters so that encrypted messages between IM module 102-1 and IM module 102-2 may be exchanged.
Embodiments of IM modules are also described in U.S. patent application Ser. No. 10/212,129, entitled “Management Capabilities for Real-Time Messaging Networks, filed on Jul. 31, 2002, which is hereby incorporated by reference for all purposes.
IM clients 104-1 and IM module 102-1 may communicate over a local area network (LAN) 206 behind firewall 202. Although LAN 206 is described, other networks will be recognized by a person skilled in the art. Similarly, IM clients 104-2 and IM module 102-2 communicate over a LAN 208 behind firewall 204.
As shown, AIM IM clients 104 communicate with other AIM IM clients 104 through an AIM PIM network. Similarly, MSN IM clients 104 and Yahoo! IM clients 104 communicate through MSN and Yahoo! PIM networks, respectively.
Because IM module 102-1 is positioned behind firewall 202, IM module 102-1 is configured to manage communications from public IM clients 104-1 to entities outside firewall 202. Thus, IM module 102-1 can ensure that all IM communications sent from behind firewall 202 may be encrypted before being sent to other IM clients 104 outside of firewall 202. Accordingly, communications between IM module 102-1 to IM module 102-2 through public IM networks 106 may be secure. Although communications between public IM clients 104-1 and IM module 102-1 are not encrypted on the LAN behind firewall 202, it is assumed that the communications may not be intercepted for malicious purposes. Also, communications between public IM clients 104-1 on the LAN behind firewall 202 may not be encrypted, because it is assumed that these communications may not be intercepted altogether.
In step 302, IM module 102-1 determines a destination for the IM. For example, if the IM is sent for username “Bob”, IM module 102-1 determines the username from the IM.
In step 304, IM module 102-1 determines if the username for the IM may receive the IM at a destination IM client 104 that communicates using a second IM module 102. For example, a user for the username may be using an IM client 104-2 behind an IM module 102-2. In one embodiment, as will be described in more detail below, a query may be sent by IM module 102-1 to the username. If the IM is destined for a username that may be using IM client 104-2, IM module 102-2 receives the IM. IM module 102-2 can then reply to the query with information that may be used to determine if it can receive secure communications from IM module 102-1.
In step 306, it is determined if IM module 102-2 can exchange secure communications with IM module 102-1. For example, the message sent from IM module 102-2 is parsed and it may be determined that IM module 102-2 is enabled to receive secure communications. IM module 102-1 may also verify other information, such as a company name, etc. in determining if secure communications can be sent. For example, it is determined if a company name is on a list of companies that have IM modules 102 that can communicate securely. If the company name is on this list, then it is assumed that secure communications can be sent to IM module 102-2.
In step 308, if IM module 102-2 cannot receive secure communications or the username “Bob” is not situated behind an IM module 102, an unencrypted IM is sent to the username “Bob.” Additionally, other actions may be taken, such as sending an IM to the username “Bob” telling the user that this message is not secure, but if an IM module is purchased, secure communications may be enabled.
In step 310, if secure communications may be sent to the username “Bob”, at least a portion of the IM that was received in step 300 is encrypted. In one embodiment, information that was sent in the body of the IM received in step 300 (e.g., the text) is encrypted and sent in the body of an IM through the public IM network 106. In this case, a new IM is generated that is encrypted. In other embodiments, the IM received in step 300 may be encrypted and sent.
In step 312, the encrypted IM is sent to the username for IM client 104-2. In one embodiment, the IM is generated to show that it is from “Alice” to “Bob”. The IM is then sent through the public IM network 106.
In step 314, the encrypted IM is sent through PIM network 106 and received at IM module 102-2. The encrypted IM is received at IM module 102-2 because it is configured to receive messages from network 106 that are destined for the username using IM client 104-2.
In step 316, IM module 102-2 decrypts the encrypted IM. The decryption process will be described in more detail below.
In step 318, the decrypted IM is forwarded to the username at IM client 104-2. Thus, the user using IM client 104-2 who is logged in with the username “Bob” receives an IM that was sent from a username, such as “Alice”. For example, the original text that was received in the IM received in step 300 is sent to destination IM client 104-2.
All subsequent messages as part of this IM conversation between the usernames “Alice” and “Bob” may be communicated between IM modules 102-1 and IM modules 102-2 as encrypted versions inside the “body” portions of IM messages. In other words, the contents of message bodies are encrypted when IMs traverse the public IM networks.
In step 400, a query is sent to the destination username to determine the IM capabilities of the destination IM client 104-2. For example, an IM client 104-2 may be situated behind an IM module 102, in which case, secure communications may be sent, if enabled. Also, IM client 104-2 may not be situated behind an IM module 102, in which case, unencrypted IMs are sent.
In step 402, the query is received by IM module 102-2 and a response to the query is sent to IM module 102-1. IM module 102-2 receives the query that is sent to the username “Bob” because it is situated in front of the IM client 104-2 from which the username “Bob” has been logged in. In one embodiment, a “Get Info” query is sent to the username “Bob”. The “Get Info” query may be any query that is interpreted by IM module 102 as a prompt to send some kind of information.
The response to the query, in one embodiment, may include security capabilities information that may be used to determine if a secure communication between IM module 102-1 and IM module 102-2 can be performed. For example, the body of the response to the “Get Info” query may communicate a company name for the recipient (e.g., “Company 2”) and a security certificate, such as an X.509 certificate. Although an X.509 certificate is described, it will be understood that any security certificate may be used.
In step 404, a response to the query is received at IM module 102-1, which recognizes it as a response to the query. In one embodiment, the body of the response may be parsed and it may be recognized that the message is a response to the query that includes security capabilities information from IM module 102-2.
In step 406, the response is parsed to determine the security capabilities information. For example, the security capabilities information may indicate that the username “Bob” is logged into a PIM network 106 via an IM module 102-2. Additionally, it may be determined that a company name is “company 2” and that it is associated with a certificate that is also included.
In step 408, at least a portion of the IM is encrypted using the security capabilities information. For example, the text of the IM received in step 400 is encrypted using the security capabilities information. In one embodiment, the certificate determined in step 406 may be used to encrypt the IM. In an alternative embodiment, IM module 102-1 may retrieve or look up a certificate in a central certificate directory by the company name, determined using the security capabilities information. No matter which method is used, IM module 102-1 may verify the certificate and decide that it can trust it. In one embodiment, certificates are verified by checking to make sure that they are signed by a well-known and trusted Certificate Authority (CA), such as, but not limited to, Verisign.
In one embodiment, IM module 102-1 may generate a session key and encrypt the text of the IM received in step 400 with this key (e.g., symmetric encryption). The session key is then encrypted with a public key associated with IM module 102-2, and the encrypted text with the encrypted session key is signed with the public key associated with a CA of module 102-1 (e.g., situated at “Company 1”) and placed into a digital envelope, such as an S/MIME envelope. This constitutes a payload component that may be inserted in the message body portion of an IM. Thus, a security capabilities information component that includes information that may be used by IM module 102-2 along with the encrypted payload may be inserted into the body of a public IM from “Alice” to “Bob” and forwarded through a PIM network 106 in step 410. Although the above encryption method is described, it will be recognized that other methods of encryption may be used.
In step 412, second IM module 102-2 receives the encrypted IM and recognizes that the IM is an encrypted IM from an IM module 102. In one embodiment, IM module 102-2 uses the attached security capabilities information component to determine that the IM includes encrypted information.
In step 414, the IM is decrypted using the security capabilities information. For example, IM module 102-2 parses the S/MIME-encoded message body. The session key is retrieved and decrypted using the private key of IM module 102-2. Then the message text is decrypted using the session key. The signature is verified using the public key of the CA of Company 2 (as was provided in the response IM in step 404).
In step 416, an informational IM is sent to the destination username, indicating that secure communications with the destination username have been enabled. For example, the informational message may state that IMs are encrypted using FaceTime's technology by a company, such as Company 1, and the username “Alice” that sent the IM is indeed associated with Company 1.
In step 418, the decrypted IM is sent to the destination username at the destination IM client 104-2. The S/MIME-encoded body is replaced with the original plain text that was sent in the original IM.
All subsequent messages exchanged as part of this IM conversation between “Alice” and “Bob” are transmitted between IM module 102-1 and IM module 102-2 as encrypted versions inside the message body portions of the IMs. The same session key may be used for the duration of the entire conversation.
Query sender 504 generates the query to send to the username, and the query is received at a query processor 512 at IM module 102-2. A response generator 514 sends a response with security capabilities information to the username that originally sent the IM. IM module 102-1 receives the response at IM parser and authenticator 508. IM parser and authenticator 508 parse the response and determine security capabilities information. The security capabilities information may be used to determine if IM module 102-2 is capable of receiving secure communications from IM module 102-1. Additionally, IM parser and authenticator 508 may authenticate the security capabilities information found in the response. For example, IM parser and authenticator 508 may either authenticate a digital certificate associated with the response or may look up a digital certificate in a database 518.
A communicator 506, if the response is authenticated, may send a confirmation IM to IM client 104-1 indicating that secure communications with the destination username is established.
An encrypting processor 510 then encrypts the IM. In one embodiment, the text of the original IM is encrypted and placed into the payload (message body) along with other security capabilities information. The encrypted IM is then sent in an IM through a public IM network 106 to the destination username.
The encrypted IM is received at a decrypting processor 516 of IM module 102-2. Decrypting processor 516 decrypts the IM and sends it to the username at IM client 104-2.
Accordingly, using IM modules, secure IM communications may be enabled. Instead of encrypting and decrypting IM messages at IM clients, an IM module is configured to encrypt messages and send the encrypted messages to another IM client behind another IM module. The IM module then intercepts, decrypts, and forwards the message to the IM client.
Because an IM module is situated such that IM clients communicate through the IM module, an effective method of sending encrypted IMs is provided at the IM module. Thus, IMs do not need to be encrypted at the IM clients. Additionally, the encrypted IMs are sent to a username associated with an IM client and are received at a second IM module. A second IM module is configured to decrypt the IM and send the decrypted IM to the username at the IM client. Thus, the destination IM client does not need to be configured to decrypt any encrypted emails. Accordingly, secure IM communications are enabled using IM modules.
The present invention can be implemented in the form of control logic in software or hardware or a combination of both. Based on the disclosure and teachings provided herein, a person of ordinary skill in the art will appreciate other ways and/or methods to implement the present invention.
The above description is illustrative but not restrictive. Many variations of the invention will become apparent to those skilled in the art upon review of the disclosure. The scope of the invention should, therefore, be determined not with reference to the above description, but instead should be determined with reference to the pending claims along with their full scope or equivalents.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US5943478||Apr 4, 1997||Aug 24, 1999||Flash Communications, Inc.||System for immediate popup messaging across the internet|
|US5999932||Jan 13, 1998||Dec 7, 1999||Bright Light Technologies, Inc.||System and method for filtering unsolicited electronic mail messages using data matching and heuristic processing|
|US6052372||Nov 7, 1996||Apr 18, 2000||British Telecommunications Public Limited Company||Method and apparatus for establishing communication|
|US6212548||Jul 30, 1998||Apr 3, 2001||At & T Corp||System and method for multiple asynchronous text chat conversations|
|US6248946||Mar 1, 2000||Jun 19, 2001||Ijockey, Inc.||Multimedia content delivery system and method|
|US6260148||Jul 26, 1999||Jul 10, 2001||Microsoft Corporation||Methods and systems for message forwarding and property notifications using electronic subscriptions|
|US6292800||Jan 29, 1999||Sep 18, 2001||America Online||Database system|
|US6301609||Sep 8, 1999||Oct 9, 2001||Lucent Technologies Inc.||Assignable associate priorities for user-definable instant messaging buddy groups|
|US6308238||Nov 12, 1999||Oct 23, 2001||Akamba Corporation||System and method for managing connections between clients and a server with independent connection and data buffers|
|US6336133||May 13, 1998||Jan 1, 2002||America Online, Inc.||Regulating users of online forums|
|US6339784||May 13, 1998||Jan 15, 2002||America Online, Inc.||Self-policing, rate limiting online forums|
|US6366962||Dec 18, 1998||Apr 2, 2002||Intel Corporation||Method and apparatus for a buddy list|
|US6389132||Oct 13, 1999||May 14, 2002||Avaya Technology Corp.||Multi-tasking, web-based call center|
|US6400381||Jun 11, 1999||Jun 4, 2002||International Business Machines Corporation||Web places|
|US6408066||Dec 15, 1999||Jun 18, 2002||Lucent Technologies Inc.||ACD skill-based routing|
|US6430602||Aug 22, 2000||Aug 6, 2002||Active Buddy, Inc.||Method and system for interactively responding to instant messaging requests|
|US6449344||Jan 27, 1997||Sep 10, 2002||Aol Acquisition Corporation||Communication system|
|US7127741 *||Jun 22, 2001||Oct 24, 2006||Tumbleweed Communications Corp.||Method and system for e-mail message transmission|
|US7131003 *||Feb 20, 2003||Oct 31, 2006||America Online, Inc.||Secure instant messaging system|
|US20030125927||Dec 28, 2001||Jul 3, 2003||Microsoft Corporation||Method and system for translating instant messages|
|US20030131061 *||Nov 27, 2002||Jul 10, 2003||Active Buddy, Inc.||Transparent proxy server for instant messaging system and methods|
|US20030204720 *||Apr 26, 2002||Oct 30, 2003||Isadore Schoen||Secure instant messaging system using instant messaging group policy certificates|
|US20030204741 *||Apr 26, 2002||Oct 30, 2003||Isadore Schoen||Secure PKI proxy and method for instant messaging clients|
|US20040015610 *||Jul 18, 2002||Jan 22, 2004||Sytex, Inc.||Methodology and components for client/server messaging system|
|US20040088423 *||Jun 10, 2003||May 6, 2004||Akonix Systems, Inc.||Systems and methods for authentication of target protocol screen names|
|US20040103318||Jun 10, 2003||May 27, 2004||Akonix Systems, Inc.||Systems and methods for implementing protocol enforcement rules|
|US20040109518 *||Jun 10, 2003||Jun 10, 2004||Akonix Systems, Inc.||Systems and methods for a protocol gateway|
|US20040111623||Jun 10, 2003||Jun 10, 2004||Akonix Systems, Inc.||Systems and methods for detecting user presence|
|US20040133520 *||Jun 17, 2003||Jul 8, 2004||Callas Jonathan D.||System and method for secure and transparent electronic communication|
|US20040133775 *||Jun 17, 2003||Jul 8, 2004||Callas Jonathan D.||System and method for secure electronic communication in a partially keyless environment|
|US20040136386||Jun 10, 2003||Jul 15, 2004||Akonix Systems, Inc.||Systems and methods for reflecting messages associated with a target protocol within a network|
|US20040210772 *||Nov 19, 2003||Oct 21, 2004||Jeff Hooker||Method and apparatus for secure instant messaging utilizing server-supervised publication|
|US20050114652 *||Nov 18, 2004||May 26, 2005||Totemo Ag||End-to-end encryption method and system for emails|
|1||*||Ramsdell et. al., "S/MIME Gateway Protocol", http://tools.ietf.org/html/draft-enc-smime-gateway-00, Jul. 12, 2001.|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US7890084 *||Oct 30, 2006||Feb 15, 2011||Cellco Partnership||Enterprise instant message aggregator|
|US8032165||Oct 19, 2010||Oct 4, 2011||Cellco Partnership||Enterprise instant message aggregator|
|US8732854 *||Nov 1, 2006||May 20, 2014||Time Warner Cable Enterprises Llc||Methods and apparatus for premises content distribution|
|US9104297 *||Jan 25, 2013||Aug 11, 2015||International Business Machines Corporation||Indicating organization of visitor on user interface of user engaged in collaborative activity with visitor|
|US9313458||Aug 26, 2013||Apr 12, 2016||Time Warner Cable Enterprises Llc||Downloadable security and protection methods and apparatus|
|US9313530||Nov 12, 2012||Apr 12, 2016||Time Warner Cable Enterprises Llc||Technique for securely communicating programming content|
|US20080112405 *||Nov 1, 2006||May 15, 2008||Chris Cholas||Methods and apparatus for premises content distribution|
|US20110035591 *||Feb 10, 2011||Cellco Partnership D/B/A Verizon Wireless||Enterprise instant message aggregator|
|US20140215354 *||Jan 25, 2013||Jul 31, 2014||International Business Machines Corporation||Indicating organization of visitor on user interface of user engaged in collaborative activity with visitor|
|U.S. Classification||709/206, 713/156, 709/207, 713/153, 713/150|
|Cooperative Classification||H04L63/20, H04L51/04, H04L63/0428, H04L12/581|
|European Classification||H04L63/04B, H04L51/04, H04L63/20, H04L12/58B|
|Jan 7, 2005||AS||Assignment|
Owner name: FACE TIME COMMUNICATIONS, INC.,CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:SHERSTINSKY, ALEX;PETVIASHVILI, JOSEPH;MANDEL, EUGENE;AND OTHERS;REEL/FRAME:016163/0496
Effective date: 20041227
|Aug 21, 2013||FPAY||Fee payment|
Year of fee payment: 4
|Apr 29, 2015||AS||Assignment|
Owner name: GOLUB CAPITAL LLC, AS AGENT, ILLINOIS
Free format text: SECURITY INTEREST;ASSIGNOR:ACTIANCE, INC.;REEL/FRAME:035527/0923
Effective date: 20150429
|May 15, 2015||AS||Assignment|
Owner name: ACTIANCE, INC., CALIFORNIA
Free format text: CHANGE OF NAME;ASSIGNOR:FACETIME COMMUNICATIONS, INC.;REEL/FRAME:035705/0823
Effective date: 20110125