JP2006251892A - System and method for managing web content update history - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To browse a Web page on which the update of Web content is reflected in a real time while performing update history management in a real time. <P>SOLUTION: This Web content update history management system is provided with such means arranged in Web servers (WEB1, WEB2) as a means for receiving the file name of an update file from the communication terminal of a content preparer, and for preparing a file in each of two different storage regions and a means (NFS) for overwriting packets (A, B, C, D) configuring the update file received from the communication terminal of the content preparer on the files prepared in those two different storage regions. Thus, it is possible to browse a Web page on which the update of Web content is reflected in a real time. <P>COPYRIGHT: (C)2006,JPO&NCIPI

Description

  The present invention relates to a system and method for managing an update history of web content. More specifically, the present invention provides a centralized management of update history of web content, particularly web content that is frequently updated by a plurality of content creators. The present invention relates to a web content update history management system and method capable of reproducing content.

  At present, when personal computers and mobile phones with an Internet connection environment have become widespread, it is extremely common to browse web pages (also called web sites, home pages, etc.) and obtain various information. That is. The web page is kept up to date by updating the content published and viewed there. That is, the content that is published and browsed on the web page changes with the lapse of time due to continuous content updates.

  The frequency of web page updates varies, for example, from when updates in seconds are made repeatedly and continuously to when they are updated about once every few days. Examples of web pages that are frequently updated include the progress of sports matches, stock transactions and exchange rates, disaster information such as typhoons and earthquakes, and election information. Web pages that provide this type of information require a quick release of the content. If various procedures are required until the release, and there is a delay, the information may already be obsolete at the time of release.

  Although the web content is continuously updated in this way, it may be necessary to reproduce the content that was released at a specific point in time. For example, there is a case where it is desired to know whether or not the information A has already been published on the web page B at 10:00 am Japan time on December 1, 2004. In addition, it is a case where it is desired to know what kind of contents can be browsed on the web page C at midnight on the east coast time of the United States on January 1, 2000. If the content on the web page is updated by only one content creator, it will be relatively easy to reproduce. If the content creator keeps a log of the files uploaded to the web page, it is clear how many updates have been made up to a certain point in the past, and at that particular point in time the web page This is because it is easy to see what kind of content was released. However, the situation is different when there are many content creators who update content instead of one.

  In this specification, web content (also simply referred to as content) is information that constitutes a web page (also referred to as a web site, home page, etc.) and is accessed using a web browser. This is a general term for text data, image (still image, moving image) data, audio data, etc.

  In this application, the applicant wants to propose that if there are multiple content creators and the web content is updated as a whole of a number of files uploaded individually by each content creator, the web content is updated. A system and method that enables content history update management so that web content at a certain point in time in the page can be easily reproduced.

  Before describing such a system and method, first, as a background, we would like to consider a content history management and reproduction method that has been widely used. First, there is a method in which each of a plurality of content creators manages their own update history and reproduces the content using the history individually managed by the content creator's terminal. Secondly, all the content creators once register the content to be uploaded for update once on the dedicated server for history management, and the content once registered on the history management dedicated server in this way, There is a method of registering to a public web server at once. Thirdly, there is a method for periodically storing contents of a public server in which contents uploaded from a plurality of content creators are registered.

  However, each of the conventional methods as described above has problems, and it is not always easy to reproduce the web content at a specific point in the past. In the first method, a content update history is stored on each of a plurality of content creators. In other words, a record of when and what kind of file is uploaded is stored on the computer of the producer 1, and a record of when and what file is uploaded is stored on the computer of the producer 2. As a result, only an individual upload history for each content creator remains. It is not easy to reproduce web content at a specific point in time from such individual history. Also, since history management is entrusted to the content creator, the burden of history management increases in proportion to the amount of content produced.

  Next, in the second method, a first server (history management server), which is a destination to which the content creator uploads an update file, and a person who intends to view a web page access using a browser. 2 servers (public servers) are separated. In other words, the content to be released on the second server is temporarily stored in the first server that manages the update history as a total of many files uploaded from many content creators via the Internet or dedicated lines. be registered. Then, the file group constituting the content registered in the first server is transferred to the second server. When transferring, it depends on how the first server and the second server are connected, but basically, each file format that constitutes the file group is maintained. Forwarded. Web content is not just composed of relatively small text files. Some files are relatively large, such as audio files and image files containing moving images. Therefore, a certain amount of time is required to move all the files constituting the web content from the first server to the second server. As described above, according to the second method, it is possible to reproduce the published content as a whole. However, in order to publish content, a pre-publication procedure of registration in the update management server is required. Therefore, there is a possibility that a delay occurs between the update and the release, which can be said to be a problem associated with the content to be updated in real time being the history management target. In addition, a dedicated system for managing the update history is required. Furthermore, since the registration work in the update history management server is a burden on the content creator, it may be difficult to introduce such a system itself.

  As described above, in the second method, a time delay may occur because the content once uploaded to the update history management server is moved to the publishing server. This delay appears as a problem that it takes time to update the web content for those who access the public server and browse the web page. On the other hand, for content creators, this delay appears as a problem that uploading update files does not proceed well.

  Finally, in the third method, it is impossible to completely reproduce the content unless there is a certain condition between the timing of storing the content and the timing of updating the content. is there. For example, let us consider a case where update 1 and update 2 of content are performed in this order. In this case, if the content storage 1 is performed before the update 1 and the storage 2 is performed after the update 2, that is, the two storages and the two updates are storage 1, update 1, update 2, and storage. Assuming that they occurred in the order of 2, the content between update 1 is completed and update 2 is started is changed by update 2 before saving 2, so it cannot be reproduced afterwards. .

  According to the present invention, a client terminal having an Internet connection environment, a web server in which a web page that can be browsed by designating a predetermined URL in the client terminal is installed, and a communication line including the Internet A web content update history management system including a communication terminal accessible to the web server and providing update data of web content constituting the web page is provided. The web content update history management system includes: (a) an update file that is in the web server and is transmitted from the communication terminal and updates the web content in response to a login from the communication terminal. (B) means for requesting the file name of the update file; and (b) means for transmitting the file name of the update file to the web server in response to the request for the file name in the communication terminal; Residing in the web server and in response to receiving the file name, creating a file having the received file name in each of two different regions in the web server, the two files (D) residing in the communication terminal, and responding to receipt of the notification, updating the update file to the client. (E) a file that is in the web server, receives the update file, and creates the received update file in each of the two separate storage areas; The client terminal can browse a web page in which the update of the web content by the communication end is reflected in real time.

  Further, in the system according to the present invention, by including the update time identification information in the file name created by the means (c), even the web content updated continuously in time is unique. Identification becomes possible.

  Furthermore, in the system according to the present invention, the means (e) has received (e1) the means for receiving the update file in units of packets constituting the update file, and (e2) the received packet. In order, it can comprise further the means to write in the two files created in each of the two separate storage areas.

  In addition to the definition of the web content update history management system described above, the present invention is a computer-readable storage storing a computer program that causes a computer to function as each means constituting such a system. It can also be grasped as a medium or such a computer program itself.

Hereinafter, embodiments of the present invention will be described in detail in the order of content installation, storage software, storage registration, and reproduction with reference to the accompanying drawings.
FIG. 1 shows a system configuration of a content update history management system according to the present invention. R in FIG. 1 is a router that performs packet routing. First, the web servers WEB1 and WEB2 publish content installed via a file server using a network file system (NFS). The NFS is a device for sharing content among the respective servers (web server, file server, application server), and includes a content publishing region, a content storage region, and an operation log storage. It is made up of an area for use. Next, the file servers FILE1 and FILE2 are servers to which the respective content producers connect in order to upload content, and from the respective content producers' communication terminals, the Internet (from the upper producer 1 in FIG. 1). And a dedicated line (in the case of connection from the producer 2 on the lower side of FIG. 1). The application server AP is a server for registering content stored under a different file name in the database server DB. Furthermore, the application server reproduces content that has been released at a certain point in the past. Finally, the database server DB accumulates information such as the newly registered content and the publication time of the updated content.

  In the system configuration of FIG. 1, two web servers (WEB1 and WEB2) and two file servers (FILE1 and FILE2) are also shown in FIG. 2 and subsequent figures. The reason that two are installed is to prepare for a case where data is damaged due to some reason by making it redundant (duplex). Since FIG. 1 assumes an actual system, such a redundant configuration is used. However, it should be added that the redundant configuration itself has been widely used and is not a configuration unique to the present invention. .

  FIG. 2 is a diagram in which an arrow indicating how a content creator uploads content for update is added to the system configuration diagram of FIG. Content is uploaded from each content creator via the Internet or via a dedicated line. Uploading via a dedicated line is, for example, in the same organization where the data center where the above-mentioned servers are located and the office where the content is created are connected by a dedicated line. This is the case. The content uploaded by the content creator is installed on the network file system NFS via the first file server FILE1 or the second file server FILE2 in which upload-only software is installed.

  Next, storage of content uploaded from each content creator will be described with reference to FIG. First, in order to upload the content, the content creator logs in to the file server through authentication using an ID, a password, etc. from his / her communication terminal such as a personal computer or a workstation (step 301). . After logging in, the file name (index.html) of the content to be transmitted is sent to the file server (step 302). When the file server receives the file name, the file server creates two files having file names designated by the content creator. One is a public file (step 303), and the other is a storage file for reproduction (step 303 '). Next, the content divided into a plurality of TCP packets (A, B, C, D in the example of FIG. 3) is transmitted from the content creator's communication terminal to the file server (step 304). . The file server receives the packets and writes the packets to each of the two files created in step 303 and step 303 '(step 305). Here, packets A, B, C, and D are written in both the public file and the storage (update history management) file. The upper side of FIG. 3 shows a state in which packets A, B, and C are sent in order, and the lower side of FIG. 3 shows that packets A and B are written in respective files for publishing and saving. Shows a state in which packets C and D are being sent. In step 305, the same packet is written in each of the two files. As a result, the two files, the public file and the storage file, have the same contents. Thus, in the present invention, two files having the same contents are created in different areas.

  As a result, it may seem similar to the second method described above as a prior art in that files having the same contents can be created. However, in the second method according to the prior art, as a result of the content creator uploading the update file to the update history management server, the update file is once registered in the update history management server. The registered update file is moved to the public server. It takes time to create two files by such a method. On the other hand, according to the storage operation of the present invention shown in FIG. 3, the update file sent from the content creator has already been created as a packet actually transmitted through the Internet or a dedicated line. It is written in two files for publishing and saving. Therefore, the time required to move update data once existing as a file to another server as in the second method according to the prior art is unnecessary, and two identical contents are updated simultaneously. A file is created.

  FIG. 4 shows how the content uploaded from the content creator is stored and registered. First, the status of content installation and operation by the content creator is recorded in a log, and the log is stored on the network file system NFS together with the content transferred by the user (step 401). Then, the application server AP confirms the accumulated log (step 402). The contents confirmed by the application server AP are reflected in the database server DB (step 403). Next, the contents accumulated for storage are moved to the hard disk on the application server AP (step 404).

  In particular, as described above in relation to FIG. 3, in the system according to the present invention, the content received for update received by the server is stored by simultaneously writing to two files in units of received packets. One file is for public use and is installed in the public area of the network file system NFS, and the other file is for storage and is installed in the storage area of the network file system NFS. At the same time that the content is installed in each area, the status of the operation of the content is recorded in the work log. The application server AP refers to the work log in a predetermined cycle, moves the storage content installed in the temporary area to the hard disk HDD connected to the application server AP, and simultaneously releases the content. Information such as time and installed directory name is registered in the database server DB. Based on the registered log information and content, the content published at a specific time is reproduced.

  As shown in FIG. 3, the content creator uploads the content to the file server, and the uploaded content is stored in the file server. A flowchart showing the flow is shown in FIG. Is shown in Further, as shown in FIG. 4, a flowchart showing a flow in which the content once uploaded is finally stored in the hard disk is shown in FIG.

  As described above, in the content update history management system according to the present invention, a mechanism for managing content history (“registration system”) is included in a public server system in which publicly available content is installed. The problem in the prior art is solved. In the second update history management method in the prior art described in the description of the background art, two separate servers for update history management and for public release are provided. On the other hand, in the present invention, uploading from a plurality of content creators via a plurality of networks by performing both the content update history management and the release of the latest content within a single server system. Content can be saved in real time.

  As in the first and third methods according to the prior art, in most update history management systems according to the prior art, the content uploaded from the content creator when updating the content is released as a single content for publication. Registered on the web server. On the other hand, in the present invention, when the web server receives the content for update transmitted from the content creator, the embedded registration system creates two files at the same time and receives them in each of the two files. The same data corresponding to the selected content is written. Thus, a public file and a storage file are created simultaneously. Even if content with the same name is updated continuously in a short time by adding the date and time of creation to the file for saving to enable unique identification, Can be stored and played back in an identifiable manner. When this registration system is used, the procedure for installing content on the web server is the same as the conventional procedure, and it is possible to handle content registration work and real-time updating.

  On the web server, in addition to creating a file for publishing and a file for saving, all the operations performed by each content creator to update existing content in parallel with it are dedicated. It is recorded as a log. Using this log, the actions of each content creator are registered in the history management system. Then, the history can be browsed based on the registered information.

  As described above, in the second method according to the prior art, uploading of the update file to the update history management server must be completed once. Therefore, as already pointed out, for content creators, there has been a phenomenon in which uploading work does not proceed smoothly. On the other hand, in the registration system according to the present invention, the contents of the update are written into two files in units of transmitted packets. In other words, it is a significant advantage that the management work of the update history is automatically executed and this management work proceeds without being particularly conscious of the content creator.

  Therefore, by using the registration system according to the present invention, it becomes possible to centrally manage the update history of individual web contents continuously updated by the content creator. Then, by using the update history managed in this way, the web content published at an arbitrary time on the web page is sent to the client terminal on the browsing side at that time. It is possible to reproduce it exactly as it is.

1 is a system configuration of a content update history management system according to the present invention. FIG. 2 is a diagram in which an arrow indicating how a content creator uploads content for updating is added to the system configuration diagram of FIG. 1. It is a figure which shows the aspect in which the content uploaded from each content creator is preserve | saved. Further details of how the content uploaded by the content creator is stored and registered is shown. FIG. 4 is a flowchart illustrating a flow in which a content creator uploads content to a file server and the uploaded content is stored in the file server as illustrated in FIG. 3. FIG. 5 is a flowchart showing a flow in which content once uploaded is finally stored in a hard disk as shown in FIG.

Claims (5)

A client terminal having an Internet connection environment, a web server in which a web page that can be browsed by designating a predetermined URL in the client terminal is installed, and the web server via a communication line including the Internet A web content update history management system including a communication terminal that is accessible and provides update data of web content constituting the web page,
(A) means for requesting a file name of an update file which is in the web server and is transmitted from the communication terminal and updates the web content in response to a login from the communication terminal;
(B) means in the communication terminal for transmitting the file name of the update file to the web server in response to the request for the file name;
(C) residing in the web server and in response to receiving the file name, creating a file having the received file name in each of two different regions in the web server; Means for notifying the client of the end of creation of two files;
(D) means in the communication terminal for transmitting the update file to the web server in response to receiving the announcement;
(E) means in the web server for receiving the update file and overwriting the received update file with a file created in each of the two separate storage areas;
It is possible to browse a web page in which the update of the web content by the communication end is reflected in the client terminal in real time while managing the update history of the web content in real time. Feature Web content update history management system.   2. The system according to claim 1, wherein the file name created by means (c) includes update time identification information, so that it is possible to uniquely identify web content that is updated continuously in time. A system characterized by 3. The system according to claim 1 or claim 2, wherein means (e) comprises:
(E1) means for receiving the update file in units of packets constituting the update file;
(E2) means for writing received packets in the two files created in each of the two separate storage areas in the order received;
A system characterized by further comprising:   A computer-readable storage medium storing a computer program that causes a computer to function as each means constituting the system according to claim 1.   A computer program for causing a computer to function as each means constituting the system according to claim 1.

Images