Source: http://www.google.com/patents/US7533185?dq=6,108,703
Timestamp: 2014-03-11 23:09:53
Document Index: 742732765

Matched Legal Cases: ['art 22', 'art 20', 'art 21', 'art 21', 'art 22', 'arts 22', 'art 22', 'art 22', 'art 20', 'art 22', 'art 22', 'art 22', 'art 20', 'art 20', 'art 20', 'art 22']

Patent US7533185 - Data communication method, system and program using unicast and multicast ... - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inAdvanced Patent SearchPatentsIn a data communication method, when packet data are sent and received among a plurality of computers connected each other via the network, communications are established by using a unicast connection. Then, the packet data are sent by selectively using a multicast communication and the unicast communication...http://www.google.com/patents/US7533185?utm_source=gb-gplus-sharePatent US7533185 - Data communication method, system and program using unicast and multicast communicationsAdvanced Patent SearchPublication numberUS7533185 B2Publication typeGrantApplication numberUS 10/372,960Publication dateMay 12, 2009Filing dateFeb 26, 2003Priority dateMar 22, 2002Fee statusPaidAlso published asUS20030182446Publication number10372960, 372960, US 7533185 B2, US 7533185B2, US-B2-7533185, US7533185 B2, US7533185B2InventorsMasami Koide, Akira SuzukiOriginal AssigneeRicoh Company, Ltd.Export CitationBiBTeX, EndNote, RefManPatent Citations (31), Non-Patent Citations (7), Referenced by (1), Classifications (15), Legal Events (2) External Links: USPTO, USPTO Assignment, EspacenetData communication method, system and program using unicast and multicast communicationsUS 7533185 B2Abstract In a data communication method, when packet data are sent and received among a plurality of computers connected each other via the network, communications are established by using a unicast connection. Then, the packet data are sent by selectively using a multicast communication and the unicast communication for at least one computer to which the communication is established. As a result, it is possible to reduce an amount of network traffic under a peer-to-peer network without intermediation of a server and improve reliability of the multicast communication.
Meanwhile, it is indispensable to provide a network application with communication functions such as �multicast� and �broadcast�. In the multicast communication, one host can communicate with a plurality of specified hosts. On the other hand, in the broadcast, one host can communicate with all unspecified clients. Under the multicast and the broadcast, if a host sends a packet to a network address, which is designated for each of the multicast and the broadcast, (multicast address and broadcast address) only one time, a host can simultaneously send the packet to desired hosts connected to the host via a network. For that reason, the multicast function and the broadcast function work in favor of the processing efficiency and the band utility ratio of the network.
In a conference system where a plurality of hosts are connected to each other and information is communicated among the hosts, it is more preferable to use a communication system that operates in a �peer-to-peer� fashion than a �client server� fashion for some reasons. First, the client server type communication system tends to be complicated. Second, the place where the conference is held is not restricted in the peer-to-peer type communication system, that is, the conference can be held even at the place where the communication system cannot be connected to any server. Third, some expenses such as the server installation cost, the administrator personnel cost, and the management cost can be neglected in the peer-to-peer type communication system.
SUMMARY OF THE INVENTION It is a general object of the present invention to provide a data communication system, a data communication method, a data communication program and a recording medium in which the above-mentioned problems are eliminated.
BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 is a schematic diagram illustrating a data structure of an encapsulated document according to a first embodiment of the present invention;
Some extended program 112 are added corresponding to information types in the encapsulated document 101. As is shown in FIG. 5, various extended programs 112 are prepared in accordance with types of display media. For instance, if the digital information file in the encapsulated document 101 comprises only the text information 103, �Text Panel� program 112 a together with the fundamental program 111 is prepared as the extended program 112 in the encapsulated document 101. Also, if the digital information file comprises the media information 104 for representing a still image or a moving image, �Image Panel� program 112 b, �Movie Panel� program 112 ac and �3D Panel� program 112 d are prepared as the extended program 112 in the encapsulated document 101.
FIG. 7 is a view illustrating a display example of the encapsulated document 101 described by using the XML shown in FIG. 6. Tags <DOCUMENT> and </DOCUMENT> are placed at the head and the tail of a document. Information regarding the structure of the document is described between the two tags. Tags <TEXT> and <TEXT/> are used to display a document title at the top of the document. If only text information is described between the tags, that is, if there is no special attribute information between the tags, the text information is displayed as the plain text. The XML description in FIG. 6 has the tag <TEXT FILE=�BODY.TEXT�/> at the next line. The tag is used to read the text file �BODY.TEXT� and display the contents thereof. Furthermore, the-image tag at the next line is used to read the still image file �IMAGE.JPG� and display contents thereof at the position and the size prescribed by the image tag. Namely, the �X�-�Y� coordinate (100, 10) is set as the origin where the image should be displayed, and �WIDTH� and �HEIGHT� prescribe the size of the image to be displayed.
There are various user's manipulations such as clicking of the mouse 11 and an input through the keyboard 10. In the clicking of the mouse 11, an individual extended program 112 determines whether or not a position where the mouse 11 is clicked is within a display area occupied by the extended program 112 and then performs an operation corresponding to the clicking an the display area if the clicked position is in the occupied area. In the input through the keyboard 10, an individual extended program 112 determines whether or not a cursor position of the keyboard 10, which is not illustrated, is within a display area occupied by the extended program 112 and then performs an operation corresponding to the cursor position if the cursor position is in the occupied area. As is shown in FIG. 14, for instance, when three types of digital information PRG 1, PRG 2 and PRG 3 are displayed in a document and a user clicks the mouse 11 on the position designated by the sign �X�, the extended program PRG 2 corresponding to the position detects the clicking of the mouse 11 and performs an operation corresponding to the clicking.
For instance, the Java has API (Applications Programming Interface) for sending and receiving data. In detail, the Java has the API �ServerSocket� for receiving a request as a receiver socket and the API �Socket� for establishing a connection. For a connection request received via the network interface 8, the �ServerSocket� uses the method �accept( )� to accept the connection request. Then, the connection between two computers 1 in question is established via the network interfaces 8 of the computers 1 by using the API �Socket�. As a result, it becomes possible for the computers 1 to accept data. Here, if the API �Socket� is not opened, data are not communicated (the message �Socket error� is returned.). Thus, in the Java, the connection type sending and receiving part 22 can be easily implemented by using methods �getOutputStream( )� and �getInputStream( )� of the APIs �ServerSocket� and �Socket�.
Also, the Java has the APIs �DatagramSocket� or �MulticastSocket� (�MulticastSocket� is inherited from �DatagramSocket�.) corresponding to the UDP for the multicast. The APIs �DatagramSocket� and �MulticastSocket� have a method �send ( )�, and the method �send( )� can send data via the network interface 8 regardless of the condition of a receiver computer. Thus, in the Java, the multicast sending part 20 can be easily implemented by using the method �send ( )� of the API �MulticastSocket� (�DatagramSocket�), and the multicast receiving part 21 can be easily implemented by using a method �receive( )� of the API �MulticastSocket� (�DatagramSocket�).
FIG. 18 shows an example of contents of the request packet and the receiver response packet. In this example, the request packet and the receiver response packet comprise a process request ID a, a network address (IP address) b, a host name c, a title d, sending time e, a sequential number f, and a user's name g. The process request ID is prescribed in advance and is used to identify a content type of the packet. For instance, the process request ID of a request packet represents packet contents such as �a request to send a receiver response packet�. The multicast receiving part 21 or the connection type sending and receiving part 22 reads the process request ID and then issues a process instruction corresponding to the process request ID.
The network address and the host name are a network address and a host name of a sender of the packet (host A in FIG. 17), respectively. The title is a file name in the document in question or a document title. The sending time is time when the packet is sent. The sequential number is attached when the packet is sent in the multicast. For instance, the sequential number has �2� if the packet has been multicast two times.
The individual documents use the connection type sending and receiving parts 22 to reply the determination results (�TRUE� or �FALSE�) as receiver response packets to the sender host A.
The host A receives the receiver response packets through the connection type sending and receiving part 22 of the host A. If the receiver response packet has �TRUE�, the host A sets the receiver response flag in FIG. 24. If the receiver response packet has �FALSE�, the host A fetches the sending instruction content corresponding to the sequential number and obtains the sending instruction. Then, the host A resends the data.
In the case where the data are resent, the host A uses the connection type sending and receiving part 22 to resend the data to only the host that has replied the receiving response packet having �FALSE� under the data communication process according to the first embodiment.
The first special case of the data communication process handles a situation where data are sent to a host located on a communication path whose communication condition is not satisfactory. As mentioned above, once a communication is established, the multicast sending part 20 is basically responsible to multicast data. However, when the data are sent to a host on a communication path whose communication condition is not satisfactory, the connection type sending and receiving part 22 may be used to send the data. The communication availability table shown in FIG. 24 is used to determine the communication condition. Furthermore, as is shown in FIG. 27, a condition flag f7 is added to the communication availability table. Initially, the condition flag f7 has �TRUE�. In order to determine the communication condition, the communication availability table is examined for each communication. For instance, if there is a host whose receiver response flag f4 remains �FALSE� more than or equal to N times, the condition flag f7 of the host is set to �FALSE�. When a user instructs the user's host to multicast data, the host examines the condition flags f7 of the receiver hosts. If a host has the condition flag �FALSE�, the sender host uses the more reliable connection type sending and receiving part 22 to send the data to the host having �FALSE� in the condition flag f7. FIG. 27 shows an example where the condition flag f7 of the host B is set to �FALSE� due to the fact that the host B has the receiver response flag f4 �FALSE� once.
A description will now be given, with reference to FIG. 36, of a data communication method according to the second embodiment of the present invention wherein those parts that have been described with respect to the first embodiment are referred to the same numerals and the description thereof will be omitted. According to the first embodiment, when data are communicated, the connection type sending and receiving part 22 resends the data to only hosts from which the receiver host has received the receiver response packets being �FALSE�. The second embodiment differs from the first embodiment only in that the multicast sending part 20 is used to resend the data.
The host A is assumed to receive a receiver response packet being �FALSE� from a host, which indicates that the host does not receive data, and resend the same data. In this case, the host A uses the multicast sending part 20 to send the data again under the data communication method according to the second embodiment.
Here, such data receiving information comprises the following three items: a sender host, a sequential number, and data contents. The receiver host maintains the data receiving information. For instance, the host C is supposed to maintain the data receiving information shown in FIG. 36. When the host B does not successfully receive data from the host A, the multicast sending part 20 of the sender host A resends the data �host A: sequential number 3� to the successful receiver host C as well as the unsuccessful receiver host B under the data communication method according to the second embodiment. When the host C receives the data, the host C discards the data with reference to the data receiving information. If the host C receives the data �host B: sequential number 2�, the host C fetches the data because the data receiving information of the host C does not include the data. Here, hosts do not have to maintain the entire data receiving information that the hosts have received before. The hosts may maintain the most recent data receiving information. Also, the hosts may maintain the data.
FIG. 37 is a flowchart of the procedure of the data communication process according to the third embodiment. As is shown in FIG. 37, if a user instructs the host A to multicast data after establishment of communications (step S51), the document A that is driven in the host A creates a communication availability table as shown in FIG. 24 in the RAM 4 or the HDD 5. For each of the hosts (host B, host C and host D), the value �n�, which indicates the number of times when the multicast has been performed, is set to the sequential number f3 and the value �FALSE� is also set to the receiver response flag f4 (step S52). In addition, for instance, the sequential number f5 and the sending instruction f6 as shown in FIG. 25 are registered.
If the host A accepts the receiver response packet within the predetermined time period, the host A sets the receiver response flag f4 in the communication availability table for the host to the value �TRUE�. Here, the receiver response packet has the same sequential number as the received data. As a result, the receiver response flag f4 remains �FALSE� for hosts from which the host A could not receive the receiver response. Based upon the sequential number, it is possible to comprehend information for determining what data arrive at which host. If there is a host for which the receiver response flag f4 remains �FALSE�, the host A can conclude that the host A has not received the receiver response from the host yet because of some troubles.
When the host A waits over the predetermined time period, the host A examines the receiver response flag f4 of the sequential number �n� for each of the hosts (step S55).
If there is a host for which the receiver response flag f4 is �TRUE� (step S56: N), it is determined that the data are successfully received by the host. On the other hand, if there is a host for which the receiver response flag f4 is �FALSE� (step S56: Y), the host A obtains a sending instruction of the sending instruction f6 based on the sequential number f5 (step S57) and then uses the connection type sending and receiving part 22 to resend the data to the host (step S58).
The steps S55 through S58 are repeated until all the hosts have the receiver response flags f4 �TRUE� for the sequential number �n� (step S59: N).
Patent CitationsCited PatentFiling datePublication dateApplicantTitleUS4947202Jul 6, 1989Aug 7, 1990Ricoh Company, Ltd.Distance measuring apparatus of a cameraUS5069543Feb 22, 1990Dec 3, 1991Ricoh Company, Ltd.Apparatus for measuring distances at many pointsUS5572678 *Jan 25, 1993Nov 5, 1996Hitachi Microcomputer System, Ltd.System for sending frames from sender to receiver using connectionless protocol and receiving acknowledging frame and retransmission request frame from receiver using connection oriented protocolUS5594872 *Apr 26, 1994Jan 14, 1997Hitachi, Ltd.Method of communicating messages in a distributed processing systemUS5619301Apr 15, 1996Apr 8, 1997Ricoh Company, Ltd.Detector for detecting focusing state or distance of photographed objectUS5760896Jun 10, 1996Jun 2, 1998Ricoh Company, Ltd.Distance measuring deviceUS6138144 *Jun 24, 1997Oct 24, 2000At&T Corp.Method for managing multicast addresses for transmitting and receiving multimedia conferencing information on an internet protocol (IP) network implemented over an ATM networkUS6151696 *Jan 23, 1998Nov 21, 2000Starburst Communications CorporationData transmissionUS6173314 *Dec 8, 1997Jan 9, 2001Nec CorporationApplication sharing system with user managed address for conferencingUS6209004 *Aug 28, 1996Mar 27, 2001Taylor Microtechnology Inc.Method and system for generating and distributing document sets using a relational databaseUS6404745 *Aug 12, 1999Jun 11, 2002Ezenia! Inc.Method and apparatus for centralized multipoint conferencing in a packet networkUS6415327 *Jan 24, 2000Jul 2, 2002Microsoft CorporationAutomatic protocol rollover in streaming multimedia data delivery systemsUS6426773Mar 27, 1998Jul 30, 2002Ricoh Company, Ltd.Image pickup device including an image pickup unit which is displaced relative to an object to be imagedUS6466550 *Nov 11, 1998Oct 15, 2002Cisco Technology, Inc.Distributed conferencing system utilizing data networksUS6509925 *Jan 27, 2000Jan 21, 2003International Business Machines CorporationConferencing systemUS6577599 *Jun 30, 1999Jun 10, 2003Sun Microsystems, Inc.Small-scale reliable multicastingUS6832367 *Mar 6, 2000Dec 14, 2004International Business Machines CorporationMethod and system for recording and replaying the execution of distributed java programsUS6990513 *Jun 22, 2001Jan 24, 2006Microsoft CorporationDistributed computing services platformUS7139813 *Nov 1, 1999Nov 21, 2006Nokia Networks OyTimedependent hyperlink system in videocontentUS7191241 *Sep 27, 2002Mar 13, 2007Alacritech, Inc.Fast-path apparatus for receiving data corresponding to a TCP connectionUS7444438 *Aug 17, 2006Oct 28, 2008Intel CorporationMethod and architecture to support interaction between a host computer and remote devicesUS7466707 *Mar 21, 2005Dec 16, 2008Sony CorporationTransmitter, communication system, and communication methodUS20020191594 *Aug 13, 2001Dec 19, 2002Tomoaki ItohTransmitting/receiving method and device thereforUS20030005054 *Jun 28, 2001Jan 2, 2003Hani El-GebalyDistributed multipoint conferencingUS20030014391 *Mar 5, 2001Jan 16, 2003Evans Paul AData distributionUS20030182446Feb 26, 2003Sep 25, 2003Masami KoideData communication method, data communication system, data communication program and recording mediumUS20050071459 *Sep 26, 2003Mar 31, 2005Jose Costa-RequenaSystem, apparatus, and method for providing media session descriptorsUS20050141507 *Feb 1, 2005Jun 30, 2005Placeware, Inc.Method and apparatus for automatically determining an appropriate transmission method in a networkJP2000022687A Title not availableJPH1117713A Title not availableJPH11161622A Title not available* Cited by examinerNon-Patent CitationsReference1M. Handley, et al., "SIP: Session Initiation Protocol", Network Working Group, Mar. 1999, 8 pages.2U.S. Appl. No. 09/329,341, filed Jun. 10, 1999, Suzuki.3U.S. Appl. No. 10/183,613, filed Jun. 28, 2002, Suzuki et al.4U.S. Appl. No. 10/372,960, filed Feb. 26, 2003, Koide et al.5U.S. Appl. No. 10/743,092, filed Dec. 23, 2003, Suzuki et al.6U.S. Appl. No. 11/495,669, filed Jul. 31, 2006, Mori, et al.7U.S. Appl. No. 11/580,128, filed Oct. 13, 2006, Suzuki, et al.Referenced byCiting PatentFiling datePublication dateApplicantTitleUS8171275 *Jan 14, 2008May 1, 2012Bally Gaming, Inc.ROM BIOS based trusted encrypted operating system* Cited by examinerClassifications U.S. Classification709/238International ClassificationG06F13/00, H04L29/08, G06F15/173, H04L12/56, H04L12/18Cooperative ClassificationH04L67/1048, H04L67/1068, H04L67/104, H04L67/1042, H04L12/1868, H04L12/1818, H04L12/1827European ClassificationH04L12/18R1, H04L29/08N9PLegal EventsDateCodeEventDescriptionOct 1, 2012FPAYFee paymentYear of fee payment: 4Apr 17, 2003ASAssignmentOwner name: RICOH COMPANY, LTD., JAPANFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:KOIDE, MASAMI;SUZUKI, AKIRA;REEL/FRAME:013970/0312Effective date: 20030207RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services©2012 Google