Source: http://www.google.com/patents/US20040044776?dq=5,222,134
Timestamp: 2014-03-12 09:07:39
Document Index: 513848904

Matched Legal Cases: ['arty 185', 'arty 185', 'arty 185', 'arty 185', 'arty 185', 'arty 185', 'arty 185', 'arty 185', 'arty 185']

Patent US20040044776 - Peer to peer file sharing system using common protocols - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inAdvanced Patent SearchPatentsThere is provided a method for exchanging data between a first device and a second device via a network. The method includes (a) communicating a request for the data from the second device to the first device, (b) communicating an identifier for the data from the first device to the second device, (c)...http://www.google.com/patents/US20040044776?utm_source=gb-gplus-sharePatent US20040044776 - Peer to peer file sharing system using common protocolsAdvanced Patent SearchPublication numberUS20040044776 A1Publication typeApplicationApplication numberUS 10/104,743Publication dateMar 4, 2004Filing dateMar 22, 2002Priority dateMar 22, 2002Publication number10104743, 104743, US 2004/0044776 A1, US 2004/044776 A1, US 20040044776 A1, US 20040044776A1, US 2004044776 A1, US 2004044776A1, US-A1-20040044776, US-A1-2004044776, US2004/0044776A1, US2004/044776A1, US20040044776 A1, US20040044776A1, US2004044776 A1, US2004044776A1InventorsMichael LarkinOriginal AssigneeInternational Business Machines CorporationExport CitationBiBTeX, EndNote, RefManReferenced by (25), Classifications (9), Legal Events (1) External Links: USPTO, USPTO Assignment, EspacenetPeer to peer file sharing system using common protocolsUS 20040044776 A1Abstract There is provided a method for exchanging data between a first device and a second device via a network. The method includes (a) communicating a request for the data from the second device to the first device, (b) communicating an identifier for the data from the first device to the second device, (c) communicating the identifier from the second device back to the first device, and (d) communicating the data from the first device to the second device, after the communication of the identifier from the second device back to the first device. The request, the identifier, and the data are formatted in accordance with a protocol that is common to both of the first device and the second device. There is also provided a system for a first device to exchange data with a second device via a network. Images(5) Claims(22)
[0035]FIG. 1 is a block diagram of a system 100 configured for a first device, e.g., a local device, to exchange data with a second device, e.g., a remote device, via a network in accordance with the present invention. The data can represent any form of text, graphics, video or audio information. [0036] System 100 includes two workstations 120, 130 configured for communication with one another via a network 125. As mentioned earlier, the meaning of the terms �local device� and �remote device� depend on one's perspective. As such, either of workstations 120, 130 may be regarded as the local device, and then the other would be regarded as the remote device. [0037] Network 125 can be any of a local area network (LAN), a wide area network (WAN), or a combination of networks, such as a corporate intranet coupled to the Internet. Workstations 120, 130 can connect to network 125 via a wire conductor, an optical link or a wireless link. [0038] Workstations 120, 130 are meant to include any processor or device configurable for exchanging data with another processor or device via network 125. By way of example, such a processor or device can be a general purpose microcomputer, such as one of the members of the Sun� Microsystems family of computer systems, one of the members of the IBM Personal Computer family, or any conventional work-station or graphics computer device, a desktop computer, a laptop computer, or a personal digital assistant. Workstation 120 has an affiliated local storage device 105, and workstation 130 has an affiliated local storage device 145. In their preferred embodiment, storage devices 105 and 145, are disk storage media. [0039] Workstation 120 also includes a buffer 112, the purpose of which is described below. Buffer 112 is a data storage device. It can be implemented, for example, as a random access memory (RAM) and located either internal to workstation 120, as shown in FIG. 1, or external to workstation 120. Alternatively, it can be implemented as part of a storage system such as storage device 105, or on another storage system such as a separate disk drive. [0040] A software program module within which the present invention is embodied is installed in a memory on each of workstations 120 and 130. The software module includes instructions for execution by the processors within workstations 120 and 130 to implement a configuration tool 115, 135 and a file-sharing engine (FSE) 110, 140, as described herein. [0041] Consider a case of two users �A� and �B�, in this example two people. User A has workstation 120 and user B has workstation 130. In one embodiment of the present invention, a simple model using minimal security, a typical transaction might proceed as follows: [0042] (1.1) At some point in time, A decides to share a file 102 with B. [0043] (1.2) A uses configuration tool 115 to mark file 102 as shareable, and to permit B's access to file 102. [0044] (1.3) A's configuration tool 115 notifies A's FSE 110 of the new permission and share information as defined in step 1.2. [0045] (1.4) At some point, B uses configuration tool 135 to create a local reference to A's share, that is, to create a local reference on B's workstation 130 to A's file 102. [0046] (1.5) B's FSE 140 authenticates to A's FSE 110 using a suitable security mechanism. That is, B's FSE 140 provides some appropriate security information to A's FSE 110 in order to identify B as having authorization to access file 102. [0047] (1.6) A communication link is established between B's FSE 140 and A's FSE 110 across network 125. B's FSE 140 establishes a connection to A's FSE 110. B's FSE 140 sends A's FSE 110 a status packet 150, i.e., a �heartbeat� packet, at periodic, preferably regular, time intervals, until the communication link is terminated. In return, A's FSE 110 sends a status packet reply 175 to B's FSE. This round-trip exchange of status packet 150 and status packet reply 175 allows both A's FSE 110 and B's FSE 140 to recognize whether the other is �online�, and conversely to recognize whether the other is not connected to the network and/or to determine link congestion. Since a slow reverse link could skew the transit time of a packet, there may be situations where one wishes to consider a one-way transit time. For example, travel time of status packet 150 can be used to determine quality and congestion of network 125. [0048] (1.7) File access is passed through B's FSE 140 when B makes a request for data from file 102 or when one of B's local software applications attempts to access a remote reference or drive letter/mount point, which is mapped to A's workstation 120 at the time of the request. [0049] (1.8) At B's FSE 140, the request for data in step 1.7 is translated into an HTTP request 155 and sent to A's FSE 110. HTTP request 155 includes relevant information such as a file name and an indication of which data block is being requested. [0050] (1.9) A's FSE 110 decodes HTTP request 155 and sends a marker packet 160 to B's FSE. Marker packet 160 can be encoded as an HTTP cookie or it can be encoded using some other suitable encoding technique. A cookie is typically a small packet of information sent from one party to another party to be retrieved at a later time by the sending party. Marker packet 160 contains an identification number that B's FSE 140 stores on local storage device 145 for use in future communications. [0051] (1.10) A's FSE 110 reads B's requested data from A's local shared file 102 and encodes this data in an HTTP-suitable format. This encoded data is stored in a buffer 112 local to A's workstation 120, and marked with an identification matching that of marker packet 160, which was sent to B's FSE 140 in step 1.9. At some point, B's FSE 140 sends a second request, i.e., a request 165, to A's FSE 110 containing the identification for marker packet 160 and a request for retrieval of the data previously stored in buffer 112. By buffering the encoded data in buffer 112, it is possible to cache future requests for the same data, and also, if for some reason there is corruption on the link, it is possible for the requestor to re-request the data by resubmitting the same marker. This marker/buffering is described below in greater detail. Note that in some circumstances A's workstation 120 cannot initiate a connection to B's workstation 130, but once a connection is established from B's workstation 130 to A's workstation 120, A's workstation 120 can send data over the connection. Accordingly, A's FSE 110 does not send the encoded data directly back to B's workstation 130 because it cannot be assumed that A's workstation 120 can reach B's workstation 130. [0052] (1.11) A's FSE 110 receives request 165 and validates the marker packet identification included therein against a list of outstanding marker identifications. If the marker packet identification is valid, the data stored in buffer 112 is encoded in an HTTP-suitable format and sent as a data packet 170 to B's FSE 140. [0053] (1.12) If more data packets are required by B's FSE 140 from A's FSE 110 to fulfill the request for data in step 1.7, then steps 1.7-1.11 are repeated as necessary. The data block stored in buffer 112 by A's FSE 110 in step 1.10 is saved for a period of time to allow a retransmission of the data block if a network outage or other error, such as a data checksum error, occurs. [0054] (1.13) Assume that B's local storage device 145 contains a file 147 that user A is permitted to access. In situations where A's workstation 120 cannot initiate a connection to B's workstation 130, the periodic transmission of status packet 150 from B's FSE 140 to A's FSE 110 (see step 1.6), can be used for A's FSE 110 to request data from B's FSE 140. For example, B's workstation 130 may be located behind a component that blocks unsolicited incoming data, e.g., a firewall 127, and as such, would block a transmission from A's workstation 120. Status packet 175 includes a field within which a file request from A's workstation to B's workstation can be encoded. This permits system 100 to operate in an environment that only permits one-way communications channel initiations, as is the case for certain types of firewall software. [0055] (1.14) When B's FSE 140 finds that status packet reply 175 includes a request by A's FSE 110 for data from file 147, a sequence of steps similar to 1.51.12 is used to send data from B's FSE 140 to A's FSE 110. However, B's FSE 140, instead of holding data locally and waiting for a retrieval request from A's FSE, sends an HTTP encoded request 180 to A's FSE 110 that contains data blocks requested by A's FSE 110, along with a data checksum. [0056] As described in steps 1.1-1.14, B's workstation 130 initiates a communication session by sending a status packet 150 to A's workstation 120. However, this description is only exemplary, as it is possible for A's workstation 120 to initiate the session if the roles of the workstations are reversed, or if true bi-directional initiation is allowed. [0057] If A's FSE 110 determines that a threshold number of lost status packets is reached, then it purges data from buffer 112, and the marker packet identification, that corresponds to the lost status packets. If B's FSE 140 determines that a threshold number of lost status packets is reached, then it purges the marker packet identification that corresponds to the lost status packets. Users A and B may receive an error message on their respective workstations or on an operator panel. [0058] System 100 may employ encryption technology to protect the integrity of data being transferred between workstations 120 and 130 via network 125. For example, in step 1.11, FSE 110 may encrypt data contained within data packet 170, and in step 1.14, FSE 140 may encrypt data contained within HTTP encoded request 180. [0059] Authentication could be performed by a third party 185 at various times during the operation of system 100. Third party 185 may be implemented as a workstation in a manner similar to that of workstations 120, 130. Third party 185 includes a processor with an associated memory that holds a program module containing instructions for executing security features for system 100. In one embodiment, in step 1.5, third party 185 could perform the authentication of B's FSE 140 to A's FSE 110. This is known as key-pair authentication and is common in encryption technology. [0060] In another embodiment, in steps 1.11 and 1.14, third party 185 intervenes to inspect some or all of the data transmissions between A's FSE 110 and B's FSE 140. This is known as metadata based inspection. In this scheme, third party 185 inspects characteristics of subject data, such as filename, content type, checksum, date, etc. and, based on some rule, decides whether a transfer of the subject data between A's workstation 120 and B's workstation 130 should be allowed or denied. [0061] System 100 employs a security framework that affords a system designer considerable latitude when integrating the system within a given environment. A simple authentication mechanism consists of a basic rule based ACL as mentioned earlier. A second, more robust implementation involves an exchange of security keys between participants. This also grants the ability to use a third party authentication scheme, which would not be necessary under the ACL-based scheme. [0062] Although system 100 is described herein as having the instructions for the method of the present invention installed into the memories of workstations 120, 130 and third party 185, the instructions can reside on an external storage media 190 for subsequent loading into workstations 120, 130 and third party 185. Storage media 190 can be any conventional storage media, including, but not limited to, a floppy disk, a compact disk, a magnetic tape, a read only memory, or an optical storage media. Storage media 190 could also be a random access memory, or other type of electronic storage, located on a remote storage system and coupled to workstations 120, 130 and third party 185. [0063]FIG. 2 is a block diagram of a functional hierarchy of one embodiment of a system, in accordance with the present invention, employing HTTP protocol. With regard to the directionality of communication between two participants, when viewed from a purely functional sense, the present invention only requires an ability for one-way unmolested communication initiation between the two participants. HTTP is the preferred communications protocol because of the aforementioned benefits, such as the prevalent policy of allowing HTTP (web) traffic to flow through corporate firewalls and other Internet blocks. The system includes a client application, a client OS integration module, an HTTP driver, an operating system, a TCP/IP stack and a network. The operating system, TCP/IP stack and network operate in a conventional manner. [0064] The client application can be any generic software application running on either of A's or B's workstations. Examples of such generic software include Microsoft Word�, Microsoft Excel�, etc. The client application interfaces with the client OS integration module when a request is made for data stored on a drive letter or mount point. [0065] The client OS integration module interfaces with a protocol driver that is responsible for formulating the packets and requests described earlier. The protocol driver module uses features of the operating system to send network packets and requests over the network. The client OS integration module also provides a drive letter mapping or directory mount point to files located at a remote site. For example, A's workstation 120 would use this module to map a drive letter, e.g., J:\, to reflect the files that are available on B's workstation 130. Without such a module, a user at workstation 120 would need to search and then transfer or copy files of interest from workstation 130. Thus, the client OS integration module provides the aforementioned seamless integration with the operating system. [0066] The HTTP driver receives requests from the client OS integration module and translates the requests into HTTP format. It then uses the operating system's native technology to send messages from workstation 120 to workstation 130, or vice versa. [0067]FIG. 3 is a block diagram of a functional hierarchy of the present invention employing a user defined, user supplied, protocol. FIG. 3 illustrates an alternate scenario to that of FIG. 2 using a user-defined protocol that is forwarded and unmolested in the particular environment. The hierarchy of FIG. 3 differs from that of FIG. 2 in the way the data is formulated and sent across the network link. As shown in FIG. 3, depending on the particular user-defined protocol being used, it is possible that the client operating system (OS) may be bypassed via path 305 when the protocol interfaces with the network stack. One protocol that could be used in accordance with the hierarchy shown in FIG. 3 is Remote Procedure Call (RPC), for example, but others also exist. [0068]FIG. 4 is a block diagram of a functional hierarchy of the present invention employing Simple Object Access Protocol (SOAP) over various lower-level protocols. SOAP is a protocol in which a remote procedure call (RPC) can be characterized as an XML message and dispatched to a remote server. Since this scheme is RPC-based, the parameters in the procedure call include the various packets involved in the exchange, such as the status packet, the status reply packet, data packets, etc. Because SOAP itself relies on an underlying protocol, the present invention can employ SOAP over HTTP, SOAP over SMTP, or SOAP over any other suitable protocol. [0069] The present invention integrates seamlessly with a client OS, for example, by providing a drive letter or mount point to the client. This feature is represented in FIGS. 2-4 by a block denoted �Client OS integration module�. A local user would not have to use a search engine, and instead the local user would be able to browse files available at a remote location in a standard file explorer window. [0070] The status packet, i.e., status packet 150 in FIG. 1, is a specially formulated HTTP request. This packet is periodically sent at some time interval, preferably a regular time interval, from a requester of data to a provider of the data. The interval of time does not necessarily need to be firmly fixed, but rather, the time interval between two consecutive status packets should be less than some predetermined time interval so that each of workstations 120 and 130 will recognize that the other is �online�. The interval can be specified at compile-time. In one embodiment the interval is 60 seconds. The status packet serves a number of purposes: [0071] (1) It directly provides for an ability for multiplexed two-way sharing of files over a link that can only be initiated in one direction. [0072] (2) It is used by one end of a link to determine whether the other end of the link is still connected. [0073] (3) Timestamp information in the status packet can be used to diagnose link quality by checking transit time of the status packets across the network. [0074] (4) It provides the mechanism for file system metadata propagation, such as when files shared on the provider end are added or deleted. [0075] It should be understood that various alternatives and modifications of the present invention can be devised by those skilled in the art. The present invention is intended to embrace all such alternatives, modifications and variances that fall within the scope of the appended claims. Referenced byCiting PatentFiling datePublication dateApplicantTitleUS7036040 *Nov 26, 2002Apr 25, 2006Microsoft CorporationReliability of diskless network-bootable computers using non-volatile memory cacheUS7403995 *Jan 8, 2003Jul 22, 2008Outhink, Inc.Symmetrical bi-directional communicationUS7454653 *Jan 10, 2006Nov 18, 2008Microsoft CorporationReliability of diskless network-bootable computers using non-volatile memory cacheUS7499899 *Jul 2, 2004Mar 3, 2009Northrop Grumman CorporationDynamic software integration architectureUS7519614Aug 31, 2006Apr 14, 2009Sap AgData verification systems and methods using business objectsUS7526483 *Oct 23, 2003Apr 28, 2009Microsoft CorporationSystem and method for virtual folder sharing including utilization of static and dynamic listsUS7644239May 3, 2004Jan 5, 2010Microsoft CorporationNon-volatile memory cache performance improvementUS7673066 *Oct 12, 2004Mar 2, 2010Sony CorporationFile transfer protocol for mobile computerUS7685109Mar 29, 2006Mar 23, 2010Amazon Technologies, Inc.Method and apparatus for data partitioning and replication in a searchable data serviceUS7747894 *Jun 6, 2005Jun 29, 2010Microsoft CorporationTransport-neutral in-order delivery in a distributed systemUS7756983Apr 24, 2008Jul 13, 2010Outhink, Inc.Symmetrical bi-directional communicationUS7801912Mar 29, 2006Sep 21, 2010Amazon Technologies, Inc.Method and apparatus for a searchable data serviceUS7912967Jul 7, 2010Mar 22, 2011Outhink, Inc.Symmetrical bi-directional communicationUS8041904Nov 30, 2009Oct 18, 2011Microsoft CorporationNon-volatile memory cache performance improvementUS8046821 *Feb 13, 2006Oct 25, 2011Qualcomm IncorporatedMechanism and method for controlling network access to a service providerUS8055753 *Jun 11, 2003Nov 8, 2011International Business Machines CorporationPeer to peer job monitoring and control in grid computing systemsUS8108483 *Jan 30, 2004Jan 31, 2012Microsoft CorporationSystem and method for generating a consistent user namespace on networked devicesUS8255645Sep 13, 2011Aug 28, 2012Microsoft CorporationNon-volatile memory cache performance improvementUS8315988 *Aug 31, 2006Nov 20, 2012Sap AgSystems and methods for verifying a data communication processUS8392400Mar 29, 2006Mar 5, 2013Amazon Technologies, Inc.Method and apparatus for stress management in a searchable data serviceUS8484167 *Aug 31, 2006Jul 9, 2013Sap AgData verification systems and methods based on messaging dataUS8554758Mar 29, 2006Oct 8, 2013Amazon Technologies, Inc.Method and apparatus for monitoring and maintaining health in a searchable data serviceUS8560456 *Dec 2, 2005Oct 15, 2013Credigy Technologies, Inc.System and method for an anonymous exchange of private dataUS20120124158 *Jan 12, 2012May 17, 2012Jianyu Roy ZhengFile transfer protocol for mobile computerWO2007079303A2 *Nov 30, 2006Jul 12, 2007Patrick W RansilMethod and apparatus for a distributed file storage and indexing service* Cited by examinerClassifications U.S. Classification709/228International ClassificationH04L29/08, H04L29/06Cooperative ClassificationH04L69/329, H04L69/18, H04L67/06, H04L67/104European ClassificationH04L29/08N5, H04L29/06KLegal EventsDateCodeEventDescriptionMar 22, 2002ASAssignmentOwner name: INTERNATIONAL BUSINESS MACHINES CORPORATION, NEW YFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:LARKIN, MICHAEL KEVIN;REEL/FRAME:012732/0608Effective date: 20020313RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services©2012 Google