WO1998054631A2 - System for network file distribution - Google Patents
System for network file distribution Download PDFInfo
- Publication number
- WO1998054631A2 WO1998054631A2 PCT/US1998/007337 US9807337W WO9854631A2 WO 1998054631 A2 WO1998054631 A2 WO 1998054631A2 US 9807337 W US9807337 W US 9807337W WO 9854631 A2 WO9854631 A2 WO 9854631A2
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- server
- central server
- files
- servers
- client
- Prior art date
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
Definitions
- This invention relates generally to a system for distributing information to a plurality of computers. More specifically, the invention relates to a system for distributing, updating and maintaining files, originated by various sources, on remote servers subsequently accessed by multiple users over networks.
- the Internet is a widely distributed network of servers, gateways and hubs, each either enabling the Internet as a whole (such as by routing data requests and responses) and/or housing data and functions accessible by end users.
- This distributed scheme of data and functions applies not only to the Internet in general, but also to the individual providers of data and functionality.
- one organization may not have all of its Internet related files contained on one server, but may have them shared between multiple, geographically separated servers. With larger organizations, each division or subsidiary may have its own dedicated servers to store and maintain only those Internet files particular to its responsibilities.
- the servers are likely all networked in one form or another (for example, through the Internet itself) , it is also possible for an operator to individually and manually access each server in turn and overwrite the existing files.
- all of these methods require gathering the necessary changes or updated files from diverse origins, since responsibility for maintaining the files may be fragmented. The gathering step may also become unwieldy, as some or a majority of the information may originate with many different content providers both inside and outside the organization directly responsible for the Internet sites.
- information would flow in a multi-step operation, first from each individual content provider in turn to an individual or group within the controlling organization and then each file would be manually transferred to the end-user-accessible server.
- a system having client computers, at least one central server and local servers.
- the local servers control the updating of content on HTTP farm servers directly under its control.
- Client computers are used by content providers and system administrators to control the content on the ultimate HTTP servers.
- the central server receives information from the client computer, allows for testing of the content, if desired, and then forwards the information to the local servers as appropriate.
- the release and maintenance of content is strictly controlled on several levels.
- Fig. 1 is an overall system schematic showing a preferred embodiment of the network distribution file system of the present invention
- Fig. 2 is a logic flowchart of a remote client computer accessing the central server of the system of Fig. 1;
- Fig. 3 is a logic flowchart of a security feature of the client/central server connection of the system of Fig.
- Fig. 4 is a logic flowchart of a remote local server accessing the central server of the system of Fig. 1;
- Fig. 5 is a logic flowchart of another security feature of the local/central server connection of the system of Fig. 1; and Fig. 6 is a schematic diagram showing the location of various files in the system of the present invention.
- Fig. 1 the overall schematic of a system according to the present invention is shown.
- the system allows an organization to make content available to others, such as over the internet, while giving the organization the ability to easily and automatically control that content, though it may be scattered across multiple servers.
- client is anyone, either within or outside the controlling organization who has authorization to alter or provide content (e.g., files, data, etc.) to the system.
- User is a person who ultimately accesses the content, such as in an HTTP environment, and/or takes advantage of the functionality of the content. The user may be within or outside the controlling organization, as described below.
- Client computers 110 are accessed by various classes of clients: system administrators, content providers and programmers, to name a few.
- the client computers provide access to the files of the system for updating or other maintenance purposes.
- the local servers 120 feed content to their HTTP server farms respectively, as appropriate for ultimate use by users. In other words, the local servers put the content in a position where it may be accessed by anyone with access to that server farm.
- two of the servers 120a, 120b shown are examples of private access servers. These servers would be accessed only by users within the organization controlling the system. These servers 120a, 120b could be part of a corporation's intranet, taking the place of a hardwired local area network.
- Two other servers 120c, 120d are outside of the controlling organization and may be accessed by any public user with the appropriate computer capabilities.
- some of the content such as the user's financial account information, may require passwords or other security features, but at least the connection can be made through public computer networks.
- the local servers 120c, 120d outside the controlling organization are separated from their respective central servers 130 by firewall systems 140a, 140b. Individual firewall systems are generally known.
- a socket relay 150 described more fully below, would be needed.
- the socket relay 150 is located between the double firewalls 140a, 140b.
- the socket relay prevents certain techniques for bypassing firewalls by altering the address of the data packets and retransmitting the packets between the firewalls 140.
- the local server 120d attempts to make a connection to 1.1.1.1:7100 (this address is broken down into the server "1.1.1.1” and the listening port "7100") .
- the firewall 140a is configured to translate the address of the packet into 2.2.2.2:7100, "2.2.2.2” being the address of the socket relay 150 running on a separate computer.
- the data packets are then placed on the safe side of the firewall 140a and transmitted to the socket relay 150.
- the socket relay 150 then connects to the second firewall 140b at 3.3.3.3:7100 and transmits the data packets to address 3.3.3.3:7100.
- the packet address is translated by the second firewall 140b into 4.4.4.4:7100, "4.4.4.4" being the address of the central server 130.
- the packets are placed on the safe side of the firewall 140b and transmitted to the central server 130.
- the end result is that a packet sent to 1.1.1.1:7100 arrives at 4.4.4.4:7100 as though it was originally sent to that address.
- the socket relay 150 which does not alter the data packets, but transmits them to a different address, attempts to bypass the firewalls are thwarted.
- Central servers 130 are situated between the local servers 120 and client computers 110, acting as conduits and gatekeepers for content flow.
- the central servers 130 form the backbone of the system and include much of the functionality to achieve the system's objects.
- Each central server 130 is connected to a plurality of local servers 120, each which either include the files that are subject to updating or have connections to and control over other servers that do.
- the specific hardware and connection protocols for the various servers are not critical, although there are some preferred features.
- the hardware preferably includes the storage capacity to maintain the necessary files of the system, as described below.
- the central servers have higher storage needs, as they house master copies of all data files under their control .
- the central servers may also hold archived copies of all previous versions of all files, and thus would require significantly more storage.
- All of the servers must also include standard hardware and software for making remote connections, such as over telephone lines, satellite or microwave transmissions or hardwiring.
- the protocol used is immaterial, although the current TCP/IP standard is preferred.
- the connections between the client and central servers are preferably made over a data highway 100, such as a Novell network within the controlling organization or the Internet itself.
- the connections between the central and local servers are similar.
- the central and local servers are workstations running Microsoft ® Windows NT.
- the client computers are workstations preferably running under either Windows 95 or Windows NT. All of the servers preferably communicate using the TCP/IP protocol.
- the exact hardware configuration, operating system, and communications protocol of each server is not critical and it is contemplated that improvements in workstations and communications protocols may be incorporated into the present invention without departing from the invention.
- the potential variation in the client computers is largely due to the fact that some of those servers may be outside the controlling organization and are thus not subject to control. It is only necessary that those servers be capable of running the client or local server portion, respectively, of the software portion of the present system.
- the software components of the system are preferably built using Microsoft's Foundation Classes (MFC) . Specifically the system uses the MFC CSocket class for streaming complex aggregate data types over TCP/IP connections.
- MFC Microsoft's Foundation Classes
- the client computer should be pre- configured with the network address (for example, TCP/IP address) of the central server or else the client may input the address. This may also include identifying a specific listening port on the central server.
- Each central server then maintains a database of those client computers and users that are permitted to access that particular central server.
- the database also contains, for each user, the types and/or specific files that may be updated and/or deleted by the user. This access information is set by the controlling organization to maintain security.
- the client also needs to know the specific local and central servers that form a pathway to the target HTTP server. This address information is then programmed into the client computer.
- a database may be used for automatic retrieval by the client computer of the appropriate local and client computer information for a particular selected target HTTP server.
- connection sequence between a client computer and a central server is illustrated in the logic schematic of Fig. 2. Assuming that the central server is up and running with its portion of the software of the present invention, that server will be listening on two separate socket ports waiting for connections. One port is listening for connections coming from client computers while the second port is listening for connections coming from local servers. Of course, more than two ports may be used and simultaneous connections may be made, although this raises the possibility of two clients attempting to update the same file at the same time. This is usually avoided in the preferred embodiment by only allowing one client to update an associated target HTTP file. This also helps maintain control over the version of the files, since only one client has the ability to update.
- the client whose update command was received first would be executed, while a near-simultaneous command from another user would result in an error message being sent back to the second client computer and the file not being further updated.
- a socket connection is initiated by the client computer (block 220) and established with the central server.
- the central server acknowledges the connection (block 230) .
- the client computer then sends a login request to the central server, using the username and security password of the client attempting to update the files (block 240) .
- encryption may be performed on the username and password data to prevent unauthorized users, using such programs as packet "sniffers," to gain improper access to the system. It is further contemplated that some form of encryption and/or authentication may be used for all data passed between the various servers of the system.
- the central server responds with the client's account information, which includes, but is not limited to, the following information: file types and specific file names or file prefixes the client is permitted to update; and target local server and/or HTTP farm machines the user is allowed to update (block 250) . Based on these restrictions (previously set and maintained by the controlling organization's administrators), the client may now update content files.
- the client computer is the master and the central server is the slave, i.e., the central server waits for commands from the client computer.
- the central server sends a test packet periodically, even though the central server is the slave in the connection.
- the servers can detect when a connection has been lost or dropped, allowing the servers to immediately free up resources previously used by that connection for other connections.
- the central server sends a test packet that contains no data, only control signals (block 310) . If the client computer does not echo the packet back (block 320) , the central server releases the connection (block 330) .
- the central server maintains the connection (block 340) and begins waiting a predetermined period (preferably two minutes - block 350) to send another test packet (block 310) . It is preferred that the delay at block 350 be large enough so that the test packets do not create a performance or load problem on the network.
- the client computer contains various files pertaining to the present invention. Of course, all of the servers in the system will have the necessary operating system and communications files, in addition to any display, storage or other driver files needed for the general functioning of the server computer. With respect to the present invention, the client computer 110 includes the program executable files 610 of the present invention.
- the server also contains the source content files 620, which are the files that are transferred ultimately to the local servers and the HTTP farms.
- Internal data files 630 store information on the central and local servers to which the client computer has access, in addition to any restrictions on access to those servers.
- the client computer includes a log file 640, which records all client activity. This can be useful to an administrator in diagnosing a client error, or in recreating what a client desired to do, but was unsuccessful .
- the central servers each contain program executable files 650 for their own use. These are in addition to those executable files that may be transferred to local servers at another time.
- the central servers also each contain a set of master content files 660, which are master copies of the most recent versions of all files that were transferred to any of the local servers connected to each particular central server.
- Archive data and archived files 670 include a record of all transactions that have occurred to the local servers, as well as copies of all older versions of superseded content files. It is not necessary for all of the archived files to be maintained on the central servers. Preferably, the older archived files are transferred to less accessible media, such as removable tape cartridges, rather than on the servers' own drives.
- the system is capable of not only recreating the current configuration of any local server (using master files) , but the configuration at any time in the past as well. For example, if a local server is damaged in some way, or there is a data loss on that server, the system can read the archive data to determine which of the current master files had been transferred by the central server and not superseded since transfer.
- the central server can then transfer all of these content files, including the necessary local server executable files, to completely rebuild the server.
- the central server also contains database files 680 relating to the client and local servers that may access it. For client computers, these files would include username and password information for clients, while for local servers, it would include the machine group names of servers for validation.
- the database files also include tables detailing which of the master content files are intended for particular local servers. The tables include entries for each master content file and include such information as the following: time/date of last update, and appropriate local servers for transfer.
- the local servers 120 contain the program executable files 690 needed to run the system on that computer.
- the local servers also contain the content files 700 that have been transferred through the central servers 130, as well as connection information files 710, including the network address of the assigned central server and the machine group name, discussed below.
- the client would make desired changes to source content files contained on the client computer. This could involve a single change to a single file, multiple changes to multiple files, additions and deletions of entire files, or any combination of those. Not all clients are given complete functionality, so it is possible that a particular client would not be permitted to delete files, but merely to add or alter them.
- the client initiates (such as by pressing a screen button) the connection between the client and central servers as discussed above. Assuming the particular client has no restrictions with respect to the updated files, the master content files may then be superseded in one of two modes: replace-all or replace-since a certain date and time.
- the replace-all mode With the replace-all mode, every file in the client's source file directory is copied to the central server. As each file is copied, the previous version stored on the central server is moved to an archive location and a record is made of the transfer.
- the replace-all mode has the possibility of replacing a relatively new version of a file with an older one that just may happen to be in the user's directory along with new updated files. Therefore, the preferred mode is the replace-since mode, in which the client computer only transfers those files that have been added or updated since a particular date and time. For example, only files updated since the last connection to the central server could be transferred. This greatly reduces the chance of overwriting a newer file. It is also contemplated that the central server could respond to the client computer with a warning when the time/date stamp on a file to be transferred is before the time/date stamp on its current master file. The transfer would only then take place upon specific client authorization.
- Each file is also transmitted with additional data packets that include the addresses and directories of the local servers to which the file should be transferred by the central server.
- the additional data packets preferably also include the network address and local directories of the target HTTP servers to which the file is ultimately transferred.
- the client computer displays the status of the transfer to confirm that all files have indeed been transferred. Failed transfers can be immediately seen and dealt with by the client.
- the user may also login again with a different username and password, if perhaps the user has multiple sets of content files under its control, or drop the connection to the central server. Once the connection is dropped, the central server resumes its listening state for the next client computer to connect.
- the central server also includes a test server, which is preferably a separate process running on the central server machine and configured as an HTTP server.
- the test server may also be a dedicated separate server machine.
- the client may also transfer the files to the test server.
- the client may then access the updated files to check the quality of the files. For example, if the updated content files include a web page in HTML or another browser format, the client could access the file on the test server using a browser, including all the file's embedded links to such other files as inline graphics. This is performed to catch any bugs or errors in the updated files before they are distributed by the central servers to local servers, where they are often immediately available to the users in and out of the controlling organization.
- This test server provides instantaneous feedback to the client regarding possible inoperative sites in their internet user environment.
- the connection between the central and local servers is somewhat different than the client/central connection in that it is not client-initiated, but is preferably accomplished automatically.
- the central server once running, will be listening on at least one port for connections from a local server.
- Each local server is pre-programmed with the network address (e.g., TCP/IP address) of its assigned central server.
- the local server attempts to connect to its assigned central server periodically (block 410) , preferably every two minutes. If the connection is successful (block 420) , the central server will acknowledge the connection (block 430) .
- the local server waits a pre-programmed delay (block 440) , preferably two minutes, and attempts to connect again. Assuming the connection has been made and acknowledged, the local server will then send its machine group name, which is a registry set value (block 450) . If the central server database has been pre-programmed with the machine group name for that server (block 460) , then the connection is maintained and content file updates will be received by the local server (block 470) . If the machine group name is not valid compared to the central server database, the connection is dropped by the central server (block 480) .
- the central server Unlike the client computer/central server connection, even though the local server initiated the connection, the central server becomes the master, while the local server becomes the slave waiting for commands.
- the slave server in this case the local server
- the central server does successfully echo the packet (block 520) , the central server maintains the connection (block 540) and the local server begins waiting a predetermined period (preferably two minutes - block 550) to send another test packet (block 310) . It is preferred that the delay at block 550 be large enough so that the test packets do not create a performance or load problem on the network. If the connection is lost or dropped unexpectedly (for example, due to power outage) , the local server will attempt to re- establish the connection every two minutes until successful.
- each client controls the updating of content files it is authorized to alter.
- the central server transfers the updated files to the connected local servers.
- the client maintains full version control on the content files. For example, if the client is updating files on several different target HTTP servers and one is unsuccessful for an unknown reason, the client can immediately restore the other HTTP servers to their previous state using archived files and determine the problem. Then the client would re-transfer the files through the central server to the HTTP servers.
- the local server does not maintain copies of the older versions of content files, as these are archived on the central server as described above.
- the client software includes the option of automatic periodic updates to the central and local servers until all files on the target servers match the latest versions on the client computer.
- the HTTP server may need to be stopped and restarted for the updates to take effect. If the client had selected that option (discussed below) when transferring the files from the client computer, the central server will cause the HTTP server to be stopped and then restarted.
- Delete Remote Files Allows clients with proper authorization to delete files on the central server.
- Freeze Target Machines Allows clients with proper authorization to freeze target central or local servers to prevent them from receiving any further updates during routine maintenance or another updating sequence.
- Ping Selected Servers Allows clients to test whether or not the target server(s) are up and functioning properly.
- Pinch Selected Servers Allows users to test whether a certain TCP/IP based server is up and running by connecting and disconnecting from the servers 's listening port. Stop/Start NT Servers: In order to update internet site system files, it is sometimes necessary to shut down the HTTP server. Once the new system files have been updated, the HTTP server can be restarted. This option provides the stop/start functionality needed to accomplish this task.
- Update System Software Allows an administrator to update new versions of the system software from a remote location.
- Get Software Versions Allows an administrator to verify the running versions of the central and local server system files from a remote location.
- View Targets Allows a client to see all target machines available to them. From the list, the client may then select which of the local servers it wishes to update.
- Delete Target Allows a client to delete all files and directories at a target location.
Abstract
Description
Claims
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
AU69678/98A AU6967898A (en) | 1997-05-27 | 1998-04-14 | System for network file distribution |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US86380797A | 1997-05-27 | 1997-05-27 | |
US08/863,807 | 1997-05-27 |
Publications (2)
Publication Number | Publication Date |
---|---|
WO1998054631A2 true WO1998054631A2 (en) | 1998-12-03 |
WO1998054631A3 WO1998054631A3 (en) | 1999-03-11 |
Family
ID=25341834
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/US1998/007337 WO1998054631A2 (en) | 1997-05-27 | 1998-04-14 | System for network file distribution |
Country Status (2)
Country | Link |
---|---|
AU (1) | AU6967898A (en) |
WO (1) | WO1998054631A2 (en) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2000045303A1 (en) * | 1999-01-28 | 2000-08-03 | Webspective Software, Inc. | Web server content replication |
US7630989B2 (en) | 2002-05-17 | 2009-12-08 | Colonial First State Investments Ltd. | Transaction management system |
WO2014193638A1 (en) * | 2013-05-30 | 2014-12-04 | Qualcomm Incorporated | Method and apparatus for transmitting symbol files |
Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5530808A (en) * | 1993-12-10 | 1996-06-25 | International Business Machines Corporation | System for transferring ownership of transmitted data packet from source node to destination node upon reception of echo packet at source node from destination node |
US5684984A (en) * | 1994-09-29 | 1997-11-04 | Apple Computer, Inc. | Synchronization and replication of object databases |
US5724575A (en) * | 1994-02-25 | 1998-03-03 | Actamed Corp. | Method and system for object-based relational distributed databases |
US5729735A (en) * | 1995-02-08 | 1998-03-17 | Meyering; Samuel C. | Remote database file synchronizer |
US5732219A (en) * | 1995-03-17 | 1998-03-24 | Vermeer Technologies, Inc. | Computer system and computer-implemented process for remote editing of computer files |
US5734823A (en) * | 1991-11-04 | 1998-03-31 | Microtome, Inc. | Systems and apparatus for electronic communication and storage of information |
US5737539A (en) * | 1994-10-28 | 1998-04-07 | Advanced Health Med-E-Systems Corp. | Prescription creation system |
-
1998
- 1998-04-14 WO PCT/US1998/007337 patent/WO1998054631A2/en active Application Filing
- 1998-04-14 AU AU69678/98A patent/AU6967898A/en not_active Abandoned
Patent Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5734823A (en) * | 1991-11-04 | 1998-03-31 | Microtome, Inc. | Systems and apparatus for electronic communication and storage of information |
US5530808A (en) * | 1993-12-10 | 1996-06-25 | International Business Machines Corporation | System for transferring ownership of transmitted data packet from source node to destination node upon reception of echo packet at source node from destination node |
US5724575A (en) * | 1994-02-25 | 1998-03-03 | Actamed Corp. | Method and system for object-based relational distributed databases |
US5684984A (en) * | 1994-09-29 | 1997-11-04 | Apple Computer, Inc. | Synchronization and replication of object databases |
US5737539A (en) * | 1994-10-28 | 1998-04-07 | Advanced Health Med-E-Systems Corp. | Prescription creation system |
US5729735A (en) * | 1995-02-08 | 1998-03-17 | Meyering; Samuel C. | Remote database file synchronizer |
US5732219A (en) * | 1995-03-17 | 1998-03-24 | Vermeer Technologies, Inc. | Computer system and computer-implemented process for remote editing of computer files |
Cited By (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2000045303A1 (en) * | 1999-01-28 | 2000-08-03 | Webspective Software, Inc. | Web server content replication |
WO2000045300A1 (en) * | 1999-01-28 | 2000-08-03 | Webspective Software, Inc. | Web server content replication |
GB2362974A (en) * | 1999-01-28 | 2001-12-05 | Webspective Software Inc | Web server content replication |
GB2363494A (en) * | 1999-01-28 | 2001-12-19 | Webspective Software Inc | Web server content replication |
GB2363494B (en) * | 1999-01-28 | 2003-10-15 | Webspective Software Inc | Web server content replication |
GB2362974B (en) * | 1999-01-28 | 2003-12-17 | Webspective Software Inc | Web server content replication |
US7630989B2 (en) | 2002-05-17 | 2009-12-08 | Colonial First State Investments Ltd. | Transaction management system |
WO2014193638A1 (en) * | 2013-05-30 | 2014-12-04 | Qualcomm Incorporated | Method and apparatus for transmitting symbol files |
Also Published As
Publication number | Publication date |
---|---|
WO1998054631A3 (en) | 1999-03-11 |
AU6967898A (en) | 1998-12-30 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8800023B2 (en) | Remote access architecture enabling a client to perform an operation | |
US7441029B2 (en) | Storage system managing data through a wide area network | |
JP5716134B2 (en) | Method and apparatus for remotely updating a running process | |
JP5945031B2 (en) | Provision and manage replicated data instances | |
AU2004279162B2 (en) | System and method for a software distribution service | |
US6662198B2 (en) | Method and system for asynchronous transmission, backup, distribution of data and file sharing | |
EP1014266B1 (en) | Method, apparatus and program storage device for a client and adaptive synchronization and transformation server | |
CN102394872B (en) | Data communication protocol | |
EP1636711B1 (en) | System and method for distribution of software licenses in a networked computing environment | |
KR100729288B1 (en) | Web server content replication | |
US20030009752A1 (en) | Automated content and software distribution system | |
US20020004824A1 (en) | Method and apparatus for automatically deploying data and simultaneously Executing computer program scripts in a computer network | |
WO2003034259A1 (en) | Deployment of business logic software and data content onto network servers | |
JP2003524255A (en) | Internet based remote data and file recovery system and method | |
US8341127B1 (en) | Client initiated restore | |
EP1181652B1 (en) | Extended file system | |
US20040216126A1 (en) | Method, system, and article of manufacture for agent processing | |
JP5354768B2 (en) | Software automatic distribution system | |
WO2006138308A2 (en) | System and corresponding method for providing redundant storage of a data file over a computer network | |
WO1998054631A2 (en) | System for network file distribution | |
Cisco | Preparing to Install CiscoWorks | |
US11461192B1 (en) | Automatic recovery from detected data errors in database systems | |
US10824748B2 (en) | Method and system for low overhead control/status handshake for remote shared file server | |
KR100382246B1 (en) | Method for Data Recovery Using the System Comprising Server and Client | |
Konstantinov | Automated Web Application Monitoring |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AK | Designated states |
Kind code of ref document: A2 Designated state(s): AU CA CN JP |
|
AL | Designated countries for regional patents |
Kind code of ref document: A2 Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE |
|
DFPE | Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101) | ||
AK | Designated states |
Kind code of ref document: A3 Designated state(s): AU CA CN JP |
|
AL | Designated countries for regional patents |
Kind code of ref document: A3 Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE |
|
121 | Ep: the epo has been informed by wipo that ep was designated in this application | ||
122 | Ep: pct application non-entry in european phase | ||
NENP | Non-entry into the national phase in: |
Ref country code: CA |
|
NENP | Non-entry into the national phase in: |
Ref country code: JP Ref document number: 1999500658 Format of ref document f/p: F |