Title of Invention	"COMMUNICATION PROCESS IN A SET OF DISTRIBUED SYSTEMS VIA AT LEAST OE INTERNET TYPE NETWORK AND SYSTEM THEREFOR"
Abstract	The invention relates to a communication process via an internet network that comprises distributed systems (S1) Each system (S1) is connected to the network (SRX) via a standard interface module (10), standard software layers (12, 13) comprising a stack of addresses and protocols, and hosts software entities (SVA, SVB), The latter and the systems (S1) are provided with a network address in a virtual subnetwork to which the system itself (S1) and said software entities (SVA, SVB) are connected via a specific interface module (11, 20, 30) and specific software layers (21-22, 31-32) comprising a stack of addresses and protocols. The addresses and names of the systems (S1) and of the software entities (SVA, SVB) connected to the virtual networks (SVNY) are stored in a domain name directory (DNS1), making it possible to directly address one of the software entities (SVA, SVB)

Title of Invention

"COMMUNICATION PROCESS IN A SET OF DISTRIBUED SYSTEMS VIA AT LEAST OE INTERNET TYPE NETWORK AND SYSTEM THEREFOR"

Abstract

The invention relates to a communication process via an internet network that comprises distributed systems (S1) Each system (S1) is connected to the network (SRX) via a standard interface module (10), standard software layers (12, 13) comprising a stack of addresses and protocols, and hosts software entities (SVA, SVB), The latter and the systems (S1) are provided with a network address in a virtual subnetwork to which the system itself (S1) and said software entities (SVA, SVB) are connected via a specific interface module (11, 20, 30) and specific software layers (21-22, 31-32) comprising a stack of addresses and protocols. The addresses and names of the systems (S1) and of the software entities (SVA, SVB) connected to the virtual networks (SVNY) are stored in a domain name directory (DNS1), making it possible to directly address one of the software entities (SVA, SVB)

Full Text	-1- A PROCESS OF COMMUNICATION IN A SET OF DISTRIBUTED SYSTEMS VIA AT LEAST ONE INTERNET TYPE NETWORK AND SYSTEM THEREFOR The present invention relates to a process of communication in a set of distributed systems via at least one internet type network and system therefor. More particularly, the invention relates to the naming, the addressing, and the routing of information between the distributed systems, via one or more networks or subnetworks using internet technology. Within the scope of the present invention, the term "internet" should be understood in its most general sense. It specifically includes, in addition to the "Internet" per se, private corporate networks or the like, known as "intranets," and the networks that extend them to the outside, known as "extranets." It is also useful, for purposes of clarity, to review several definitions used in the description of the present invention. Hereinafter, a unit, a data processing machine, or more generally, a platform, using an operating system ("OS") will be called a "system." These systems are connected to one another by one or more networks or subnetworks, at least some of which use internet technology, in the sense mentioned above. Hereinafter, the terms "networks" and "subnetworks" will be used interchangeably. These systems host "servers." A server is generally defined as being software or a software entity that provides a given service (for example, file transfer software). In internet technology, so-called "IP" addresses are used. An address of this type is structured and comprises a subnetwork address, called a prefix, and an address of an entity in this subnetwork. Referring again to a server, it is addressable according to the prior art by means of an IP address as just defined and a port number, which will be designated P,, with i being an arbitrary subscript. This port number typically comprises two bytes and makes it possible to reach the server i in the system. In summary, if a system with the arbitrary subscript 0 is referenced So, and is associated with an IP address notated "X1 Xo", this means that this system So is connected to the subnetwork with the prefix X, with Xo as its address in this subnetwork A system can naturally be connected to several subnetworks. In this case, it has as many IP addresses as there are subnetworks Although the invention applies to all sorts of existing applications or services, it applies more particularly to distributed systems using "object" technology and to communications of the "client-server" type To explain the concept, without in any way limiting its scope, the following will keep to this preferred context of the invention, unless stated otherwise In other words, this particular technique applies to the exchanges of messages between client objects and server objects, which objects can be distributed throughout the entire system As is well known, systems connected to one or more networks or subnetworks are grouped into domains In the past, the networks and the systems were dissociated, and each domain used its own mechanisms for naming and addressing entities as well as for routing information in the networks and systems. Moreover, the mechanisms were not unified within the same network or system domain A first simplification occurred, with respect to networks, with the emergence of internet As for the systems themselves, the degree of simplification is generally very low. However, there have been a few attempts at simplification. For example, with respect to address directories, it is possible to use the access method known by the acronym "LDAP" ("Lightweight Directory Access Protocol") and the architecture that conforms to the "X500" standard. In addition, services such as "DNS" ("Domain Name Server") are beginning to be integrated into operating systems ("OS") or into "middleware." However, there is still a big difference between the "network" approach and the "system" approach In summary, it is clear that in the prior art, the systems, subsystems, services and software applications normally use specific solutions for the naming, addressing and routing of information. This situation is not without its drawbacks, and several of these will be discussed. First of all, the multiplicity of solutions makes the process for configuring the components listed above very complex. The configurations are normally static However, as noted, there is a trend toward using directories of the "X500" type for the system objects: the users, the resources, the services and the applications. Nevertheless, the network objects, which are managed by the internet domain name servers ("DNS"), are still excluded and are not integrated with the system objects. It follows that when a client interacts with a server, specific addressing and name resolution services are used For example, naming services like those known by the name "CORBA" (defined by the "Object Management Group" consortium) may be cited. These services use very different mechanisms. Other services are known, for example the naming service of the "DCE" ("OSF" in a distributed environment), or of "TUXEDO" (distributed transaction service known in the "UNIX" environment, "TUXEDO" and "UNIX" being registered trademarks). In general, clients that address a remote entity managed by a system, service or application invoke a name service This requires the name of the network and the network address of the system that contains the entity to be reached. The drawbacks inherent in these solutions are the following a multiplicity of naming services, directories, and tables of correspondences between network and system addresses, the complexity of the configuration processes, and above all, the need for the client (or user) to know which system (i.e. which machine) contains the object addressed, or more generally, the entity addressed. The processes according to the prior art therefore have numerous drawbacks. Furthermore, it may be added that they do not meet the current needs, or at least meet them inadequately The most important needs are listed below First of all, as has been noted, the configuration is most often static. The current need is to move toward "zero administration," based on an automatic and dynamic configuration. A second need relates to portability. An object, or more generally an entity, belonging to a "DNS" domain must be able to migrate, i.e., to leave its domain, while remaining addressable as though it had stayed in its domain. A third need, which goes hand-in-hand with the second, is that the servers must be independent from the host platforms. This setup allows unlimited migration. A fourth need relates to security, in the broadest sense of this concept, authentication, access control, integrity and confidentiality of the exchanges Generally, this is called the "AIC" concept - for "Availability - Integrity -Confidentiality " These requirements must be met from end to end between, for example, the client object and the server object, i.e , a software entity, and not just during the passage through the network or networks, i.e , between physical machines A fifth need relates to the compatibility, or coexistence, between the various internet protocols, especially between the widely used "IPV4" version and the more recent "IPV6" version, this version being a subset of the "IPNG" (Internet Protocol New Generation") standard currently being implemented. However, it must be noted that an address conforming to the IPV4 protocol has only four bytes, or 232 theoretical addresses, actually far fewer because of the structural hierarchy (particularly the presence of a prefix). Projections into the future have shown that, given the predictable growth of the Internet, a real shortage of addresses should occur during the period from 2005 to 2011 Also, since 1995, recommendations for the adoption of a new protocol, IPV6, have been published ("Internet Engineering Task Force" and "IPng" work groups). An address conforming to this IPV6 protocol comprises sixteen bytes, which allows for a much larger address space, even if not all oF the addresses are actually usable, as in the case of the IPV4 protocol In effect, this has been calculated to represent 6.65 x 1023 network addresses per square meter of the surface of the planet. A more detailed description of this protocol may be found in the in the book by A. Thomas, "IPng and the TCP/IP protocols," published by Wiley Computer Publishing, 1996 The process according to the invention further multiplies the need for numbers of distinct addresses, as will be shown. For all of these reasons, it is preferable to use the IPV6 protocol within the scope of the invention. Consequently, the object of the invention is to eliminate the drawbacks of the prior art, while meeting the current needs, some of which have been mentioned, without significantly increasing costs, while possibly even obtaining a reduction of these costs. -4A- Accordingly, the present invention provides a process of communication in a set of distributed systems via at least one internet type network, said set being divided into at least one domain comprising systems addressable via said network by means of a first series of internet type addresses stored in a domain name directory and each system being connected to said network via a standard interface module and having standard software layers comprising a stack of addresses of the first series and internet type communication protocols, and each system hosting at least one software entity, said process comprising the steps of providing said software entities and said systems with an internet type address of a second series , configuring each system into at least one system virtual network to which the system itself and said software entities are connected via specific interface modules and specific software layers comprising a stack of addresses of the second series and internet type communication protocols , and storing said addresses and names of the systems and the software entities connected to said system virtual networks in said domain directory, such that any of said software entities hosted in any of said systems may be directly addressed from anywhere is said set of distributed systems using the internet type address of the second series or the names of the software entities. The present invention also provides a communication system in a set of distributed systems via at least one internet type network, said set being divided into at least one domain comprising systems addressable via said network by a first series of internet type addresses stored in a domain name directory and each system being connected to said network via an interface module and having software layers comprising a stack of addresses of the first series and internet type communication protocols, and each system hosting at least one software entity, said communication system being characterized in that said software entities and said systems are each provided with an internet type address of a second series, each system being configured into at last one system virtual network to which the system itself and said software entities are connected via specific interface modules and specific software layers comprising a stack of addresses of the second series and internet type communication protocols, and means for storing said addresses and names of the systems and software entities connected to said system virlual networks in said domain directory, such that any of said software entities hosted in any of said systems may be directly addressed from anywhere in said set of distributed systems using the internet type address of the second series or the names of the software entities. To this end, the systems, accepting what has been given, are considered to be virtual networks, which hereinafter will be called "system virtual networks" or "SVN" In other words, the software entities, for example software objects in a preferred embodiment, become directly addressable in a system This system constitutes a node of the virtual network "SVN" and also a node of the "real" network, i e , the Internet, intranet or extranet The system acts as a gateway that interconnects the nodes of the virtual network "SVN" to the aforementioned "real" network In a preferred variant of the invention, the process also provides a dynamic, i.e , automatic, configuration capability. To do this, it uses the above-mentioned IPV6 protocol The latter characteristic also offers the capability to meet certain additional requirements, such as portability and/or security. The physical and logical objects, or more generally the physical and logical entities, whether they are of the system or the network type, i e., the clients, servers, systems, gateways, routers, etc , are at the same address level Common mechanisms are used for the naming, the addressing, and the name resolution and routing services. When a client establishes a connection with a software server that, in a preferred variant of embodiment, is an object container, there is no longer a need to also provide the name of the system (i.e., the machine and its services) that contains this server Hence, the subject of the invention is a communication process in a set of distributed systems via at least one internet type network, said set being divided into at least one domain comprising systems addressable via said network by means of a first series of internet type addresses stored in a domain name directory and each system being connected to said network via a standard interface module, standard software layers comprising a stack of addresses of the first series and internet type communication protocols, and hosting at least one software entity, characterized in that said software entities and said systems are each associated with an internet type address of a second series, in that each system is configured into a so-called system virtual network, to which the system itself and said software entities are connected via specific interface modules and specific software layers comprising a stack of addresses of the second series and internet type communication protocols, and in that said addresses and names of the systems and the software entities connected to said system virtual networks are stored in said domain directory, making it possible to directly address any of said software entities hosted in any of said systems Hence, it is clear that the process according to the invention provides many advantages, including the capability for a client (or more generally for a user) to directly address a server '(or more generally a software entity), and not the system that contains it. The invention will be more clearly understood and other characteristics and advantages will emerge from the reading of the following description in reference to the attached figures, in which - Figs 1a through 1c illustrate an architecture of a distributed system in an internet type network according to the prior art, - Fig. 2 schematically illustrates the process according to the invention; - Figs 3 and 4 illustrate the architecture of a system according to the process of the invention, - Fig. 5 schematically illustrates a communication process in a two-protocol system, - and Fig 6 illustrates the adaptation of the process according to the invention to a clustered system architecture. Before describing the process according to the invention, it is first necessary to review the configuration of a system 1 according to the prior art and its chief characteristics, in reference to Figs. 1a through 1c. First of all, let us consider an isolated system, referenced So, connected to an internet type subnetwork SRX, with the prefix X, as illustrated more particularly by Fig. 1a. Let us also assume that it hosts two servers SV01 and SV02, i.e. two software objects, or more generally two software entities. The system So has an IP address in the subnetwork SRX given by the relation @IP:X, Xo Each server, SV01 or SV02, is identified by an IP address and a port number, P01 OR P02. which are: - for the server SV01- X, Xo, P01; - for the server SV02: X, Xo, P02 The system So is connected to the subnetwork SRX via an interface I0, which will be described in detail below, and which comprises various logical layers: stacks of IP addresses, communication protocols Only this interface knows the port numbers Po, and P02 Therefore, it is easy to see that according to the prior art, when wishing to address one of the servers SV01 of SV02 from outside the system So, it is absolutely necessary to know the IP address of this system, i e , the address @IP:X Xo. Fig 1b illustrates, more generally, a set 1 of systems connected via a subnetwork SRX, again in a configuration according to the prior art In Fig. 1b, it is assumed that the set 1 constitutes one and only one domain D1 It is also assumed that the system 1 comprises q clients, referenced Cl1 through Clq, and n machines, i e., systems, referenced S1 through Sn Each system comprises a given number of servers, for example m servers in the system S1, referenced SV11 through SV1m, and p servers in the system Sn, referenced SVn1 through SVnp. Each system is provided with one or more so-called IP addresses. The exchanges of information, i.e , of messages, take place using the "TCP-IP" protocol between the clients CI1 through CLq, and the systems S1 through Sn, via the internet type subnetwork SRX The domain D1 also comprises a domain name server DNS, that stores a directory of IP addresses. Finally, each system S1 through Sn comprises an interface, I, through In, with the subnetwork SRX, which stores a stack of IP addresses associated with each system and a routing table that makes it possible to transfer a received message to another system via the subnetwork SRX Within a system, for example the system S11 a particular server, for example the server SV11, is identified by a port number, as noted in connection with Fig. 1a. When a client, for example Cl11 wants to address a particular server, for example the aforementioned server SV11, it is necessary for it to know the name of the system that is hosting it, in this case the system S1 The directory present in the server DNS1 establishes a correlation between the name and the IP address of the system S1 containing the server SV11 The client CI1, then addresses the system S1 using the IP address it receives from the domain name server DNS, As shown in Fig. 1 c, the addressing schema is very similar to the one just described when the set of systems, referenced V, comprises several domains, for example two domains D1 and D2 Each domain D1 and D2 comprises its own specific domain address server DNS, and DNS2, and a network or subnetwork SRX1 and SRX2, respectively The interconnections between subnetworks take place via an interdomain network or subnetwork SRld, and a server, also interdomain, DNSld, is provided If the client CI1 in the domain D1 no longer wishes to address a server (not represented) comprised in the system Sn of the domain D1, but a server (not represented) comprised in the system S21 of the domain D2, it will be provided with the address of the destination domain D2 by the server DNS,d, then, in the domain D2, it will be provided with the address of the destination system S21 by the server DNS2. Here again, it is necessary to know the name of the system hosting the server addressed, in this case the name of the system S21 Before describing the process of the invention, it is also necessary to briefly review the mechanisms used in the domain servers, for example DNS, or DNS2, and those used for routing The main function of domain name server, or "DNS," is to establish a correspondence between symbolic names assigned to systems (and more generally to entities, as explained above, within the scope of the process according to the invention), and IP addresses. A domain name server operates hierarchically It is constituted by domains, for example D1 or D2 (Fig 1c), that allow the names to be divided into functional categories, for example associated with a business, with a country, etc This last characteristic, at the "top" of the aforementioned hierarchy (first level domains), is represented by a suffix such as "com," "edu," "gov," "int," "mil," "net," "org," "fr," etc., separated from the rest of the name by a period. The rest of the domain name can in turn be divided into partial domain names separated by periods (lower levels). For example, a given business service could be represented by a symbolic name such as "servicei.xxx com", in which "xxx" would represent the name of a company and "servicel" would represent a particular service A search for this name makes it possible to focus on the domain name servers "DNS" assigned to " com" If a name of the aforementioned type is being searched for, it is the domain name server "DNS" assigned to " xxx", whose superior server is "com", that will process the request This corresponds to the schema implicitly described in connection with Fig 1c. More precisely, for example, in the domain name server DNS, of the domain D1 that contains the system S11, there is an entry of the type "sys11 -> X1,Xn", X1 being the prefix of the subnetwork SRX1, and X11 the address of the system S11 in the subnetwork SRX1 Within a system, an initial configuration operation makes it possible to allocate it an address using a specific command. For example, in a "UNIX" (registered trademark) environment, the command "IFCONFIG" makes it possible to configure the network interfaces, for example I, through ln (Fig. 1 b), of a stack of internet protocols This configuration operation creates an entry in a table known by the acronym "IFNET". This table contains a description of the interface, the IP address, status information and pointers to the "drivers" associated with the interface. After this operation, the system S11 (in the example) has the address X,X11 as its IP address Referring again to Fig. 1a, the routing allows access to a subnetwork other than the subnetwork SRX, for example a network SRZ (not represented), Z being the prefix of this network, this access takes place through the system So, which constitutes an X-Z gateway. The system S11 is a terminal and the IP routing level can be deactivated Within an internet network, the routers use databases that make it possible to switch the packets of informational data There are many known routing protocols such as "RIP" ("Routing Information Protocol") or "OSFP" ("Open Shortest Path First"). These protocols allow the routers to exchange routing information. For example, if the "RIP" protocol is used, a given system communicates the addresses of its prefixes (i.e., the addresses of the subnetworks to which it is connected) to all of its neighbors. Thus, step by step, the routes that allow the packets to be routed are established. It is then necessary to declare "drivers," and more precisely, two types of drivers' a network interface driver, called "nid", and a driver that corresponds to the electronic circuit board for interfacing with the network, called "ndd" (for "network device driver"). 10 The process according to the invention will now be described. Fig 2 very schematically illustrates the process for addressing servers according to the invention It is assumed in Fig 2, for purposes of simplification, that the set of systems, here referenced 2, is comprised within only one domain D1, associated with one domain name server DNS, and only one client Cl1 According to a first important characteristic of the invention, each "real" system (S1 through Sn of Fig 1b) is comparable to a virtual network SVN, through SVn represented by dotted lines in Fig 2 These networks will hereinafter be called "system virtual networks." According to a second important characteristic of the invention, the servers, for example SV11 through SV13, are each associated with an individual IP address. It follows that each server, for example the server SV11, i e., an object or a software entity, is directly addressable by a client, for example a client Cl11 and more generally a client CIx if the system 2 comprises several clients (x being arbitrary) In other words, a client no longer needs to know the name of the system hosting the server sought The directory of the server DNS, stores all of the IP addresses of the servers, for example the servers SV11 through SV13 of the system virtual network SVN1 It must be noted that, in a multidomain system, all the servers of a system virtual network belong to the same domain. According to a third important characteristic of the invention, the "real" systems or machines (S, through Sn of Fig 1b) which, in a configuration according to the prior art, constitute endpoint systems, become intermediate systems They constitute nodes of the virtual networks SVN, through SVNn, and also nodes of the "real" network, i.e the internet or intranet subnetwork SRX. The systems act as gateways that interconnect the nodes of the virtual networks SVN, through SVNn with the subnetwork SRX. Each system is also provided with an IP address Hence, a system virtual network SVN, associated with a system S1, may be represented as illustrated by Fig. 3. It is noted that the system S1 actually constitutes a node for the network Rx and that, seen from this network (i e., from the outside), it is associated with a first address IP,, with @IP1 'X.X1, X being the 11 prefix assigned to the subnetwork SRX and X1 the address of S, in the subnetwork it is assumed that the system virtual network SVNy is constituted by the two servers referenced SVA and SVB that it hosts and by the system S1 itself Seen from the system virtual network SVN11 the system S, is associated with a second address IP2l with @IP2 Y,Y1f Y being the prefix assigned to the system virtual network SVNY and Y, the address of S, in the network SVNY Likewise, the servers SA and SB are associated with two addresses IPA and !P8, respectively, with @IPA:Y,YA, and @IP2-Y,YB, YA and YB being the addresses of SVA and SVBt respectively, in the network SVNY. Fig. 4 illustrates in greater detail the architecture of the system S, according to the invention The "real" network Rx communicates with the system virtual network SVNY via a standard network interface module 10, known by the acronym "IFNET" (common to the prior art), a stack of system IP addresses 12, also standard, and an interface module 11 specific to the system virtual network, which, for the sake of analogy, will be called "IFSVN" In essence, the latter plays a role similar to the "IFNET" interface 10 The system also comprises a standard "TCP/UDP" protocol layer 13. Likewise, even though the servers SVA and SVB are physically located in the system S1f they are both provided with specific "IFSVN" interface modules, 20 and 30 respectively, stacks of IP addresses, 21 and 31 respectively, and "TCP/UDP" protocol layers, 22 and 32 respectively. The servers SVA and SV0 therefore communicate with the system virtual network SVNY through these two layers and through the specific interface modules In other words, the specific interface modules 11, 20 and 30 allow for a standard behavior of the IP level (level 12) of the system S, that contains the system virtual network SVNY They allow the routing of packets of information within the system S1 to the software servers SVA and SVB, which henceforth act like virtual endpoint systems of the system virtual network SVNY. 12 According to the invention, the allocation of IP addresses, whether they relate to the systems per se or more specifically to the software servers, takes place in a way that is intrinsically similar to the methods of the prior art For a given server, for exampfe SVA, i e , related to an object run in a system, for example the system S1 included in the domain D11 the directory of the server DNS, is updated This update can be performed manually or automatically, as will be explained below More precisely, an object or an entity uses two functions that are intrinsically known the allocation of a global address and the release of an address As indicated, the allocation of an address takes place in a way similar to the prior art, but with one major difference the system virtual networks are referenced in the domain name server with the entities that are connected to them, including the software servers Returning to the example of Fig 4, the domain name server DNX, stores the following entries" a/sys1 ->X,X, , b/sys2-> Y,Y1 , c/ serva -> Y,YA , d/servb-> Y,YB; the entries a/ and b/ being related to the addresses \P, and IP2, respectively, and the entries c/ and d/ being related to the addresses IPA and IP8, respectively It must be noted that sys1, sys2, serva and servb are symbolic names A server or service is therefore directly addressable. For example, if a company "xxx" has the domain name server DNS, and its superior domain name server is the server of "com", the service "serva" becomes addressable in the Internet by the name "serva.xxx com". Any client object, or more generally any user, can query its domain name server to request the IP address corresponding to this name The domain of the system that sent the request, given the structuring of the name (i.e., a notation that includes periods) transfers the request to its superior domain name server if it cannot handle it itself, and so on until a particular domain server is capable of addressing the request to the domain name server that will 13 handle the correspondence "symbolic name - IP address requested," for example the server DSN, The address releasing function releases an address previously allocated to an object For routing purposes, the system S1 is no longer an endpoint, but has become a gateway The IP routing level is necessarily activated In order for there to be correct routing between all of the systems of a network, no matter what its nature, it is also necessary to perform name resolution operations This function is the most important of those assigned to the protocol "ICMP" (for "Internet Control Message Protocol"). It consists in the discovery, for a given system, for example S,, of the neighbor systems that share the links to which it is connected. This operation takes place the first time a datagram is sent through the network SRX to a neighbor In effect, at this instant, the system S1 that wishes to send a datagram to one of its neighbors knows the IP address of the destination, but not its network address (for example an "Ethernet" (registered trademark) address, if it is a network of that type) In practical terms, this means that the system S1 must construct a table that establishes the correspondences between IP addresses and network addresses. To do this in local area networks, for example in networks of the aforementioned "Ethernet" type, the IPV4 protocol uses a protocol known by the term "ARP" (for "Address Resolution Protocol") and the IPV6 protocol uses a protocol known by the term "NDP" (for "Neighbor Discovery Protocol") For example, if the protocol "NDP" is used, the system S1 can know the network addresses of the other systems that share its links A given system uses a broadcast address to request from its neighbors, as a function of their IP addresses, their network addresses. In the case of the system virtual networks according to the invention, for example SVNY, the various users are the system S1 itself and the servers hosted by this system SVA and SVB Since they are located in the same place, the neighbor discovery described above is unnecessary. The protocols "ARP" or "NDP" are not invoked. The initial configuration operation must, in the case of the invention, be subdivided. For example, in the above-mentioned "UNIX" environment, the 14 command "IFCONFIG" is also used However, it is necessary to configure the interface to the subnetwork SRX, the interface to the system virtual network SVNY, and also to configure an address of the alias type for each server connected to this network In the example described, two addresses must be configured @IPA Y,YA and @PB:Y,YB As in the case of the prior art, it is necessary to declare "drivers," and more precisely, two types of drivers a network interface driver, called "nid," and a driver that corresponds to the electronic circuit board for interfacing with the network, called "ndd" (for "network device driver") Likewise, it is necessary to declare an interface driver for the system virtual network, for example SVNY This last driver is created (software development) in accordance with the rules for writing a standard interface driver "nid". It must be noted that the equivalent of the driver "ndd" is no longer necessary In fact, the "TCP/IP" layers necessarily comprise a driver called a "loopback" which, for the system virtual network SVNY, plays the role of the driver "ndd" for the subnetwork SRX The way in which data packets enter and leave the system S1 will now be described in greater detail If a data packet containing the indications "Y,YA" in its IP address arrives in the system S1, the latter consults the local address table It finds "Y,YA in the "IFNET" table 10 (an entry called an "alias") and considers the packet to have arrived at its destination and delivers it to the waiting application, i e , the server SVA, via the virtual network SVNY If a data packet is sent by a server, for example the server SVB, to a server SVn located outside the system virtual network SVNY, the system S1 acts as a "routing server," or gateway, and switches this packet to the network interface that corresponds to the subnetwork SRX If, on the other hand, a data packet is sent by a server, for example the server SVB, to a server located inside the system virtual network SVNY, for example the server SVA, the system S1 also acts as a router. It detects that the destination address corresponds to one of the local addresses. It executes a standard loop of the type known by the term "loopback" (mandatory in any stack of TCP/IP protocols, as indicated above) and transmits the packet to the server SVA. Hence, 15 the data packet does not leave the system S1 In particular, it does not pass through the subnetwork SRX. The process according to the invention offers many advantages and possibilities First of all, it must be noted that the process according to the invention is fully compatible with the internet protocol most commonly used to date, i e , the IPV4 protocol, alone or in combination with the new IPV6 protocol. Fig 5 illustrates, by way of example, the communication process between two system virtual networks SVNY and SVN2, comprised in two systems, S1 and S2 respectively It is assumed that the two systems have both IPV4 and IPV6 addresses. It is also assumed that the network SRX that connects the two systems S1 and S2 uses the IPV4 protocol The standard encapsulation mechanisms used by the IPV6 protocol allow the users of the systems S1 and S2 to interoperate by using IPV6 packets that are encapsulated into IPV4 packets as they pass through IPV4 networks, as is the case for the network Rx The two protocols can therefore coexist, and the IPV4 protocol can still theoretically be used alone within the scope of the invention However, it has been indicated that a shortage of addresses is predictable Moreover, given that according to one of the most important characteristics of the invention, the servers are also provided with an IP address, which contributes to increasing the need for addresses, it seems preferable to use the IPV6 protocol within the scope of the invention Secondly, in combination with the new IPV6 internet protocol, the process according to the invention allows for a dynamic configuration, the dynamic resolution of the names being achieved by the protocol known as "NDP" (for "Neighbor Discovery Protocol"). The dynamic allocation of IP addresses is followed by an update of the databases of the directory service, making the owner of the IP address capable of communicating with a network of the internet, intranet or extranet type. By way of example, a three-phase process, which makes an object or an entity dynamically addressable anywhere in a given domain, will be described in detail below 16 During phase 1, the object is run in a first system, for example the system S1 (Fig. 5), and the following steps are performed. - allocation of an IP address to the object; -the directory of the domain, for example DNS, of D,, that contains the system S1 is updated, - the object can then establish connections with other objects During phase 2, the object is transferred into another system, for example the system S2 (Fig. 5), and the following steps are performed - the object closes its active connections; - the object releases its IP address, - the directory DNS1 of D, is updated; - the object is transferred to the system S2 using a file transfer protocol. During phase 3, the object is run in the system S2 and the following steps are performed. - allocation of a new IP address to the object, - update of the directory DNS, of D1; - the object can again establish or accept connections. Third, the process according to the invention, again in combination with the IPV6 protocol, also allows for the portability of an object or an entity In fact, the IPV6 protocol offers the capability for this object to leave a domain, while remaining addressable as though it were still in the original domain. Fourth, the process according to the invention allows software objects or entities to fully benefit from the security techniques defined at the internet level These techniques are implemented using "firewalls" and the "IPSEC" protocol. They provide access control services (address filtering), authentication, integrity (signatures) and confidentiality (using encryption algorithms) In the prior art, the internet link does not connect the systems to one another. In other words, the link and the "IPSEC" protocol do not extend as far as the software applications, i.e., as far as the servers It is therefore common to provide additional secure software layers, well known by the acronym "SSL" (or "Secure Socket Layers") in the systems, which makes the links more complex, especially when each object or entity generally has its own specific security requirements. 17 The process according to the invention, through the concept of a new generation of "firewall" associated with each client and each server whose security must be ensured, simplifies the security of the systems, since the links extend all the way to the software objects or entities In fact, according to one of its chief characteristics, these software objects have their own IP addresses and are therefore directly addressable In addition to providing greater simplicity, the process also makes it possible to reduce the cost of the solutions The equivalent security techniques implemented in the middleware in the prior art, illustrated for example by the above-mentioned "SSL" layer, become unnecessary. Up to this point, each system has been considered to be autonomous Advantageously, the process according to the invention can-also be applied to systems in "clusters." In essence, the main purpose of such an architecture is to appear, seen from the outside, to be a single system or machine The process according to the invention makes it possible achieve this objective Fig 6 illustrates an architecture of this type The clustered machines M1 through Mx, x being the maximum number of machines, are interconnected through a local area network SRC. There is network equipment in this local area network the node N provided with an IP address, IPN in the network SRX Each machine, together with the servers it is hosting at a given instant, constitutes a virtual network SVNM1 through SVNMx, these networks being connected according to the process of the invention to the network SRXl to the local area network SRC by each system, and to the network SRX via the node N The standard IP mechanism organizes the routing of a packet addressing an object of a system virtual network to the node of the cluster that contains it, for example the server SVC in the system virtual network SVNM1 in the machine M1 For a remote client outside the cluster, the object addressed can be runTn any node of the cluster, in a way that is transparent for this client. In effect, there is no, longer any need to address a particular machine among the x machines. It is only necessary to address the desired object or entity, for example SVC This mode of operation allows high availability. If an object or a software entity of a system virtual network becomes unavailable due to a hardware or software failure of the system that is hosting it, the object can be restarted in 18 another node and the standard address resolution mechanisms will allow it to be reconfigured dynamically. To do this, it is simply necessary to implement the process according to the invention, in combination with the IPV6 protocol. In another operating mode, the object or entity can be duplicated in two or more of the machines constituting the cluster This redundancy can be provided for the same reasons as above (failure or malfunction) or in order to ensure availability, through rerouting, despite an overload of one or more machines (parallel operation). With the reading of the above, it is easy to see that the invention clearly achieves the objects set forth. The advantages offered by the invention are numerous Without redescribing them in detail, it is possible to summarize them as follows - simplification of the addressing, the name services and the associated protocols, for the network objects or entities as well as for the objects or entities of the systems (software or applications), - independence of the servers from the systems (machines); - dynamic configuration, which makes it possible to move toward "zero administration"; - portability of the software objects or entities, - network security services applied to the software objects or entities; - reduction of the costs of the solutions by reusing network services existing through middleware and applications; - and compatibility with current internet type architectures, as well as the utilization of standards. It should be clear, however, that the invention is not limited to just the exemplary embodiments explicitly described, specifically in relation to Figs. 2 through 5. -19-WE CLAIM : 1 A process of communication in a set of distributed systems via at least one internet type network, said set being divided into at least one domain comprising systems addressable via said network by means of a first series of internet type addresses stored in a domain name directory and each system being connected to said network via a standard interface module and having standard software layers comprising a stack of addresses of the first series and internet type communication protocols, and each system hosting at least one software entity, said process comprising the steps of: providing said software entities and said systems with an internet type address of a second series ; configuring each system into at least one system virtual network to which the system itself and said software entities are connected via specific interface modules and specific software layers comprising a stack of addresses of the second series and internet type communication protocols , and storing said addresses and names of the systems and the software entities connected to said system virtual networks in said domain directory, such that any of said software entities hosted in any of said systems may be directly addressed from anywhere is said set of distributed systems using the internet type address of the second series or the names of the software entities 2 A process as claimed in claim 1, wherein the process comprises the steps of allocating an address comprising a prefix and an identifier to each of said software entities for updating said domain name directory to record the names and addresses of these software entities , and releasing addresses so as to release an address previously allocated to a given software entity 3. A process as claimed in claim 2, wherein said addresses are established in conformity with an internet protocol -20- 4. A process as claimed in claim 3, wherein said address allocation is dynamic and wherein the dynamic address allocation comprises at least the following phases and steps : a phase for running said software entity in a first system, comprising steps for allocating an address in conformity with the internet protocol, updating said domain name directory and establishing and/or accepting connections via said internet type network ; a phase for transferring said software entity from said first system into a second system, comprising steps for closing active connections, releasing the internet type address of the software entity, updating said domain name directory ; and a phase for running said software entity in said second system, comprising steps for allocating a new address in conformity with the IPV6 internet protocol, updating said domain name directory, and establishing and/or accepting new connections via said internet type network. 5. A process as claimed in claim 4, wherein communication between said software entities take place in a client-server mode. 6 A process as claimed in claim 5, wherein said software entities are client objects or server objects 7 A process as claimed in claim 4, wherein at least one of said systems is constituted by a cluster of at least two machines connected to said network at a common node, and each machine forming one of said system virtual networks, said node is associated with an internet type address of said first series, making it possible to address a sofware entity hosted by any one of said machines by means of an internet type address of said second series -21- 8. A process as claimed in claim 7, wherein at least one of said software entities is duplicated in at least two of the machines of said cluster 9 A process as claimed in claim 7, wherein said software entities are connected by means of an internet link via said internet type network, in order to protect this link from end to end and firewalls are associated with said software entities. 10. A communication system in a set of distributed systems via at least one internet type network, said set being divided into at least one domain comprising systems addressable via said network by a first series of internet type addresses stored in a domain name directory and each system being connected to said network via an interface module and having software layers comprising a stack of addresses of the first series and internet type communication protocols, and each system hosting at least one software entity, said communication system being characterized in that said software entities and said systems are each provided with an internet type address of a second series, each system being configured into at last one system virtual network to which the system itself and said software entities are connected via specific interface modules and specific software layers comprising a stack of addresses of the second series and internet type communication protocols, and means for storing said addresses and names of the systems and software entities connected to said system virtual networks in said domain directory, such that any of said software entities hosted in any of said systems may be directly addressed from anywhere in said set of distributed systems using the internet type address of the second series or the names of the software entities. 11. A communication system as claimed in claim 10, comprising means for allocating an address comprising a prefix and an identifier to each of said software entities for updating said domain name directory to record the names and addresses of these software entities, and releasing addresses so as to release an address previously allocated to a given software entity. -22- 12 A communication system as claimed in claim 11, wherein said addresses are established in conformity with the internet protocol. 13. A communication system as claimed in claim 12, wherein said address allocation is dynamic, and wherein the dynamic address allocation comprises at least the following phases and steps : a phase for running said software entity in a first system, comprising steps for allocating an address in conformity with the internet protocol, updating said domain name directory, establishing and/or accepting connections via said internet type network ; a phase for transferring said software entity from said first system into a second system, comprising steps for closing active connections, releasing the internet type address of the software entity, updating said domain name directory ; and a phase for running said software entity in said second system, comprising steps for allocating a new address in conformity with the IPV6 internet protocol, updating said domain name directory, and establishing and/or accepting new connections via said internet type network 14 A communication system as claimed in claim 13, wherein communications between said software entities take place in the client server mode 15 A communication system as claimed in claim 13, wherein said software entities are clients objects or server objects. 16 A communication system as claimed in claim 13, wherein at least one of said systems is constituted by a cluster of at least two machines connected to said network at a common node and each machine forming one of said system virtual networks, said node being associated with an internet type address of said first series, such that a software entity hosted by anyone of said machines by means of an internet type address of said second series may be addressed. -23- 17. A communication system as claimed in claim 16, wherein at least one of said software entities is duplicated in at least two of the machines of said cluster. 18. A communication system as claimed in claim 16, comprising firewalls associated with a pair of said software entities and means connected by an internet link via said internet type network, in order to protect said link from end to end The invention relates to a communication process via an internet network that comprises distributed systems (S1) Each system (S1) is connected to the network (SRX) via a standard interface module (10), standard software layers (12, 13) comprising a stack of addresses and protocols, and hosts software entities (SVA, SVB), The latter and the systems (S1) are provided with a network address in a virtual subnetwork to which the system itself (S1) and said software entities (SVA, SVB) are connected via a specific interface module (11, 20, 30) and specific software layers (21-22, 31-32) comprising a stack of addresses and protocols. The addresses and names of the systems (S1) and of the software entities (SVA, SVB) connected to the virtual networks (SVNY) are stored in a domain name directory (DNS1), making it possible to directly address one of the software entities (SVA, SVB)

Full Text

-1-
A PROCESS OF COMMUNICATION IN A SET OF DISTRIBUTED
SYSTEMS VIA AT LEAST ONE INTERNET TYPE
NETWORK AND SYSTEM THEREFOR
The present invention relates to a process of communication in a set of distributed systems via at least one internet type network and system therefor.
More particularly, the invention relates to the naming, the addressing, and the routing of information between the distributed systems, via one or more networks or subnetworks using internet technology.
Within the scope of the present invention, the term "internet" should be understood in its most general sense. It specifically includes, in addition to the "Internet" per se, private corporate networks or the like, known as "intranets," and the networks that extend them to the outside, known as "extranets."
It is also useful, for purposes of clarity, to review several definitions used in the description of the present invention.
Hereinafter, a unit, a data processing machine, or more generally, a platform, using an operating system ("OS") will be called a "system." These systems are connected to one another by one or more networks or subnetworks, at least some of which use internet technology, in the sense mentioned above. Hereinafter, the terms "networks" and "subnetworks" will be used interchangeably.
These systems host "servers." A server is generally defined as being software or a software entity that provides a given service (for example, file transfer software).
In internet technology, so-called "IP" addresses are used. An address of this type is structured and comprises a subnetwork address, called a prefix, and an address of an entity in this subnetwork.
Referring again to a server, it is addressable according to the prior art by means of an IP address as just defined and a port number, which will be designated P,, with i being an arbitrary subscript. This port number typically comprises two bytes and makes it possible to reach the server i in the system.
In summary, if a system with the arbitrary subscript 0 is referenced So, and is associated with an IP address notated "X1 Xo", this means that this system So is connected to the subnetwork with the prefix X, with Xo as its address in this

subnetwork A system can naturally be connected to several subnetworks. In this case, it has as many IP addresses as there are subnetworks
Although the invention applies to all sorts of existing applications or services, it applies more particularly to distributed systems using "object" technology and to communications of the "client-server" type To explain the concept, without in any way limiting its scope, the following will keep to this preferred context of the invention, unless stated otherwise In other words, this particular technique applies to the exchanges of messages between client objects and server objects, which objects can be distributed throughout the entire system
As is well known, systems connected to one or more networks or subnetworks are grouped into domains
In the past, the networks and the systems were dissociated, and each domain used its own mechanisms for naming and addressing entities as well as for routing information in the networks and systems.
Moreover, the mechanisms were not unified within the same network or system domain A first simplification occurred, with respect to networks, with the emergence of internet
As for the systems themselves, the degree of simplification is generally very low. However, there have been a few attempts at simplification. For example, with respect to address directories, it is possible to use the access method known by the acronym "LDAP" ("Lightweight Directory Access Protocol") and the architecture that conforms to the "X500" standard. In addition, services such as "DNS" ("Domain Name Server") are beginning to be integrated into operating systems ("OS") or into "middleware." However, there is still a big difference between the "network" approach and the "system" approach
In summary, it is clear that in the prior art, the systems, subsystems, services and software applications normally use specific solutions for the naming, addressing and routing of information. This situation is not without its drawbacks, and several of these will be discussed.
First of all, the multiplicity of solutions makes the process for configuring the components listed above very complex.

The configurations are normally static However, as noted, there is a trend toward using directories of the "X500" type for the system objects: the users, the resources, the services and the applications. Nevertheless, the network objects, which are managed by the internet domain name servers ("DNS"), are still excluded and are not integrated with the system objects.
It follows that when a client interacts with a server, specific addressing and name resolution services are used For example, naming services like those known by the name "CORBA" (defined by the "Object Management Group" consortium) may be cited. These services use very different mechanisms. Other services are known, for example the naming service of the "DCE" ("OSF" in a distributed environment), or of "TUXEDO" (distributed transaction service known in the "UNIX" environment, "TUXEDO" and "UNIX" being registered trademarks).
In general, clients that address a remote entity managed by a system, service or application invoke a name service This requires the name of the network and the network address of the system that contains the entity to be reached.
The drawbacks inherent in these solutions are the following a multiplicity of naming services, directories, and tables of correspondences between network and system addresses, the complexity of the configuration processes, and above all, the need for the client (or user) to know which system (i.e. which machine) contains the object addressed, or more generally, the entity addressed.
The processes according to the prior art therefore have numerous drawbacks. Furthermore, it may be added that they do not meet the current needs, or at least meet them inadequately The most important needs are listed below First of all, as has been noted, the configuration is most often static. The current need is to move toward "zero administration," based on an automatic and dynamic configuration.
A second need relates to portability. An object, or more generally an entity, belonging to a "DNS" domain must be able to migrate, i.e., to leave its domain, while remaining addressable as though it had stayed in its domain.
A third need, which goes hand-in-hand with the second, is that the servers must be independent from the host platforms. This setup allows unlimited migration.

A fourth need relates to security, in the broadest sense of this concept, authentication, access control, integrity and confidentiality of the exchanges Generally, this is called the "AIC" concept - for "Availability - Integrity -Confidentiality " These requirements must be met from end to end between, for example, the client object and the server object, i.e , a software entity, and not just during the passage through the network or networks, i.e , between physical machines
A fifth need relates to the compatibility, or coexistence, between the various internet protocols, especially between the widely used "IPV4" version and the more recent "IPV6" version, this version being a subset of the "IPNG" (Internet Protocol New Generation") standard currently being implemented.
However, it must be noted that an address conforming to the IPV4 protocol has only four bytes, or 232 theoretical addresses, actually far fewer because of the structural hierarchy (particularly the presence of a prefix). Projections into the future have shown that, given the predictable growth of the Internet, a real shortage of addresses should occur during the period from 2005 to 2011 Also, since 1995, recommendations for the adoption of a new protocol, IPV6, have been published ("Internet Engineering Task Force" and "IPng" work groups). An address conforming to this IPV6 protocol comprises sixteen bytes, which allows for a much larger address space, even if not all oF the addresses are actually usable, as in the case of the IPV4 protocol In effect, this has been calculated to represent 6.65 x 1023 network addresses per square meter of the surface of the planet. A more detailed description of this protocol may be found in the in the book by A. Thomas, "IPng and the TCP/IP protocols," published by Wiley Computer Publishing, 1996
The process according to the invention further multiplies the need for numbers of distinct addresses, as will be shown. For all of these reasons, it is preferable to use the IPV6 protocol within the scope of the invention.
Consequently, the object of the invention is to eliminate the drawbacks of the prior art, while meeting the current needs, some of which have been mentioned, without significantly increasing costs, while possibly even obtaining a reduction of these costs.

-4A-
Accordingly, the present invention provides a process of communication in a set of distributed systems via at least one internet type network, said set being divided into at least one domain comprising systems addressable via said network by means of a first series of internet type addresses stored in a domain name directory and each system being connected to said network via a standard interface module and having standard software layers comprising a stack of addresses of the first series and internet type communication protocols, and each system hosting at least one software entity, said process comprising the steps of providing said software entities and said systems with an internet type address of a second series , configuring each system into at least one system virtual network to which the system itself and said software entities are connected via specific interface modules and specific software layers comprising a stack of addresses of the second series and internet type communication protocols , and storing said addresses and names of the systems and the software entities connected to said system virtual networks in said domain directory, such that any of said software entities hosted in any of said systems may be directly addressed from anywhere is said set of distributed systems using the internet type address of the second series or the names of the software entities.
The present invention also provides a communication system in a set of distributed systems via at least one internet type network, said set being divided into at least one domain comprising systems addressable via said network by a first series of internet type addresses stored in a domain name directory and each system being connected to said network via an interface module and having software layers comprising a stack of addresses of the first series and internet type communication protocols, and each system hosting at least one software entity, said communication system being characterized in that said software entities and said systems are each provided with an internet type address of a second series, each system being configured into at last one system virtual network to which the system itself and said software entities are connected via specific interface modules and specific software layers comprising a stack of addresses of the second series and internet type communication protocols, and means for storing said addresses and names of the systems and software entities connected to said system virlual networks in said domain directory, such that any of said software entities hosted in any of said systems may be directly addressed from anywhere in said set of distributed systems using the internet type address of the second series or the names of the software entities.

To this end, the systems, accepting what has been given, are considered to be virtual networks, which hereinafter will be called "system virtual networks" or "SVN" In other words, the software entities, for example software objects in a preferred embodiment, become directly addressable in a system This system constitutes a node of the virtual network "SVN" and also a node of the "real" network, i e , the Internet, intranet or extranet The system acts as a gateway that interconnects the nodes of the virtual network "SVN" to the aforementioned "real" network
In a preferred variant of the invention, the process also provides a dynamic, i.e , automatic, configuration capability. To do this, it uses the above-mentioned IPV6 protocol The latter characteristic also offers the capability to meet certain additional requirements, such as portability and/or security.
The physical and logical objects, or more generally the physical and logical entities, whether they are of the system or the network type, i e., the clients, servers, systems, gateways, routers, etc , are at the same address level Common mechanisms are used for the naming, the addressing, and the name resolution and routing services. When a client establishes a connection with a software server that, in a preferred variant of embodiment, is an object container, there is no longer a need to also provide the name of the system (i.e., the machine and its services) that contains this server
Hence, the subject of the invention is a communication process in a set of distributed systems via at least one internet type network, said set being divided into at least one domain comprising systems addressable via said network by means of a first series of internet type addresses stored in a domain name directory and each system being connected to said network via a standard interface module, standard software layers comprising a stack of addresses of the first series and internet type communication protocols, and hosting at least one software entity, characterized in that said software entities and said systems are each associated with an internet type address of a second series, in that each system is configured into a so-called system virtual network, to which the system itself and said software entities are connected via specific interface modules and specific software layers comprising a stack of addresses of the second series and internet type

communication protocols, and in that said addresses and names of the systems and the software entities connected to said system virtual networks are stored in said domain directory, making it possible to directly address any of said software entities hosted in any of said systems
Hence, it is clear that the process according to the invention provides many advantages, including the capability for a client (or more generally for a user) to directly address a server '(or more generally a software entity), and not the system that contains it.
The invention will be more clearly understood and other characteristics and advantages will emerge from the reading of the following description in reference to the attached figures, in which
- Figs 1a through 1c illustrate an architecture of a distributed system in an
internet type network according to the prior art,
- Fig. 2 schematically illustrates the process according to the invention;
- Figs 3 and 4 illustrate the architecture of a system according to the process
of the invention,
- Fig. 5 schematically illustrates a communication process in a two-protocol
system,
- and Fig 6 illustrates the adaptation of the process according to the
invention to a clustered system architecture.
Before describing the process according to the invention, it is first necessary to review the configuration of a system 1 according to the prior art and its chief characteristics, in reference to Figs. 1a through 1c.
First of all, let us consider an isolated system, referenced So, connected to an internet type subnetwork SRX, with the prefix X, as illustrated more particularly by Fig. 1a. Let us also assume that it hosts two servers SV01 and SV02, i.e. two software objects, or more generally two software entities. The system So has an IP address in the subnetwork SRX given by the relation @IP:X, Xo
Each server, SV01 or SV02, is identified by an IP address and a port number, P01 OR P02. which are:
- for the server SV01- X, Xo, P01;
- for the server SV02: X, Xo, P02

The system So is connected to the subnetwork SRX via an interface I0, which will be described in detail below, and which comprises various logical layers: stacks of IP addresses, communication protocols Only this interface knows the port numbers Po, and P02 Therefore, it is easy to see that according to the prior art, when wishing to address one of the servers SV01 of SV02 from outside the system So, it is absolutely necessary to know the IP address of this system, i e , the address @IP:X Xo.
Fig 1b illustrates, more generally, a set 1 of systems connected via a subnetwork SRX, again in a configuration according to the prior art
In Fig. 1b, it is assumed that the set 1 constitutes one and only one domain D1 It is also assumed that the system 1 comprises q clients, referenced Cl1 through Clq, and n machines, i e., systems, referenced S1 through Sn Each system comprises a given number of servers, for example m servers in the system S1, referenced SV11 through SV1m, and p servers in the system Sn, referenced SVn1 through SVnp. Each system is provided with one or more so-called IP addresses.
The exchanges of information, i.e , of messages, take place using the "TCP-IP" protocol between the clients CI1 through CLq, and the systems S1 through Sn, via the internet type subnetwork SRX The domain D1 also comprises a domain name server DNS, that stores a directory of IP addresses. Finally, each system S1 through Sn comprises an interface, I, through In, with the subnetwork SRX, which stores a stack of IP addresses associated with each system and a routing table that makes it possible to transfer a received message to another system via the subnetwork SRX
Within a system, for example the system S11 a particular server, for example the server SV11, is identified by a port number, as noted in connection with Fig. 1a.
When a client, for example Cl11 wants to address a particular server, for example the aforementioned server SV11, it is necessary for it to know the name of the system that is hosting it, in this case the system S1 The directory present in the server DNS1 establishes a correlation between the name and the IP address of the system S1 containing the server SV11 The client CI1, then addresses the system S1 using the IP address it receives from the domain name server DNS,

As shown in Fig. 1 c, the addressing schema is very similar to the one just described when the set of systems, referenced V, comprises several domains, for example two domains D1 and D2 Each domain D1 and D2 comprises its own specific domain address server DNS, and DNS2, and a network or subnetwork SRX1 and SRX2, respectively The interconnections between subnetworks take place via an interdomain network or subnetwork SRld, and a server, also interdomain, DNSld, is provided If the client CI1 in the domain D1 no longer wishes to address a server (not represented) comprised in the system Sn of the domain D1, but a server (not represented) comprised in the system S21 of the domain D2, it will be provided with the address of the destination domain D2 by the server DNS,d, then, in the domain D2, it will be provided with the address of the destination system S21 by the server DNS2. Here again, it is necessary to know the name of the system hosting the server addressed, in this case the name of the system S21
Before describing the process of the invention, it is also necessary to briefly review the mechanisms used in the domain servers, for example DNS, or DNS2, and those used for routing
The main function of domain name server, or "DNS," is to establish a correspondence between symbolic names assigned to systems (and more generally to entities, as explained above, within the scope of the process according to the invention), and IP addresses. A domain name server operates hierarchically It is constituted by domains, for example D1 or D2 (Fig 1c), that allow the names to be divided into functional categories, for example associated with a business, with a country, etc This last characteristic, at the "top" of the aforementioned hierarchy (first level domains), is represented by a suffix such as "com," "edu," "gov," "int," "mil," "net," "org," "fr," etc., separated from the rest of the name by a period. The rest of the domain name can in turn be divided into partial domain names separated by periods (lower levels). For example, a given business service could be represented by a symbolic name such as "servicei.xxx com", in which "xxx" would represent the name of a company and "servicel" would represent a particular service A search for this name makes it possible to focus on the domain name servers "DNS" assigned to " com" If a name of the aforementioned type is being searched for, it is the domain name server "DNS" assigned to " xxx", whose

superior server is "com", that will process the request This corresponds to the schema implicitly described in connection with Fig 1c.
More precisely, for example, in the domain name server DNS, of the domain D1 that contains the system S11, there is an entry of the type "sys11 -> X1,Xn", X1 being the prefix of the subnetwork SRX1, and X11 the address of the system S11 in the subnetwork SRX1
Within a system, an initial configuration operation makes it possible to allocate it an address using a specific command. For example, in a "UNIX" (registered trademark) environment, the command "IFCONFIG" makes it possible to configure the network interfaces, for example I, through ln (Fig. 1 b), of a stack of internet protocols This configuration operation creates an entry in a table known by the acronym "IFNET". This table contains a description of the interface, the IP address, status information and pointers to the "drivers" associated with the interface. After this operation, the system S11 (in the example) has the address X,X11 as its IP address
Referring again to Fig. 1a, the routing allows access to a subnetwork other than the subnetwork SRX, for example a network SRZ (not represented), Z being the prefix of this network, this access takes place through the system So, which constitutes an X-Z gateway. The system S11 is a terminal and the IP routing level can be deactivated
Within an internet network, the routers use databases that make it possible to switch the packets of informational data There are many known routing protocols such as "RIP" ("Routing Information Protocol") or "OSFP" ("Open Shortest Path First"). These protocols allow the routers to exchange routing information. For example, if the "RIP" protocol is used, a given system communicates the addresses of its prefixes (i.e., the addresses of the subnetworks to which it is connected) to all of its neighbors. Thus, step by step, the routes that allow the packets to be routed are established.
It is then necessary to declare "drivers," and more precisely, two types of drivers' a network interface driver, called "nid", and a driver that corresponds to the electronic circuit board for interfacing with the network, called "ndd" (for "network device driver").

10
The process according to the invention will now be described. Fig 2 very schematically illustrates the process for addressing servers according to the invention It is assumed in Fig 2, for purposes of simplification, that the set of systems, here referenced 2, is comprised within only one domain D1, associated with one domain name server DNS, and only one client Cl1
According to a first important characteristic of the invention, each "real" system (S1 through Sn of Fig 1b) is comparable to a virtual network SVN, through SVn represented by dotted lines in Fig 2 These networks will hereinafter be called "system virtual networks."
According to a second important characteristic of the invention, the servers, for example SV11 through SV13, are each associated with an individual IP address. It follows that each server, for example the server SV11, i e., an object or a software entity, is directly addressable by a client, for example a client Cl11 and more generally a client CIx if the system 2 comprises several clients (x being arbitrary) In other words, a client no longer needs to know the name of the system hosting the server sought The directory of the server DNS, stores all of the IP addresses of the servers, for example the servers SV11 through SV13 of the system virtual network SVN1
It must be noted that, in a multidomain system, all the servers of a system virtual network belong to the same domain.
According to a third important characteristic of the invention, the "real" systems or machines (S, through Sn of Fig 1b) which, in a configuration according to the prior art, constitute endpoint systems, become intermediate systems They constitute nodes of the virtual networks SVN, through SVNn, and also nodes of the "real" network, i.e the internet or intranet subnetwork SRX. The systems act as gateways that interconnect the nodes of the virtual networks SVN, through SVNn with the subnetwork SRX. Each system is also provided with an IP address
Hence, a system virtual network SVN, associated with a system S1, may be represented as illustrated by Fig. 3. It is noted that the system S1 actually constitutes a node for the network Rx and that, seen from this network (i e., from the outside), it is associated with a first address IP,, with @IP1 'X.X1, X being the

11 prefix assigned to the subnetwork SRX and X1 the address of S, in the subnetwork
it is assumed that the system virtual network SVNy is constituted by the two servers referenced SVA and SVB that it hosts and by the system S1 itself Seen from the system virtual network SVN11 the system S, is associated with a second address IP2l with @IP2 Y,Y1f Y being the prefix assigned to the system virtual network SVNY and Y, the address of S, in the network SVNY
Likewise, the servers SA and SB are associated with two addresses IPA and !P8, respectively, with @IPA:Y,YA, and @IP2-Y,YB, YA and YB being the addresses of SVA and SVBt respectively, in the network SVNY.
Fig. 4 illustrates in greater detail the architecture of the system S, according to the invention
The "real" network Rx communicates with the system virtual network SVNY via a standard network interface module 10, known by the acronym "IFNET" (common to the prior art), a stack of system IP addresses 12, also standard, and an interface module 11 specific to the system virtual network, which, for the sake of analogy, will be called "IFSVN" In essence, the latter plays a role similar to the "IFNET" interface 10 The system also comprises a standard "TCP/UDP" protocol layer 13.
Likewise, even though the servers SVA and SVB are physically located in the system S1f they are both provided with specific "IFSVN" interface modules, 20 and 30 respectively, stacks of IP addresses, 21 and 31 respectively, and "TCP/UDP" protocol layers, 22 and 32 respectively. The servers SVA and SV0 therefore communicate with the system virtual network SVNY through these two layers and through the specific interface modules
In other words, the specific interface modules 11, 20 and 30 allow for a standard behavior of the IP level (level 12) of the system S, that contains the system virtual network SVNY They allow the routing of packets of information within the system S1 to the software servers SVA and SVB, which henceforth act like virtual endpoint systems of the system virtual network SVNY.

12
According to the invention, the allocation of IP addresses, whether they relate to the systems per se or more specifically to the software servers, takes place in a way that is intrinsically similar to the methods of the prior art
For a given server, for exampfe SVA, i e , related to an object run in a system, for example the system S1 included in the domain D11 the directory of the server DNS, is updated This update can be performed manually or automatically, as will be explained below
More precisely, an object or an entity uses two functions that are intrinsically known the allocation of a global address and the release of an address
As indicated, the allocation of an address takes place in a way similar to the prior art, but with one major difference the system virtual networks are referenced in the domain name server with the entities that are connected to them, including the software servers
Returning to the example of Fig 4, the domain name server DNX, stores the following entries"
a/sys1 ->X,X, , b/sys2-> Y,Y1 , c/ serva -> Y,YA , d/servb-> Y,YB;
the entries a/ and b/ being related to the addresses \P, and IP2, respectively, and the entries c/ and d/ being related to the addresses IPA and IP8, respectively It must be noted that sys1, sys2, serva and servb are symbolic names
A server or service is therefore directly addressable. For example, if a company "xxx" has the domain name server DNS, and its superior domain name server is the server of "com", the service "serva" becomes addressable in the Internet by the name "serva.xxx com". Any client object, or more generally any user, can query its domain name server to request the IP address corresponding to this name The domain of the system that sent the request, given the structuring of the name (i.e., a notation that includes periods) transfers the request to its superior domain name server if it cannot handle it itself, and so on until a particular domain server is capable of addressing the request to the domain name server that will

13
handle the correspondence "symbolic name - IP address requested," for example the server DSN,
The address releasing function releases an address previously allocated to an object
For routing purposes, the system S1 is no longer an endpoint, but has become a gateway The IP routing level is necessarily activated
In order for there to be correct routing between all of the systems of a network, no matter what its nature, it is also necessary to perform name resolution operations This function is the most important of those assigned to the protocol "ICMP" (for "Internet Control Message Protocol"). It consists in the discovery, for a given system, for example S,, of the neighbor systems that share the links to which it is connected. This operation takes place the first time a datagram is sent through the network SRX to a neighbor In effect, at this instant, the system S1 that wishes to send a datagram to one of its neighbors knows the IP address of the destination, but not its network address (for example an "Ethernet" (registered trademark) address, if it is a network of that type) In practical terms, this means that the system S1 must construct a table that establishes the correspondences between IP addresses and network addresses. To do this in local area networks, for example in networks of the aforementioned "Ethernet" type, the IPV4 protocol uses a protocol known by the term "ARP" (for "Address Resolution Protocol") and the IPV6 protocol uses a protocol known by the term "NDP" (for "Neighbor Discovery Protocol") For example, if the protocol "NDP" is used, the system S1 can know the network addresses of the other systems that share its links A given system uses a broadcast address to request from its neighbors, as a function of their IP addresses, their network addresses.
In the case of the system virtual networks according to the invention, for example SVNY, the various users are the system S1 itself and the servers hosted by this system SVA and SVB Since they are located in the same place, the neighbor discovery described above is unnecessary. The protocols "ARP" or "NDP" are not invoked.
The initial configuration operation must, in the case of the invention, be subdivided. For example, in the above-mentioned "UNIX" environment, the

14
command "IFCONFIG" is also used However, it is necessary to configure the interface to the subnetwork SRX, the interface to the system virtual network SVNY, and also to configure an address of the alias type for each server connected to this network In the example described, two addresses must be configured @IPA Y,YA and @PB:Y,YB
As in the case of the prior art, it is necessary to declare "drivers," and more precisely, two types of drivers a network interface driver, called "nid," and a driver that corresponds to the electronic circuit board for interfacing with the network, called "ndd" (for "network device driver") Likewise, it is necessary to declare an interface driver for the system virtual network, for example SVNY This last driver is created (software development) in accordance with the rules for writing a standard interface driver "nid". It must be noted that the equivalent of the driver "ndd" is no longer necessary In fact, the "TCP/IP" layers necessarily comprise a driver called a "loopback" which, for the system virtual network SVNY, plays the role of the driver "ndd" for the subnetwork SRX
The way in which data packets enter and leave the system S1 will now be described in greater detail
If a data packet containing the indications "Y,YA" in its IP address arrives in the system S1, the latter consults the local address table It finds "Y,YA in the "IFNET" table 10 (an entry called an "alias") and considers the packet to have arrived at its destination and delivers it to the waiting application, i e , the server SVA, via the virtual network SVNY
If a data packet is sent by a server, for example the server SVB, to a server SVn located outside the system virtual network SVNY, the system S1 acts as a "routing server," or gateway, and switches this packet to the network interface that corresponds to the subnetwork SRX
If, on the other hand, a data packet is sent by a server, for example the server SVB, to a server located inside the system virtual network SVNY, for example the server SVA, the system S1 also acts as a router. It detects that the destination address corresponds to one of the local addresses. It executes a standard loop of the type known by the term "loopback" (mandatory in any stack of TCP/IP protocols, as indicated above) and transmits the packet to the server SVA. Hence,

15
the data packet does not leave the system S1 In particular, it does not pass through the subnetwork SRX.
The process according to the invention offers many advantages and possibilities
First of all, it must be noted that the process according to the invention is fully compatible with the internet protocol most commonly used to date, i e , the IPV4 protocol, alone or in combination with the new IPV6 protocol.
Fig 5 illustrates, by way of example, the communication process between two system virtual networks SVNY and SVN2, comprised in two systems, S1 and S2 respectively It is assumed that the two systems have both IPV4 and IPV6 addresses. It is also assumed that the network SRX that connects the two systems S1 and S2 uses the IPV4 protocol The standard encapsulation mechanisms used by the IPV6 protocol allow the users of the systems S1 and S2 to interoperate by using IPV6 packets that are encapsulated into IPV4 packets as they pass through IPV4 networks, as is the case for the network Rx
The two protocols can therefore coexist, and the IPV4 protocol can still theoretically be used alone within the scope of the invention However, it has been indicated that a shortage of addresses is predictable Moreover, given that according to one of the most important characteristics of the invention, the servers are also provided with an IP address, which contributes to increasing the need for addresses, it seems preferable to use the IPV6 protocol within the scope of the invention
Secondly, in combination with the new IPV6 internet protocol, the process according to the invention allows for a dynamic configuration, the dynamic resolution of the names being achieved by the protocol known as "NDP" (for "Neighbor Discovery Protocol"). The dynamic allocation of IP addresses is followed by an update of the databases of the directory service, making the owner of the IP address capable of communicating with a network of the internet, intranet or extranet type.
By way of example, a three-phase process, which makes an object or an entity dynamically addressable anywhere in a given domain, will be described in detail below

16
During phase 1, the object is run in a first system, for example the system S1 (Fig. 5), and the following steps are performed.
- allocation of an IP address to the object;
-the directory of the domain, for example DNS, of D,, that contains the system S1 is updated,
- the object can then establish connections with other objects
During phase 2, the object is transferred into another system, for example the system S2 (Fig. 5), and the following steps are performed
- the object closes its active connections;
- the object releases its IP address,
- the directory DNS1 of D, is updated;
- the object is transferred to the system S2 using a file transfer protocol.
During phase 3, the object is run in the system S2 and the following steps are
performed.
- allocation of a new IP address to the object,
- update of the directory DNS, of D1;
- the object can again establish or accept connections.
Third, the process according to the invention, again in combination with the IPV6 protocol, also allows for the portability of an object or an entity In fact, the IPV6 protocol offers the capability for this object to leave a domain, while remaining addressable as though it were still in the original domain.
Fourth, the process according to the invention allows software objects or entities to fully benefit from the security techniques defined at the internet level These techniques are implemented using "firewalls" and the "IPSEC" protocol. They provide access control services (address filtering), authentication, integrity (signatures) and confidentiality (using encryption algorithms) In the prior art, the internet link does not connect the systems to one another. In other words, the link and the "IPSEC" protocol do not extend as far as the software applications, i.e., as far as the servers It is therefore common to provide additional secure software layers, well known by the acronym "SSL" (or "Secure Socket Layers") in the systems, which makes the links more complex, especially when each object or entity generally has its own specific security requirements.

17
The process according to the invention, through the concept of a new generation of "firewall" associated with each client and each server whose security must be ensured, simplifies the security of the systems, since the links extend all the way to the software objects or entities In fact, according to one of its chief characteristics, these software objects have their own IP addresses and are therefore directly addressable In addition to providing greater simplicity, the process also makes it possible to reduce the cost of the solutions The equivalent security techniques implemented in the middleware in the prior art, illustrated for example by the above-mentioned "SSL" layer, become unnecessary.
Up to this point, each system has been considered to be autonomous Advantageously, the process according to the invention can-also be applied to systems in "clusters." In essence, the main purpose of such an architecture is to appear, seen from the outside, to be a single system or machine The process according to the invention makes it possible achieve this objective
Fig 6 illustrates an architecture of this type The clustered machines M1 through Mx, x being the maximum number of machines, are interconnected through a local area network SRC. There is network equipment in this local area network the node N provided with an IP address, IPN in the network SRX Each machine, together with the servers it is hosting at a given instant, constitutes a virtual network SVNM1 through SVNMx, these networks being connected according to the process of the invention to the network SRXl to the local area network SRC by each system, and to the network SRX via the node N
The standard IP mechanism organizes the routing of a packet addressing an object of a system virtual network to the node of the cluster that contains it, for example the server SVC in the system virtual network SVNM1 in the machine M1 For a remote client outside the cluster, the object addressed can be runTn any node of the cluster, in a way that is transparent for this client. In effect, there is no, longer any need to address a particular machine among the x machines. It is only necessary to address the desired object or entity, for example SVC
This mode of operation allows high availability. If an object or a software entity of a system virtual network becomes unavailable due to a hardware or software failure of the system that is hosting it, the object can be restarted in

18
another node and the standard address resolution mechanisms will allow it to be reconfigured dynamically. To do this, it is simply necessary to implement the process according to the invention, in combination with the IPV6 protocol.
In another operating mode, the object or entity can be duplicated in two or more of the machines constituting the cluster This redundancy can be provided for the same reasons as above (failure or malfunction) or in order to ensure availability, through rerouting, despite an overload of one or more machines (parallel operation).
With the reading of the above, it is easy to see that the invention clearly achieves the objects set forth.
The advantages offered by the invention are numerous Without redescribing them in detail, it is possible to summarize them as follows
- simplification of the addressing, the name services and the associated
protocols, for the network objects or entities as well as for the objects or entities of
the systems (software or applications),
- independence of the servers from the systems (machines);
- dynamic configuration, which makes it possible to move toward "zero
administration";
- portability of the software objects or entities,
- network security services applied to the software objects or entities;
- reduction of the costs of the solutions by reusing network services existing
through middleware and applications;
- and compatibility with current internet type architectures, as well as the
utilization of standards.
It should be clear, however, that the invention is not limited to just the exemplary embodiments explicitly described, specifically in relation to Figs. 2 through 5.

-19-WE CLAIM :
1 A process of communication in a set of distributed systems via at least one
internet type network, said set being divided into at least one domain comprising
systems addressable via said network by means of a first series of internet type
addresses stored in a domain name directory and each system being connected to
said network via a standard interface module and having standard software layers
comprising a stack of addresses of the first series and internet type communication
protocols, and each system hosting at least one software entity, said process
comprising the steps of:
providing said software entities and said systems with an internet type address of a second series ;
configuring each system into at least one system virtual network to which the system itself and said software entities are connected via specific interface modules and specific software layers comprising a stack of addresses of the second series and internet type communication protocols , and
storing said addresses and names of the systems and the software entities connected to said system virtual networks in said domain directory, such that any of said software entities hosted in any of said systems may be directly addressed from anywhere is said set of distributed systems using the internet type address of the second series or the names of the software entities
2 A process as claimed in claim 1, wherein the process comprises the steps of
allocating an address comprising a prefix and an identifier to each of said software entities for updating said domain name directory to record the names and addresses of these software entities , and
releasing addresses so as to release an address previously allocated to a given software entity
3. A process as claimed in claim 2, wherein said addresses are established in conformity with an internet protocol

-20-
4. A process as claimed in claim 3, wherein said address allocation is dynamic
and wherein the dynamic address allocation comprises at least the following
phases and steps :
a phase for running said software entity in a first system, comprising steps for allocating an address in conformity with the internet protocol,
updating said domain name directory and establishing and/or accepting connections via said internet type network ;
a phase for transferring said software entity from said first system into a second system, comprising steps for closing active connections,
releasing the internet type address of the software entity,
updating said domain name directory ; and
a phase for running said software entity in said second system, comprising steps for allocating a new address in conformity with the IPV6 internet protocol,
updating said domain name directory, and
establishing and/or accepting new connections via said internet type network.
5. A process as claimed in claim 4, wherein communication between said
software entities take place in a client-server mode.
6 A process as claimed in claim 5, wherein said software entities are client
objects or server objects
7 A process as claimed in claim 4, wherein at least one of said systems is
constituted by a cluster of at least two machines connected to said network at a
common node, and each machine forming one of said system virtual networks,
said node is associated with an internet type address of said first series, making it
possible to address a sofware entity hosted by any one of said machines by means
of an internet type address of said second series

-21-
8. A process as claimed in claim 7, wherein at least one of said software entities is duplicated in at least two of the machines of said cluster
9 A process as claimed in claim 7, wherein said software entities are connected by means of an internet link via said internet type network, in order to protect this link from end to end and firewalls are associated with said software entities.
10. A communication system in a set of distributed systems via at least one
internet type network, said set being divided into at least one domain comprising
systems addressable via said network by a first series of internet type addresses
stored in a domain name directory and each system being connected to said
network via an interface module and having software layers comprising a stack of
addresses of the first series and internet type communication protocols, and each
system hosting at least one software entity, said communication system being
characterized in that said software entities and said systems are each provided
with an internet type address of a second series, each system being configured
into at last one system virtual network to which the system itself and said software
entities are connected via specific interface modules and specific software layers
comprising a stack of addresses of the second series and internet type
communication protocols, and means for storing said addresses and names of the
systems and software entities connected to said system virtual networks in said
domain directory, such that any of said software entities hosted in any of said
systems may be directly addressed from anywhere in said set of distributed
systems using the internet type address of the second series or the names of the
software entities.
11. A communication system as claimed in claim 10, comprising means for
allocating an address comprising a prefix and an identifier to each of said software
entities for updating said domain name directory to record the names and
addresses of these software entities, and releasing addresses so as to release an
address previously allocated to a given software entity.

-22-
12 A communication system as claimed in claim 11, wherein said addresses are established in conformity with the internet protocol.
13. A communication system as claimed in claim 12, wherein said address allocation is dynamic, and wherein the dynamic address allocation comprises at least the following phases and steps :
a phase for running said software entity in a first system, comprising steps for allocating an address in conformity with the internet protocol,
updating said domain name directory,
establishing and/or accepting connections via said internet type network ;
a phase for transferring said software entity from said first system into a second system, comprising steps for closing active connections,
releasing the internet type address of the software entity,
updating said domain name directory ; and
a phase for running said software entity in said second system, comprising steps for allocating a new address in conformity with the IPV6 internet protocol,
updating said domain name directory, and
establishing and/or accepting new connections via said internet type network
14 A communication system as claimed in claim 13, wherein communications
between said software entities take place in the client server mode
15 A communication system as claimed in claim 13, wherein said software
entities are clients objects or server objects.
16 A communication system as claimed in claim 13, wherein at least one of
said systems is constituted by a cluster of at least two machines connected to said
network at a common node and each machine forming one of said system virtual
networks, said node being associated with an internet type address of said first
series, such that a software entity hosted by anyone of said machines by means of
an internet type address of said second series may be addressed.

-23-
17. A communication system as claimed in claim 16, wherein at least one of
said software entities is duplicated in at least two of the machines of said cluster.
18. A communication system as claimed in claim 16, comprising firewalls
associated with a pair of said software entities and means connected by an internet
link via said internet type network, in order to protect said link from end to end
The invention relates to a communication process via an internet network that comprises distributed systems (S1) Each system (S1) is connected to the network (SRX) via a standard interface module (10), standard software layers (12, 13) comprising a stack of addresses and protocols, and hosts software entities (SVA, SVB), The latter and the systems (S1) are provided with a network address in a virtual subnetwork to which the system itself (S1) and said software entities (SVA, SVB) are connected via a specific interface module (11, 20, 30) and specific software layers (21-22, 31-32) comprising a stack of addresses and protocols. The addresses and names of the systems (S1) and of the software entities (SVA, SVB) connected to the virtual networks (SVNY) are stored in a domain name directory (DNS1), making it possible to directly address one of the software entities (SVA, SVB)

Documents:

in-pct-1999-00029-kol abstract.pdf

in-pct-1999-00029-kol assignment.pdf

in-pct-1999-00029-kol claims.pdf

in-pct-1999-00029-kol correspondence.pdf

in-pct-1999-00029-kol description(complete).pdf

in-pct-1999-00029-kol form-1.pdf

in-pct-1999-00029-kol form-13.pdf

in-pct-1999-00029-kol form-18.pdf

in-pct-1999-00029-kol form-3.pdf

in-pct-1999-00029-kol form-5.pdf

in-pct-1999-00029-kol g.p.a.pdf

in-pct-1999-00029-kol letters patent.pdf

in-pct-1999-00029-kol others.pdf

in-pct-1999-00029-kol reply f.e.r.pdf

« Previous Patent

Next Patent »

Patent Number

203353

Indian Patent Application Number

IN/PCT/1999/00029/KOL

PG Journal Number

10/2007

Publication Date

09-Mar-2007

Grant Date

09-Mar-2007

Date of Filing

06-Sep-1999

Name of Patentee

BULL S.A.

Applicant Address

68, ROUTE DE VERSAILLES, F-78430, LOUVECIENNES, FRANCE.

Inventors:

#	Inventor's Name	Inventor's Address
1	HERBERT MICHEL	4,IMPASSE J.H. LARTIGUE, F-38120, SAINT-EGREVE, FRANCE.

PCT International Classification Number

H04L 29/00, 29/12A.

PCT International Application Number

PCT/FR98/02890

PCT International Filing date

1998-12-28

PCT Conventions:

#	PCT Application Number	Date of Convention	Priority Country
1	98/00055	1998-01-06	France