WO1999026165A1 - Procede et dispositif pour la mise a jour de donnees - Google Patents

Procede et dispositif pour la mise a jour de donnees Download PDF

Info

Publication number
WO1999026165A1
WO1999026165A1 PCT/JP1998/002550 JP9802550W WO9926165A1 WO 1999026165 A1 WO1999026165 A1 WO 1999026165A1 JP 9802550 W JP9802550 W JP 9802550W WO 9926165 A1 WO9926165 A1 WO 9926165A1
Authority
WO
WIPO (PCT)
Prior art keywords
shared data
data update
update request
order
data
Prior art date
Application number
PCT/JP1998/002550
Other languages
English (en)
French (fr)
Inventor
Takashi Sakakura
Original Assignee
Mitsubishi Denki Kabushiki Kaisha
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Mitsubishi Denki Kabushiki Kaisha filed Critical Mitsubishi Denki Kabushiki Kaisha
Priority to JP51656699A priority Critical patent/JP3617997B2/ja
Priority to US09/284,736 priority patent/US6981061B1/en
Priority to EP98924554A priority patent/EP0952510A4/en
Publication of WO1999026165A1 publication Critical patent/WO1999026165A1/ja

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G06F16/2365—Ensuring data consistency and integrity
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99931—Database or file accessing
    • Y10S707/99938—Concurrency, e.g. lock management in shared database
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99951—File or database maintenance
    • Y10S707/99952—Coherency, e.g. same view to multiple users

Definitions

  • the present invention relates to a data updating method and a data updating method in a computer system, and more particularly to a data updating method and a data updating method for updating shared data shared by a large number of user terminals connected to various communication environments.
  • Related. Background art
  • the quality of the communication line is guaranteed to some extent by the communication protocol.However, when using a wireless line such as a PHS (Personal Handyphone System) or a mobile phone, the line is disconnected, The connection status of the line is not always guaranteed, even when the line is not used. Also, the transfer speed is low. When attempting to perform transaction processing from a terminal that uses such a wireless line, invalid transactions are expected to occur frequently. Transaction becomes invalid The user is disadvantaged more, and the burden is increased as a system.
  • An object of the present invention is to provide a data updating method and method that can execute a data updating transaction fairly among users even when a terminal whose connection state cannot be guaranteed is used. Disclosure of the invention
  • a data updating method includes: a plurality of user terminals; and a server that manages shared data between users, wherein the plurality of user terminals and the server are located between the user terminals and the server.
  • Each of the user terminals holds a timekeeping function module that measures the time synchronized with each other in the above, and the user terminal sends the time acquired from the timekeeping function module at the time of the update request of the shared data and the data update request issue time
  • the shared data update request is sent to the above server, and the data update request issue time is the same as the time of the original transmission until the shared data update request is received by the server.
  • An update request transmission processing unit that repeatedly transmits the shared data as described above, and the server, based on the data update request issuance time attached to the shared data update request received from the user terminal, transmits the shared data And having a shared data management module that determines the data update order of.
  • the shared data management module includes an update rule management unit that sets an update request reception period, and an update request management unit that receives the shared data update request received during the update request reception period.
  • the update rule management unit further sets a valid update request issuance period included in the update request reception period, and the update request management unit sets the data update request issuance time of the received shared data update request to the valid update request issuance time. It is characterized in that it receives a shared data update request within the period.
  • the update request transmission processing unit sends a shared data update request including a data update condition.
  • the shared data management module examines the data update conditions included in the shared data update request in the order of the data update request issuance time, and determines that the data update condition is satisfied. When satisfied, the data updating unit determines a shared data update value in response to the shared data update request and updates the shared data to the shared data update value.
  • the data update unit examines the data update conditions included in the already received shared data update request in the order of the data update request issuance time, and when the data update condition is satisfied, c shared data management module and determining the shared data updated prediction value based on the shared data update request, a single authorization of the authorized strength is classified into predetermined stages to the user terminal And a user notification unit for selecting information to be transmitted to each user terminal according to the authority.
  • the user notification unit is characterized in that the update history of the shared data is transmitted only to the user terminals having authority of a certain level or more.
  • the user notification unit is characterized in that the content of the data update request from each user terminal is transmitted only to the user terminals having a certain level of authority.
  • the shared data management module has a user notification unit for notifying the user terminal when the shared data is updated.
  • the user notification unit is characterized in that the content of the notification includes at least information of a difference before and after the update of the shared data.
  • the user notification unit notifies a user terminal that has accessed the shared data before updating the shared data.
  • the user notification unit notifies the user terminal that has accessed the shared data within a certain period before updating the shared data, and the c user terminal transmits information to the server.
  • Send request and share data pipe The management module receives the information transmission request from the user terminal, examines the access history of the user terminal to the shared data, and determines that the user terminal has accessed the shared data before receiving the information transmission request. In some cases, a user notification unit that responds to the information transmission request is provided.
  • the user notification unit responds to the information transmission request when the user terminal has accessed the shared data within a certain period before receiving the information transmission request.
  • the information transmission request from the user terminal is a transmission request for the content of the data update request that has already arrived at the server and before the shared data update processing.
  • the user terminal transmits a condition for monitoring the update of the shared data
  • the shared data management module registers the transmitted condition, and transmits the shared data to the user terminal when the condition is satisfied by the update of the shared data. It is characterized by having a user notification unit that notifies the user of the update.
  • the user terminal transmits a condition for monitoring the update of the shared data
  • the shared data management module registers the transmitted condition
  • the shared data update predicted value is transmitted to the user terminal when the shared data update predicted value satisfies the condition.
  • the timing function module includes an encryption processing unit.
  • the timing function module is characterized in that it has a user terminal authentication function.
  • the server has a storage unit for storing a shared data update request queue in which the shared data update requests from the respective user terminals received by the shared data management module are arranged in the order of the data update request issue time. .
  • a data updating method includes: a plurality of user terminals; and a server that manages shared data between users.
  • the timekeeping function module of the plurality of user terminals and the timekeeping function module of the server are mutually connected. Synchronization step, and when the shared data update request is issued by the user terminal, the time obtained from the timing function module is attached to the shared data update request as the data update request issue time and sent to the server. Transmitting and repeatedly transmitting the data update request issue time at the same time as the original transmission until the shared data update request is received by the server; and updating the shared data from the user terminal by the server. Receiving the shared data update request, and based on the data update request issue time attached to the received shared data update request, Characterized by comprising the step of determining the new sequence.
  • the shared data update request is a sell order or a buy order including the first condition and the quantity condition, and is stored in the storage unit of the server in the form of the shared data update request queue so that the data update request issuance time is in ascending order. And has the following steps.
  • Step to step b) Read the corresponding orders from the shared data update request queue stored in the server storage unit in ascending order, and execute one of the following steps depending on whether there is a corresponding order that satisfies the first condition with the main order.
  • First condition comparison step to be executed b 1) If there is no corresponding order that matches the first condition, this main order is deleted from the shared data update request queue as an unsatisfied order, and the above (a) check is performed. Step back to the step;
  • FIG. 1 is a diagram of a configuration example of a system to which the present invention is applied.
  • FIG. 2 is a diagram of an example of incorporating a timing function according to the present invention.
  • FIG. 3 is a block diagram of the timekeeping function module according to the present invention.
  • FIG. 4 is a diagram of a configuration example of a shared data management server according to the present invention.
  • FIG. 5 is a diagram of a configuration example of a shared data management module according to the present invention.
  • FIG. 6 shows an example of an input screen of a terminal application using the present invention.
  • FIG. 7 is a flowchart of a shared data update request issuing process according to the present invention.
  • FIG. 8 is a diagram showing an example of shared data update request data according to the present invention.
  • FIG. 9 is a flowchart of a shared data update request receiving process according to the present invention.
  • FIG. 10 is a flowchart of a shared data update process according to the present invention.
  • C FIG. 11 is a diagram of an example of user ID data according to the present invention.
  • FIG. 12 is a flowchart of the notification service registration process according to the present invention.
  • FIG. 13 is a schematic diagram of a data monitoring registration queue according to the present invention.
  • FIG. 14 is a diagram of an example of a shared data update request queue according to the present invention.
  • FIG. 15 is a schematic diagram of a notification service registration table according to the present invention. BEST MODE FOR CARRYING OUT THE INVENTION
  • This product transaction system is a type of transaction system in which many users participate.
  • the system provides a virtual market, and participation in the market is possible only by using the terminals provided by the system. Participants can participate in the market fairly using not only wired terminals but also wireless terminals.
  • a user can access a wireless phone from mobile terminals 101 and 102.
  • Terminals connected to the intranet connected via a public network from a base station 107 via a public network 108 using a line, or via a personal computer PC 103, 1 Terminals connected to the same LAN (Loca 1 Area Network) to which the server 110 that manages shared data is connected may also participate from the beginning.
  • LAN Local Area Network
  • participants join from 6- Figure 1 shows the three types of communication media described above.
  • the mobile terminals 101 and 102 and the terminals 103 to 106 are collectively referred to as user terminals.
  • user terminals participating in this system hold a timekeeping function module 201 with a timekeeping function
  • the server 110 holds a timekeeping function module 402.
  • a terminal communication program 202 is installed in each user terminal in order to transmit and receive data or information to and from the server 110.
  • the terminal communication program 202 is an example of an update request transmission processing unit.
  • the update request transmission processing unit has a shared data update request transmission function described later.
  • the terminal communication program 202 can be used only by a specific user, and has a function of confirming the user with a password. Also, a memory 203 is installed in each user terminal.
  • the same timer function module 201 is used for all user terminals including the mobile terminal 101.
  • the timekeeping function module 201 is detachable from each user terminal, and is validated by the system administrator after authentication and time setting to the standard time adopted by this system. Be distributed. For example, when the system is applied to the commodity trading market, the system administrator should strictly control the timekeeping function module 201 because the market auditing organization should do it.
  • the timing function module 201 is realized as a PC card in this system.
  • FIG. 3 shows a functional block diagram of the above-described clocking function module ⁇ ′01.
  • 310 is PC card interface logic
  • 302 is internal bus
  • 303 is knock-up battery
  • 304 is encryption and control logic
  • 305 is clock
  • Reference numeral 6 denotes an authentication data storage EP ROM (Erasab 1 e Programmable Read Only Memory).
  • the Control Logic 304 incorporates a clock synchronization host authentication port magic, which allows the clock 305 to be synchronized with the standard time of the system described later and user authentication to the EP ROM 306. Initial settings for data setting are made, and the clock function module 201 becomes valid.
  • This clock setting and user authentication data setting are performed by the system administrator.
  • the terminal communication program 202 detects whether or not the timekeeping function module 201 is mounted on the user terminal, and further, if the timekeeping function module 201 is mounted on the user terminal. Data or information can be transmitted and received only when a correct passcode is input, and the terminal communication program 202 can be used by the user.
  • Fig. 4 shows the functional configuration of the server 110, which is the shared data manager in this system.
  • C The shared data in this system is record data of each table in the database DB.
  • server 110 Connected to LAN 401, server 110 is used from each user terminal.
  • the clock function module 402 for the server is the standard time of this system, and the clock that serves as the reference for the clock function module 201 of each user terminal Holding.
  • the clock of the timekeeping function module 201 of each user terminal is adjusted by the system administrator so as to match this clock.
  • 4 0 3 update request storage disk the 4 0 4 shared data management Mojiyu Lumpur, 4 0 5 is shared data storage disk: 4 0 6 c 1 1 0 0 is a memory utilized for later It is a user management table.
  • the shared data management module 404 accepts a shared data update request from a user, and performs an update request management unit 501 that stores and manages the data, and provides a data update status notification service to various users.
  • User notification section 502 Update rule management section 503 that sets the update request acceptance period and arbitrates for updating shared data, and updates shared (queued) update request data to shared data. It is composed of a data update unit 504 for updating.
  • the user terminal has a PC card interface, When the terminal communication program 202 confirms that the user has entered the correct passcode, the terminal communication program 202 at the user terminal is used. It becomes possible.
  • the present embodiment shows an example in which the present system is applied to a merchandise trading system.
  • the buy order screen prepared by the terminal communication program 202 on the user terminal is shown in FIG. 6 (a). Shown in
  • FIG. 6 0 1 is an order screen for interactively setting a product ID (identification), a buy quantity, and a buy price condition.
  • the product ID in Figure 6 represents an orange harvested in mid-February c
  • Fig. 6 (b) shows the sell order screen.
  • the sell quantity is input.
  • the user After setting the product ID, sales quantity and selling price condition, the user checks the display screen and presses the 604 send button.
  • the above-mentioned purchase price or sale price is the first condition in the present invention.
  • the terminal communication program 202 changes the available communication media and the configuration A buy order or a sell order, that is, a shared data update request is transmitted to the server 110 according to the server address registered as the application data.
  • the transmission procedure to the server 110 after the terminal communication program 202 receives a purchase order or a sales order from a user will be described with reference to the flowchart of FIG.
  • the terminal communication program 202 uses separate screens for buy orders and sell orders in order to prevent erroneous operations by the user, but the update processing is the same. Hereinafter, this is described as a buy order.
  • the server address is obtained from the timekeeping function module 201 in step 701.
  • the server address is represented by an IP (Int er n e t P ro t o c o l) address.
  • the purchase order data given by the user in step 702 is arranged in a format accepted by the timekeeping function module 201, and is formatted in step 703 by the timekeeping function module 201 to 703. Enter buy order data.
  • the timing function module 201 generates the update request data 800 in the format shown in FIG. 8 based on this input, and encrypts the update request data 800 with the symbol key given at the time of initial setting. I do.
  • the update request data 800 is composed of a user ID 8001, which identifies the user, a transmission time 800, which is a data update request issuance time in the present invention obtained by the clock function, and a table ID 800, which indicates a product genre. 3. Record ID 800, meaning the same as the product ID, operation on quantity data
  • the transmission time was September 17, 1997, 11:03:32, 12:12
  • the table ID was fruit
  • the record ID was orange harvested in mid-February. This means a purchase order with a quantity of just 200 pieces and a buy price of 350 or less.
  • the terminal communication program 202 receives the encrypted update request data 800 from the timekeeping function module 210 (step 704).
  • the terminal communication program 202 transmits the update request data 800 encrypted in step 705 to the server c
  • Transmission to the server is not always successful depending on the communication media used by the user terminal as described above.
  • the user terminal retries until communication is successful.
  • the terminal communication program 202 does not change the transmission time 8002 of the update request data 800, and retransmits using the same transmission time 8002 as the original transmission. I do.
  • TCP fransationtContRotlProtColl
  • the user Since the encrypted update request data 800 is valid as long as it arrives within the update request acceptance period of the server, if the communication fails, the user updates the update request data 800 stored in the user terminal. 0 can be transmitted using another communication medium-Of course, the user terminal can also store the update request data 800 in the memory 203.
  • the server 110 When the server 110 receives the update request data, it receives an acknowledgment message. To the user terminal. The user terminal receives the acknowledgment message from the server 110 in step 706, and confirms whether the server 110 has accepted the update request (it may not be accepted if it is not within the acceptance period) Notify the user.
  • the update rule management function is provided in the update rule management unit 503, and manages update request reception time, manages the validity of update request issue time, and controls shared data update.
  • the data update process is set to start when the reception ends at 9 PM.
  • the update request management unit 501 has a function to receive a shared data update request from a user. Generate and manage one. This processing flow will be described with reference to FIG.
  • This process operates in an independent context and constantly monitors for incoming update requests from user terminals. Strictly speaking, a new context is generated by an incoming connection request, a global lock in one of the update request queues is obtained, and the processing of step 9 () 1 and subsequent steps is performed; The flow is described as loop processing. When update requests arrive at the same time, the processing is serialized, but this does not affect the fairness of transactions between users.
  • step 901 upon receiving the encrypted update request data 800, the update request data is decrypted to obtain the update request data 800 shown in FIG.
  • step 902 the user ID in the update request data is checked, and if the user ID is invalid, the user is notified in step 906 that the update request has not been registered due to the ID illegality.
  • step 903 an inquiry is made to the update rule management section 503 to determine whether or not the transmission time attached to the update request data 800 is within the valid update request issuance period, and the arrival time is within the update request acceptance period. After examining whether or not any of them is within the predetermined period, the user is notified of the rejection of the renewal request registration together with the reason in step 906 as well.
  • the update request data 800 in FIG. 8 contains two queue link pointers for registering on the update request queue. Then, add the address of the user for reply to the user and insert it in the update request queue in ascending order of transmission time (early time).
  • FIG. 14 shows an example of the configuration of an update request queue (hereinafter simply referred to as a queue) created in the memory 406.
  • Reference numeral 1401 denotes an update request queue illustrated in FIG. —Header that manages —: Three queue data are queued in the header.
  • a queue link pointer 1443 indicating the previous queue data on the queue and a boquelink interface 1444 indicating the rear queue data
  • the data to which the user address (port address) 1402 is added constitutes each cue data.
  • Each queue data has a fixed length, and a memory area large enough for queuing is used in a fixed manner. This area is called a memory pool.
  • the memory pool allows the memory area to be reused by operating the queue link pointer.
  • Step 905 the contents of the memory pool corresponding to the memory pool of the relevant update request queue (which is an example of the storage unit) are written to the update request storage disk 403 in Step 905, and in Step 907, The server 110 notifies the user that the update request has been accepted and registered.
  • step 908 the update request is transferred to the user who has registered the transfer request of the update request data 800 in advance.
  • the registration of the transfer request of the update request data 800 will be described in “6. Update User Notification Function” below.
  • This function is a function of the data update unit 504, and the operation of this function according to the update rule, the dequeuing of the update request data 800, and the mechanism for examining the update request will be mainly described.
  • the data update function is updated at 9:00 pm on the market business day Triggered by the rule management function:
  • the result is that data updates are processed in batches, but of course this is not a limitation of the present invention.
  • step 1001 Since the update request queue has already been organized for each record based on the update request issue time of the user, this update process is executed in step 1001 in the order of the oldest issue time for each record.
  • the queue data is processed as described below, and the processed queue data is dequeued (deleted). This processing ends when the processing of the queue data of all update request queues is completed.
  • step 102 the purchase order and the sell order in the update request queue are collated. If the queue data at the head of the update request queue (the order of the oldest update request among the unprocessed queue data) is a buy order, the queue data of the sell order is searched in ascending order, and the found sell order is searched. On the other hand, it is checked whether the prices match in step 1003. If they match (if the selling price is the buying price), then in step 104, compare the quantity of this selling order with the quantity of the buying order, and if the quantity of the selling order satisfies the quantity of the buying order, (If the quantity of the sell order ⁇ the quantity of the buy order), the transaction is assumed to have been completed and the price is registered in the database.
  • the queue data of the established buy order and the queue data of the sell order are dequeued in step 110.
  • the quantity of the sell order is larger (the quantity of the sell order> the quantity of the buy order), and there is a remaining quantity, this new quantity (the remaining quantity-the quantity of the sell order minus the quantity of the buy order) is newly added. Reset the quantity for this sell order.
  • the cue data of the buy order is dequeued (Step 1 0 1 0) c If the price or quantity does not match, return to Step 1 0 2 to search for the next candidate.
  • the queue data of the sell order is read, and a search is made for a sell order that satisfies the price and quantity. If no sell order satisfies the conditions, the buy order is not satisfied.
  • the queue data of the unsuccessful buy order is dequeued (step 1009). If the c is equal to or larger than c , the buy order is the main order and the sell order is the corresponding order in the present invention.
  • the queue data at the head of the update request queue is a sell order
  • the same processing is performed for buy orders on the queue.
  • the sell order is the main order in the present invention
  • the buy order is the corresponding order.
  • step a) If the sale is completed, that is, if the update condition is met, step
  • the shared data is updated with the operation 805 (subtract if buying, add if selling) and operand 806 (product quantity in this system) set in the update request data in 1005. That is, the data of the record in the database used by this system is updated.
  • the clearing associated with the sale of goods is performed in the clearing bank account 808 set in the update request data 800.
  • the user terminal can also use the terminal communication program 202 to inquire about the result of the update request sent by the user terminal.
  • the difference data between the pre-update record and the post-update record of the updated record is transmitted to the user who has previously registered the update notification request of the shared data in step 1007. Registration is described in “6. Update Content User Notification Function” below.
  • This function is a function of the data updating unit 504, similar to the data updating function.
  • the data update function is to finalize the selling price by comparing the queue data of the sell order and the buy order after the end of the update request acceptance period (in the present embodiment, 9:00 pm).
  • the queue data storing the buy order and the sales order received during the valid update request issuance period (in the present embodiment, 9:00 am to 3:00) is stored at regular intervals within the valid update request issuance period (for example, 1 to 1). (Every 0 minutes), and the price of the sale that is established at that time is used as the price prediction value.
  • This function is a function of the user notification unit 502.
  • the user ID is registered as the management data of the server 110 when the user is registered to the server 110 by the timekeeping function module 201.
  • the server 110 Is also registered with the user's authority. This authority is granted according to the performance in the commodity trading market, and the user can use the following data provision services according to the authority. Authority is given in three stages, Authority 1 to Authority 3.
  • Authority 1 Can be notified when shared data is updated.
  • This right 1 is the right to receive the update notification of the shared data described in “4. Data update function” above.
  • Authority 2 Can receive the content of the shared data update request managed by the server before updating the shared data.
  • This authority 2 is the authority to receive transfer of update request data described in “3. Shared data update request management function” above.
  • Authority 3 Obtain past shared data update history.
  • An update history of shared data can be obtained over the past.
  • authority 2 includes authority 1
  • authority 3 includes authority 1 and authority 2.
  • the authority of the user is registered in any of 1, 2, and 3.
  • the authority is checked and the registration process to the data reference service is performed.
  • FIG. 11 shows a user management table 110 of the system for managing the registered contents, which is stored in the update request storage disk 403.
  • the user ID is stored in 1101, and the user authority described above is registered in 1102. After 1103, the shared data update request history issued by this user is registered.
  • the shared data access of the system according to the present embodiment is performed by requesting the server 110 for updating, but the reading is performed by each user directly accessing the database. I have. Therefore, only the issuance of a shared data update request is focused on as the access history, but this is not a limitation of the present invention.
  • Figure 12 shows the user registration process flow for the update content notification service.
  • the user registration process flow shown in Fig. 12 is used in the notification service for shared data update corresponding to authority 1 and the sequential reporting service of update request data corresponding to authority 2.
  • a registration request for a notification service is received from the user in step 1221, the authority of the user is checked in step 122, and if the user is authorized to receive the notification service, the authority shown in Fig. 15 is determined.
  • the entry 1503 and 1504 are added to the notification service registration table 1501 and 1502, and the user is notified that the notification service has been registered.
  • Notification service registration table 1501 and 1502 use the user management table 1100 Entry 1503, which is a user pointer, and entry 1504, which is notification restriction information based on data access history, are stored. If the authority of the user does not match the notification service, the user is notified in step 1244 that the user has not been registered in the notification service registration table.
  • the data update unit 504 issues a notification of update to a user (user with authority 1) who has registered a shared data update notification request in advance when shared data is updated.
  • a user user with authority 1
  • the shared data update processing in step 1005 operates due to the restriction based on the data access history.
  • the entry 1505 in the notification service registration table 1501 and 1502 is 0 if there is no limit, and if it is limited to records that have been accessed once, it is the last one. If the access is limited to a certain period, the period is registered in hourly units. When 0 is registered as the entry, the difference data is transmitted unconditionally (the user can choose to be notified only of the update if desired). If 1 is registered, the user management table 1100 is accessed from the user pointer to the user management table 1100, and the user has access to the record in the past. Refer to the shared data update history 110-115 to determine whether or not access has been made, and if so, send differential data. If the reference validity period is registered, the last access time (update request issue time) of the record in the history information is referenced, and there is an access history of the record, and the last access time is within the validity period. If so, send the difference data.
  • the update request data 8000 is sent to the user (authority 2 user) who has registered the transfer of the shared data update request data 8000.
  • the user authority 2 user
  • the same processing as in 1 0 0 5 described above is Nawa line
  • the user can request notification of the update history of the shared data and the update request data 800 before the update of the shared data.
  • This system has a port for querying shared data update history and a port for querying update request data.
  • the update history of the shared data is realized by a database logging function, and the user specifies the table, record, and period, and the data is sent to the port for querying the shared data update history of the server.
  • the server checks the authority of the user, makes an inquiry to the database, and returns the update history of the record for the period of requesting the history from the user to the user.
  • the user can specify the update request data 800 before the update of the shared data by specifying a table, a record, specifying only records that have been accessed, or specifying only records within a certain period of time since the last access. Conditions can be combined and requested.
  • the server 110 Upon receiving the above request from the user to the update request data inquiry port, the server 110 checks the user authority, searches for update request data to be held and managed in the queue in the order of the oldest request reception, and checks the condition. Create a list of items that match the requirements and return to the user.
  • the server 110 receives the update request data 800, it acquires the exclusive control lock of the update request queue and updates the update request data 800.
  • the search process is executed while releasing the exclusive control lock of the update request queue appropriately.
  • the present system has a function of monitoring shared data and a predicted value.
  • the c monitor function monitors the shared data itself and the predicted value calculated from the update request by the server 110. For example, users can monitor the remaining quantity and trading value for a record, that is, the stock.
  • This system has a monitor registration port that receives a request to monitor shared data and a monitor registration port that receives a request to monitor a predicted value. The user sends a monitor request to the server by specifying a table, record, and monitor conditions in one of the monitor registration ports, either the shared data of this server or the predicted value from the update request. After checking the user's authority (monitor of shared data is available to all users, monitoring of predicted values requires two or more authorities), and the server is configured as shown in Fig.
  • the header of 0 1 is a hash key, which is connected to a hash link 1 399 consisting of a monitor service registration table 13 21 1 to 13 23.
  • FIG. 13 Although only one queue is shown in FIG. 13, there are two queues for registering a monitor request to the monitor queue 1303: a request to monitor shared data and a request to monitor a predicted value.
  • the monitor service registration table 1 3 2 for the shared data of the record concerned Search the monitoring conditions in 1 to 1 3 2 3 and notify the user who satisfied the conditions by the current change.
  • the user of the first monitor service registration table of the monitor has set two conditions: the transaction value of 1303 and the quantity of 1304. When one of the conditions is satisfied, a notification is issued.
  • the buy order and the sell order are the orders in the product transaction, but may be not only the order in the sale of the product, but also the inventory management in the supermarket, for example.
  • the stock replenishment request corresponds to a buy order and the stock replenishment corresponds to a sell order.
  • Reorders can be other forms that correspond to supply and demand for a system.
  • the valid update request issuance period is set from 9:00 am to 3:00 pm
  • the update request acceptance period is set from 9:00 am to 9:00 pm. It may be set in minutes or days.
  • each of the above modules and units may be realized by software, may be realized by hardware, or may be realized by a combination of software and hardware.
  • the shared data is updated based on the data update request issuance time, and thus depends on the communication connection state between the user terminal and the server. Not perform fair data updates.
  • the system can be operated flexibly by the method of setting the request acceptance period or the method of setting the valid update request issuance period.
  • user terminals can flexibly use the system by setting data update conditions.
  • the user terminal can efficiently evaluate its own shared data update request.
  • the server notifies the user terminal when the shared data is updated, so that the user can make efficient decisions.
  • the content of the above notification includes at least information on the difference between before and after the update of the shared data, the user can easily reproduce the shared data.
  • the user terminals that the server notifies are limited to the user terminals that have accessed the shared data before the update of the shared data, so that the system load and the user load are reduced. Operation can be tailored to your needs.
  • the user terminals that the server notifies are limited to the user terminals that have accessed the shared data within a certain period before the update of the shared data. Operations can be tailored to your needs.
  • the server examines the access history of the user terminal to the shared data and determines that the user terminal accessed the shared data before the request. Only when there is a response to the information transmission request, the system can be operated according to the load on the system and the needs of the user.
  • the server responds only when the user terminal has accessed the shared data within a certain period of time before the request, so the server responds to the system load and the needs of the user. Operation becomes possible.
  • the information transmission request is a transmission request for the content of the data update request that has already arrived at the server before the shared data update processing, Operation can be tailored to the needs of the user.
  • the user terminal registers conditions for updating the shared data, and the shared data manager notifies the user terminal when the conditions set by the user terminal are satisfied by updating the data in the server. As a result, users can monitor the update of shared data.
  • the user terminal registers conditions for updating the shared data, and the server determines whether the shared data update predicted value according to the data update request from the user terminal or another user terminal is used by the user terminal. Since the user terminal is notified when the set conditions are satisfied, the user can know the predicted value of the shared data.
  • timekeeping function since the above timekeeping function is provided with an encryption process that can be decrypted only by the system administrator, it prevents improper updating of time-series data.
  • the server stores the shared data update request from the user terminal in memory, so even if a failure occurs in the administrator system, the received data update is correctly converted to shared data after the administrator system is restored. It can be reflected.
  • the common data update request is a sales order or a buy order including the first condition and the quantity condition.
  • the shared data update request queue holds the data update request issuance time in ascending order.
  • a sell order that satisfies the first condition is searched for in ascending order, and if the first condition is satisfied, then whether or not the condition of the quantity is satisfied is searched.
  • the order is a sell order, the selling order is searched in ascending order for a buy order that meets the first condition, and if the first condition is met, then the quantity condition is met. Since so as to search for or Ukado, efficiently buy and sell orders that condition is met it is possible to search for order c

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • General Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Computer Security & Cryptography (AREA)
  • Databases & Information Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • Technology Law (AREA)
  • General Business, Economics & Management (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Mobile Radio Communication Systems (AREA)

Description

明 細 書 データ更新方式及びデータ更新方法 技術分野
本発明は、 計算機システムにおけるデータ更新方式及びデータ更新方 法に関し、 特に、 多様な通信環境に接続された多数の利用者端末で共有 される共有データの更新を行なうデータ更新方式及びデータ更新方法に 関する。 背景技術
従来から計算機システムにおいて、 2つ以上の実行単位がデータを共 有し、 各々の実行単位が共有データの更新を行なう場合、 共有データの 一貫性をいかに維持するか、 また、 各々の実行単位が各々に共有データ のコピーを持つ場合、 オリジナルの共有データと各々のコピーデータ、 また、 各々のコピ一データ同士の一貫性をいかに維持するかがさまざま なレベルにおいて問題となってきた。 たとえば、 共有メモリ型のマルチ プロセッサ計算機で各 C Pし 1 (セン トラルプロセッシングユニッ ト） が 共有メモリのデータ更新を行なう場合、 テス トアン ドセッ ト命令によつ て共有メモリ上のデータをもとに排他制御を行ない、 同時書き込みによ つてデータ一貫性が損なわれるのを防ぐ、 また、 各々の C P Uがキヤッ シュメモリを持つ場合、 ライ トスルー、 コピーバック、 .及びスヌーピン グの利用といった解決策によ り C P U間のキャッシュデータのー貫性を 守ってきた。
また、 プロセス間で共有されるファイルもその一例である。 複数のプ ロセスからのアクセスを許しても厳密なフアイルデータの一貫性は求め ない、 あるいは、 データの一貫性を重視する場合、 性能を犠牲にしても セマフォ口ック機構によるプロセス間の排他制御を行なう といった対応 がなされてきた。 この他にも、 データ一貫性に関する技術はその枚挙に 暇がない- 具体的な技術の一例と して、 特開昭 6 2— 2 0 6 9 3 5には システム資源の排他制御のための制御フアイルァクセスを更新キユーと 処理タスクによってシリアライズする技術が開示されている c
本発明がその主な適用先とする応用プログラムレベルにおいて、 デー タ一貫性が重視される問題の一つがデータベースによる トランザクショ ン処理である。 銀行口座や在庫管理など厳密な商取り引きを電子的に具 現化する もので、 A C I D (A t o m i c i t y , C o n s i s t e n c y， I s o l a t i o n a n d D u r a b i l i t y ) プロノ テ ィ と呼ばれる特性を満足するものでなければならないとされている。 す なわちシステムで扱われる一つ一つの トランザクショ ンは、 「分離でき ない」 もの、 「データの一貫性を損なわない」 もの、 「他トランザクショ ンとは隔離されている」 もの、 「データは決して失われない」 ものでな ければならない。
この特性を実現するために従来のシステムはトランザクションは同期 的に処理されるものと してきた。 つまり、 ある端末からデータベースデ ータの更新を実行する場合、.データベースに接続し、 データベースの更 新権を得て、 データ参照、 更新を行ない、 データベース更新命令 （コミ ッ ト） を発行して一連の動作を完了する。 例えば、 他のデータベース利 用者が更新しよう とするデータを更新中の場合は、 更新トランザクショ ンはデータベースに接続した状態で、 データ更新可能となるのを待つ。 一連の動作はデータベース接続を保ったまま中断なしに実行される。
もし、 一連の動作中にデータベース接続が切断されると、 実行中の ト ランザクシヨ ンは中断され、 トランザクショ ンは無効になる。 分離中断 されない更新データ特定、 更新データ排他制御、 データ操作、 データべ —ス更新という一連の トランザクション動作が保証されることを前提に 従来のデータベースシステムはデータ一貫性を保証してきた c
さて、 特表平 3 — 5 0 5 9 3 8には、 「場立ち」 を基本と して行なわ れる先物取り引き市場を 「場」 という物理的なスペースの外に計算機シ ステムを利用することによ り拡張するための技術が公表されている。 「場」 にいることによって得られる情報を計算機システムによって提供 し、 「場」 での取り引き機構、 即ち、 トランザクショ ン機構も計算機シ ステムによって実現する c
本発明を適用するすべきシステムは、 例えば、 特表平 3 — 5 0 5 9 3
8に記述されているシステムである- 本発明を適用することにより、 そ の目的と している 「場」 の拡大をさらに実現することが可能である。 従来の トランザクショ ン処理は、 データべ一スアクセス負荷調節を目 的と して T P (T r a n s a c t i o n P r o c e s s i n g ) モニ タなどのキューイング機構を使用する場合を含め、 端末からのデータ更 新要求は同期的に処理されることを前提に、 各トランザクション処理の 排他制御機構を設けることにより実現されてきた。 端末からの同期処理 を行なうにはなんらかの通信プロ トコルにより端末とホス ト （あるレ、は サーバ） との接続状態が保証されている必要があった。 通信回線の品質 はある程度までは通信プロ トコルによって保障されるが、 P H S (P e r s o n a l H a n d y p h o n e S y s t e m)、 携帯電話等の 無線回線の利用においては、 回線の切断、 また、 ユーザが明示的に無線 回線の使用を行なわない場合を含めて回線の接続状態が必ずしも保証さ れない。 また、 転送速度も低速である。 このような無線回線を利用する 端末から トランザクショ ン処理を行なおうとする場合、 無効トランザク ションが多発すると予想される。 トランザクションが無効となることに よりユーザは不利益を被り、システムとしても負担が増えることとなる。 本発明の目的は、必ずしも接続状態を保証できない端末を使用しても、 利用者間で公平にデータ更新トランザクショ ンを実行できるデータ更新 方式及び方法を提供することである。 発明の開示
この発明に係るデータ更新方式は、 複数の利用者端末と、 利用者間 の共有データを管理するサーバとを備え、 上記複数の利用者端末と上記 サーバは上記利用者端末と上記サーバとの間で相互に同期が取られた時 刻を計時する計時機能モジュールをそれぞれ保持し、上記利用者端末は、 上記共有データの更新要求時、 上記計時機能モジュールより獲得した時 刻をデータ更新要求発行時刻と して共有デ一タ更新要求に付して上記サ —バに送信し、 共有データ更新要求が上記サーバに受信されるまで、 上 記デ一タ更新要求発行時刻を当初の送信時と同一と したまま繰り返し送 信する更新要求送信処理部を有し、 上記サーバは、 上記利用者端末から 受信した共有データ更新要求に付されたデータ更新要求発行時刻に基づ き、 上記共有データの更新順序を決定する共有データ管理モジュールを 有することを特徴とする。
共有データ管理モジュールは、 更新要求受け付け期間を設定する更新 規則管理部と、 上記更新要求受け付け期間に受信した共有データ更新要 求を受け付ける更新要求管理部とを備えたことを特徴とする。
更新規則管理部は、 さらに、 上記更新要求受け付け期間に含まれる有 効更新要求発行期間を設定し、 更新要求管理部は、 受信した共有データ 更新要求のデータ更新要求発行時刻が該有効更新要求発行期間内にある 共有データ更新要求を受け付けることを特徴とする。
更新要求送信処理部は、 データ更新条件を含む共有データ更新要求を サーバに送信し、 共有データ管理モジュールは、 上記更新要求受け付け 期間の終了後、 上記共有データ更新要求に含まれたデータ更新条件をデ ータ更新要求発行時刻の順に吟味し、 上記データ更新条件が満足される 時、 上記共有データ更新要求に応じて共有データ更新値を決定し、 上記 共有データを該共有データ更新値に更新するデータ更新部を備えたこと を特徴とする。
データ更新部は、 上記有効更新要求発行期間内に、 すでに受信した共 有データ更新要求に含まれるデータ更新条件をデータ更新要求発行時刻 の順に吟味し、 上記データ更新条件が満足される場合は、 上記共有デー タ更新要求に基づく共有データ更新予測値を決定することを特徴とする c 共有データ管理モジュールは、 利用者端末に対して所定段階に強度が 分類された権限の内の 1つの権限を付与し、 該権限により各利用者端末 に送信する情報を選択する利用者通知部を有することを特徴とする。 利用者通知部は、 一定以上の強度の権限を持つ利用者端末のみに共有 データの更新履歴を送信することを特徴とする。
利用者通知部は、 一定以上の強度の権限を持つ利用者端末のみに、 各 利用者端末からのデータ更新要求の内容を送信することを特徴とする。 共有データ管理モジュールは、 共有データを更新した時に利用者端末 に通知する利用者通知部を有することを特徴とする。
利用者通知部は、 上記通知の内容に、 少なく とも共有データの更新前 後の差の情報を含むことを特徴とする。
利用者通知部は、 共有データの更新前に該共有データにアクセスした ことのある利用者端末に対して通知をすることを特徴とする。
利用者通知部は、 共有データの更新前の一定期間内に該共有データに アクセス したことのある利用者端末に対して通知することを特徴とする c 利用者端末は、 サーバに対して情報送信要求を送信し、 共有データ管 理モジュールは、 利用者端末から情報送信要求を受信し、 該利用者端末 の共有データへのアクセス履歴を吟味し、 該利用者端末が情報送信要求 の受信前に該共有データにアクセスしたことがある場合、 該情報送信要 求に応答する利用者通知部を有することを特徴とする。
利用者通知部は、 利用者端末が上記情報送信要求の受信前の一定期間 内に上記共有データにアクセスしたことがある場合、 情報送信要求に応 答することを特徴とする。
利用者端末からの情報送信要求は、 サーバにすでに到着している共有 データ更新処理前のデータ更新要求の内容に対する送信要求であること を特徴とする
利用者端末は、 共有データの更新を監視する条件を送信し、 共有デ一 タ管理モジュールは、 送信された条件を登録し、 共有データ更新により 条件が満たされた時に該利用者端末に共有データ更新を通知する利用者 通知部を有することを特徴とする。
利用者端末は共有データの更新を監視する条件を送信し、 共有データ 管理モジュールは、 送信された条件を登録し、 上記共有データ更新予測 値が条件を満たす時に利用者端末に共有データ更新予測値が条件を満た すことを通知する利用者通知部を有することを特徴とする。
上記計時機能モジュールは、暗号化処理部を備えたことを特徴とする。 上記計時機能モジュールは、 利用者端末の認証機能を備えたことを特 徴とする。
サーバは、 共有データ管理モジュールが受信した各利用者端末からの 共有データ更新要求をデータ更新要求発行時刻の順にならベた共有デ一 タ更新要求キューを記憶する記憶部を有することを特徴とする。
この発明に係るデータ更新方法は、 複数の利用者端末と、 利用者間の 共有データを管理するサーバとを備え、 上記複数の利用者端末と上記サ ーバとが、 時刻を計時するは計時機能モジュールをそれぞれ保持してい る計算機システムのデータ更新方法において、 上記複数の利用者端末の 計時機能モジュールと上記サーバの計時機能モジュールとの間で相互に 同期を取る工程と、 上記利用者端末により、 上記共有データの更新要求 時、 上記計時機能モジュールよ り獲得した時刻をデータ更新要求発行時 刻と して共有データ更新要求に付して上記サーバに送信し、 共有データ 更新要求が上記サーバに受信されるまで、 上記データ更新要求発行時刻 を当初の送信時と同一と したまま繰り返し送信する工程と、 上記サーバ により、 上記利用者端末から共有データ更新要求を受信し、 受信した共 有データ更新要求に付されたデータ更新要求発行時刻に基づき、 上記共 有データの更新順序を決定する工程を備えたことを特徴とする。
共有データ更新要求は、 第 1の条件と数量の条件を含む売り注文また は買い注文であり、 データ更新要求発行時刻が昇順となるように共有デ ータ更新要求キューの形式でサーバの記憶部に保持され、 下記ステップ を有することを特徴とする。
a ) サーバの記憶部に記憶された共有データ更新要求キューの状態によ り、 下記 （ a 1 ) 〜 （ a 3 ) のいずれかのステップを実行するチェック ステップ ；
a 1 ) サーバの記憶部に記憶された共有データ更新要求キューに注文 が保持されていない場合、 処理を終了するステップ ；
a 2 ) サーバ記憶部に記憶された共有データ更新要求キューの先頭の 注文が買い注文の場合、 この買い注文を主注文と し、 売り注文を対応注 文と して下記 （b ) 第 1条件比較ステップに進むステップ ；
a 3 ) サーバ記憶部に記憶された共有データ更新要求キューの先頭の 注文が売り注文の場合、 この売り注文を主注文とし、 買い注文を対応注 文と して下記 （b ) 第 1条件比較ステップに進むステップ； b ) サーバ記憶部に記憶された共有データ更新要求キューから対応注文 を昇順に読出し、 上記主注文と第 1の条件が一致する対応注文があるか 否かによ り次のいずれかのステツブを実行する第 1条件比較ステップ； b 1 ) 第 1 の条件が一致する対応注文がない場合、 この主注文を不成 立注文と して上記共有データ更新要求キューから削除し、 上記 （ a ) チ エックステップに戻るステップ ；
b 2 ) 第 1の条件が一致する対応注文がある場合、 主注文と対応注文 である買い注文と売り注文の数量を比較し、 その結果により下記いずれ かのステップを実行するステップ；
b 2 1 ) 買い注文の数量が売り注文の数量を超えている場合、 この 買い注文とこの売り注文は不成立と し、 共有データ更新要求キュー内の 該対応注文の次の対応注文から読出しを再開し、 上記第 1条件比較ステ ップに戻るステップ；
b 2 2 ) 買い注文の数量が売り注文の数量と等しい場合、 この買い 注文と売り注文は成立と し、 この買い注文と売り注文をそれぞれ共有デ ータ更新要求キューから削除し、 上記 （ a ) チェックステップに戻るス テツブ ：
b 2 3 ) 売り注文の数量が買い注文の数量を越える場合、 この買い 注文と売り注文は成立と し、 この買い注文は共有データ更新要求キュ一 から削除し、 この売り注文の数量をこの買い注文の数量を超えた数量に 置き換えて、 売り注文のキューデータを更新して記憶し、 上記 （ a ) チ エックステップに戻るステップ c 図面の簡単な説明
図 1 は、 本発明を適用したシステムの構成例の図である。
図 2は、 本発明による計時機能の組み込み例の図である。 図 3は、 本発明による計時機能モジユールのブロ ック図である。
図 4は、 本発明による共有データ管理サーバ構成例の図である。
図 5は、本発明による共有データ管理モジュールの構成例の図である。 図 6は、 本発明を利用した端末アプリケーションの入力画面例の図で める。
図 7は、 本発明による共有データ更新要求発行処理フロー図である。 図 8は、 本発明による共有データ更新要求データ例の図である。
図 9は、 本発明による共有データ更新要求受け付け処理フロー図であ る。
図 1 0は、 本発明による共有データ更新処理フロー図である c 図 1 1 は、 本発明による利用者 I Dデータ例の図である。
図 1 2は、 本発明による通知サ一ビス登録処理フロー図である。
図 1 3は、本発明によるデータモニタリング登録キュー模式図である。 図 1 4は、 本発明による共有データ更新要求キュー例の図である。 図 1 5は、 本発明による通知サービス登録テーブル模式図である。 発明を実施するための最良の形態
実施の形態 1 .
以下、 本発明に係るデータ更新方法を図 1から図 1 3に基づいて説明 する。 本実施形態では、 本発明を商品取り引きシステムに適用した例に ついて説明するが、 この商品取り引きシステムは、 多数の利用者が参加 する トランザクショ ンシステムの一種である。 当システムはバーチャル な市場を提供するもので、 市場への参加は当システムが提供する端末を 利用することによってのみ可能である。 参加者は有線で接続された端末 だけでなく、 無線端末を利用しても公平に市場に参加できる。
図 1 に示すように、 利用者は携帯端末 1 0 1 、 1 0 2から無線電話回 線を利用して基地局 1 0 7から公衆網 1 0 8経由で参加したり、 公衆回 線 1 0 9 とパーソナルコンピュータ P C経由で接続されたイン トラネッ 卜に接続された端末 1 0 3、 1 0 4から参加する場合もあり、 また、 共 有データの管理を行なうサーバ 1 1 0が接続された同一の L AN ( L o c a 1 A r e a N e t w o r k ) に接続された端末 1 0 5、 1 0 6 から参加する場合もある- 図 1 には前述したような 3種類の通信メディ ァが示されている。
次にシステムの構成を説明するが、 以後、 上記携帯端末 1 0 1 、 1 0 2および上記端末 1 0 3から 1 0 6の端末の総称を利用者端末とする。 図 2に示すように、 本システムに参加する利用者端末は計時機能を有 する計時機能モジュール 2 0 1 を保持し、 サーバ 1 1 0は計時機能モジ ユール 4 0 2を保持している。 また、 各利用者端末には、 サーバ 1 1 0 との間でデータあるいは情報の送受信を行うために、 端末用通信プログ ラム 2 0 2がインス トールされている。 この端末用通信プログラム 2 0 2は、 更新要求送信処理部の一例である。 この更新要求送信処理部は、 後述する共有データ更新要求送信機能を有する。
この端末用通信プロダラム 2 0 2は、 特定の利用者のみ使用可能であ り、 パスワードにより利用者を確認する機能を有する。 また、 各利用者 端末には、 メモリ 2 0 3がイ ンス トールされている。
また、 上記計時機能モジュール 2 0 1 は携帯端末 1 0 1 を含むすべ ての利用者端末で同一のものを使用する。 本計時機能モジュール 2 0 1 は各利用者端末に対して着脱式で、 システム管理者によって認証と、 本 システムが採用する標準時間への時計合わせが行なわれて有効となり、 特定の利用者のみに配布される。 システム管理者は、 例えば、 商品取り 引き市場にシステムが適用される場合、 市場の監査組織が行なうべきも ので、 システム管理者は上記計時機能モジュール 2 0 1を厳重に管理す る c
上記計時機能モジュール 2 0 1は、 本システムにおいては P Cカード として実現される。
図 3に上記上記計時機能モジュール λ ' 0 1 の機能プロック図を示す。 3 0 1は P Cカー ドイ ンタ一フェースロジック、 3 0 2は内部バス、 3 0 3はノくックアツプ電池、 3 04は暗号化およびコン トロ一ルロジック、 3 0 5はク ロ ック、 3 0 6は認証データ格納用 E P ROM (E r a s a b 1 e P r o g r a mm a b l e R e a d O n l y M e m o r y ) である。 コン トロールロジック 3 04には時計合わせホス ト認証口 ジックが組み込まれており、 ク ロ ック 3 0 5 と後述の本システムの標準 時間との時計合わせ、 および E P ROM3 0 6への利用者認証デ一タ設 定を行なう初期設定がなされて、 本計時機能モジュール 2 0 1は有効と なる。
この時計合わせ及び利用者認証データ設定は、 システム管理者により 行われる。
また、 上記端末用通信プログラム 2 0 2は、 利用者端末にこの計時機 能モジュール 2 0 1が装着されているかどうかを検出し、 さらに計時機 能モジュール 20 1が装着されていて、 利用者が正しいパスヮ一 ドを入 力したときのみデータあるいは情報の送受信が可能となり、 利用者から 上記端末用通信プログラム 2 0 2が使用可能となる。
当システムにおける共有データ管理者であるサーバ 1 1 0の機能構成 を図 4に示す c 当システムにおける共有データは、 データベース DBの 各テーブルのレコ一ドのデータである。
LAN 4 0 1 に接続されて、 サーバ 1 1 0は各利用者端末から利用さ れる。 サーバ用計時機能モジュール 4 0 2は、 本システムの標準時間で あり、 各利用者端末の計時機能モジュール 2 0 1の基準となるクロ ック を保持している。 各利用者端末の計時機能モジュール 2 0 1は、 このク ロックと一致するように、システム管理者によって時計合わせがされる。
4 0 3は更新要求格納用ディスク、 4 0 4は共有データ管理モジユ ー ル、 4 0 5は共有データ格納用ディスクである： 4 0 6はメモリである c 1 1 0 0は、 後述する利用者管理テーブルである。
図 5に示すように、 共有データ管理モジュール 4 0 4は、 利用者から の共有データ更新要求を受け付け、保存管理する更新要求管理部 5 0 1 、 各種利用者へのデータ更新状況通知サービスを行なう利用者通知部 5 0 2、 更新要求受け付け期間の設定や共有データ更新のための調停を行な う更新規則管理部 5 0 3、 整理された （キューイ ングされた） 更新要求 データから共有データの更新を行なうデータ更新部 5 0 4から構成され る。
以下、本システムの動作を次の 1から 6の各機能に基づいて説明する。 1 . 利用者端末における更新要求データ受け付け送信機能
2 . 更新規則管理機能
3 . 共有データ更新要求管理機能
4 . データ更新機能
5 . 価格予測機能
6 . 更新内容利用者通知機能
1 . 利用者端末における更新要求データ受け付け送信機能
まず、利用者端末での共有データ更新要求送信機能について説明する。 ここでは、 利用者が利用する通信メディアについては言及しないが、 利 用者端末から更新要求を発行し、 更新要求管理部 5 0 1に登録されるま でのメ力二ズムを通信再試行メ力二ズムを含めて説明する。
利用者端末は P Cカードインタ一フェースを備えており、 計時機能モ ジュール 2 0 1がシステムに組み入れられ、 さらに利用者が正しいパス ヮ一ドを入力したことを端末用通信プログラム 2 0 2が確認すると、 利 用者端末における端末用通信ブログラム 2 0 2が利用可能となる。 すでに述べた通り、 本実施形態では本システムを商品取り引きシステ ムに応用した例を示しているが、 利用者端末上の端末用通信プログラム 2 0 2が用意する買い注文画面を図 6 ( a ) に示す。
6 0 1 は注文画面で、 商品 I D ( I d e n t i i i c a t i o n)、 買い数量、 買値条件を各々対話式で設定する。 図 6の商品 I Dは 2月中 旬収穫のオレンジを表わしている c
買い数量には、 この数量丁度か、 この数量以下か、 この数量以上かを 表わすオプショ ン、 「 j u s t」 「m a x」 「m i n」 を付け、 買値は上 限値を設定する。 図 6 ( a ) の例では、 数量 2 0 0個丁度の買い注文を 表わしている。
商品 I D、 買い数量及び買値条件を設定後、 利用者は表示画面を確認 の上、 6 0 2の送信ボタンを押下する。
また、 上記ォプショ ン 「m a X」 「m i n」 は複合使用が可能であり、 たとえば以下のような表現も可能である。
1 0 0 <買値く 2 0 0
図 6 ( b ) は売り注文画面であり、 6 0 3の注文画面に、 買い注文と 同様に商品 I Dを入力した後、 売り数量を入力する。 売りの場合には、 数量にォプションは付けず、 売値は下限値を入力する。
商品 I D、 売り数量及び売値条件を設定後、 利用者は表示画面を確認 の上、 6 0 4の送信ボタンを押下する。
上記買値または売値が、 本発明における第 1の条件である。
利用者による送信ボタン 6 0 2あるいは 6 0 4の押下により、 端末用 通信ブログラム 20 2は利用できる通信メディアと、 コンフィグレーシ ョンデータと して登録されているサーバァ ドレスにより、 買い注文また は売り注文、 つまり、 共有データ更新要求をサーバ 1 1 0に送信する。 端末用通信プログラム 2 0 2が、 利用者からの買い注文または売り注 文を受け付けた後のサーバ 1 1 0への送信手順について、 図 7のフ口一 チヤ一トを参照して説明する。
なお端末用通信プログラム 2 0 2は利用者の誤操作を未然に防ぐため 買い注文、 売り注文を別画面と しているが、 更新処理と しては同一であ る。 以下、 買い注文と して説明する。
最初の処理と して、 ステップ 70 1でサーバァ ドレスを計時機能モジ ユール 2 0 1から取得する 当システムにおいてはサーバア ドレスは I P ( I n t e r n e t P r o t o c o l ) ァ ドレスにて表現されてい る。
ステップ 7 0 2で利用者から与えられた買い注文データを計時機能モ ジュール 2 0 1が受け付けるフォーマツ トに整理し、 ステップ 7 0 3で 計時機能モジュール 2 0 1 に 7 0 3でフォーマッ トされた買い注文デ一 タを入力する。 計時機能モジュール 2 0 1はこの入力により、 図 8に示 すフォーマツ トの更新要求データ 8 0 0を生成し、 初期設定時に与えら れた喑号鍵により、 更新要求データ 8 0 0を暗号化する。
この更新要求データ 8 0 0は、 利用者を特定する利用者 I D 8 0 1、 計時機能により得た本発明におけるデータ更新要求発行時刻である発信 時刻 8 0 2、 商品ジャンルを表わすテーブル I D 8 0 3、 前記商品 I D と同じ意味のレコード I D 8 0 4、 数量データに対するオペレーション
(買いなら減算、 売りなら加算） 8 0 5、 数量 （オペラン ド） 8 0 6、 オペレーション実行可否を決定する条件 8 0 7、 共有データ更新に伴う 清算トランザクションを行なうための利用者清算銀行口座 8 0 8を含む c 条件 8 0 7は、 オペレーシヨ ン 8 0 5が減算すなわち買い注文の場合は 自動的に買値の上限値を示し、 ォベレーシヨ ン 8 0 5が加算すなわち売 り注文の場合なら自動的に売値の下限値を示す。
図 8の更新要求データ 8 0 0において、 発信時刻は 1 9 9 7年 9月 1 7 日 1 1時 3分 3 2秒 1 2、 テーブル I Dは果物、 レコード I Dは 2月 中旬収穫のオレンジを意味し、 数量 2 0 0個丁度、 買い値 3 5 0以下の 買い注文である。
端末用通信プロダラム 2 0 2は暗号化された更新要求データ 8 0 0を 計時機能モジュール 2 1 0から受けとる （ステップ 7 0 4 )。 端末用通 信プログラム 2 0 2は、 ステップ 7 0 5で暗号化された更新要求データ 8 0 0をサーバに送信する c
サーバへの送信はこれまで説明してきた通り利用者端末が利用する通 信メディアにより必ずしも成功するとは限らない。 利用者端末は通信に 成功するまで再試行を重ねる。 再試行の場合でも、 端末用通信プロダラ ム 2 0 2は更新要求デ一タ 8 0 0の発信時刻 8 0 2を変化させず、 当初 の送信時と同一の発信時刻 8 0 2を用いて再送する。 こう して必ずしも 接続状態を保証できない端末を使用しても、 利用者間で公平にデータ更 新トランザクションを実行できるデ一タ更新方式及び方法を提供するこ とが可能になる。 当システムにおいては、 通信プロ トコルとして T C P ( f r a n s a t i o n C o n t r o l P r o t o c o l ) を利/ Ή しているのでサーバへ送信されたか否かは確実に知ることができる。 暗号化された更新要求データ 8 0 0はサーバの更新要求受け付け期間 内に到達する限り有効であるので、 通信に失敗する場合、 利用者は利用 者端末内に保存されている更新要求データ 8 0 0を他の通信メディアを 利用して送信することもできる- もちろん、 利用者端末は更新要求デー タ 8 0 0をメモリ 2 0 3の中に保存することもできる。
サーバ 1 1 0は、 更新要求データを受信した場合、 受理メ ッセージ を利用者端末に送信する。 利用者端末はステップ 7 0 6でサーバ 1 1 0 からの受理メ ッセージを受け、 サーバ 1 1 0が更新要求を受け付けたか どうかを確認し （受け付け期間内でない場合に受理されない可能性があ る）、 利用者に通知する。
2 . 更新規則管理機能
更新規則管理機能は更新規則管理部 5 0 3が持ち、 更新要求受け付け 時間の管理、 更新要求発行時刻の妥当性の管理、 共有データ更新の制御 を行なう。
本実施形態では商品取り引きに応用されている例を示しているが、 本 機能が参照利用/管理するコンフィ ダレ一ショ ンデータファイルに固定 的に、 有効更新要求発行期間と して午前 9時〜午後 3時、 更新要求受け 付け期間と して午前 9時〜午後 9時を設定している。
この有効更新要求発行期間は一般の市場の営業時間に相当するものと 想定しており、 この時間内に発行された買い注文、 売り注文のみが有効 とするものである。
また、 有効更新要求発行期間内に発行された注文でも通信状況により 遅延してサーバに到着することがあり、 その遅延時間を考慮して、 この 更新要求受け付け期間内に到着した注文は、 受け付けるとするものであ る。
データ更新処理は午後 9時の受け付け終了をもって開始する設定と なっている。
3 . 共有データ更新要求管理機能
更新要求管理部 5 0 1が持つ、 利用者からの共有データ更新要求の受 け手となる機能であり、 利用者からの更新要求を受けて、 更新要求キュ 一を生成し管理する。 本処理フローを図 9を用いて説明する。
本処理は独立したコンテクス トで動作しており、 常に、 利用者端末か らの更新要求の着信をモニタしている。 厳密には、 着信コネク ト要求に よって新規のコンテクス トが生成され、 更新要求キューに一つあるグロ 一バルロ ックを取得の上、 ステップ 9 () 1以下の処理を行なう力；、 ここ ではフローをル一プ処理と して表記してある。 更新要求の着信が重なつ た時は処理がシリアライズされるが、 利用者間のトランザクションの公 平性には影響しない。
ステップ 9 0 1で、暗号化された更新要求データ 8 0 0を受けとると、 この更新要求データを複合化し、 図 8に示した更新要求データ 8 0 0を 得る。
ステップ 9 0 2で更新要求データ中の利用者 I Dをチェック し、 利用 者 I Dが不正ならば、 I D不正により更新要求登録がなされなかった旨 を該利用者にステップ 9 0 6で通知する。
続いてステップ 9 0 3で更新規則管理部 5 0 3に問い合わせ、 更新要 求データ 8 0 0に付された発信時刻が有効更新要求発行期間内か否か、 また着信時刻が更新要求受け付け期間内か否かを吟味して、 いずれか一 方でも所定期間内でなければ、 ステップ 9 0 6で同じく理由とともに更 新要求登録が拒絶された旨を該利用者に通知する。
ステップ 9 0 3で発信時刻、 着信時刻とも所定期間内であったら、 ス テツプ 9 0 4では、 図 8の更新要求データ 8 0 0に、 更新要求キュー上 へ登録するためのキューリンクポインタ 2つと、 該利用者への返信用に 該利用者のア ドレスを付加し、 発信時刻の昇順 （時刻の早い順） へ更新 要求キューに挿入する。
図 1 4にメモリ 4 0 6に作られた更新要求キュー （以下、 単にキュー ともいう） の構成例を示す 1 4 0 1 は図 1 4に例示する更新要求キュ —を管理するへッダである： 該へッダに 3つのキューデータがキュ一ィ ングされている。 図 8に示すフォ一マッ 卜の更新要求データ 8 0 0に加 え、 キュ一上の前キューデータを示すキューリンクポインタ 1 4 0 3 と 後キューデータを示すボキューリンクインタ 1 4 0 4、 および利用者ァ ドレス （ポートア ドレス） 1 4 0 2を付加されたデータが各キューデ一 タを構成している。 各キューデータは固定長でありキューイングに十分 なサイズのメモリ領域を固定的に使用する。 この領域をメモリプールと 呼ぶがメモリプールによりキューリンクボインタ操作によってメモリ領 域の再利用が可能である。
さらに、 該当する更新要求キューのメモリプールに対応する （記憶部 の一例である） 更新要求格納用ディスク 4 0 3へのメモリプールの内容 書き込みをステップ 9 0 5で行なって、 ステップ 9 0 7で該更新要求が サーバ 1 1 0に受理されて登録された旨を該利用者に通知する。
さらに、 ステップ 9 0 8で更新要求データ 8 0 0の転送要求を予め登 録をしている利用者に当更新要求を転送する。 更新要求データ 8 0 0の 転送要求の登録については、 以下の 「 6 . 更新内容利用者通知機能」 に おいて説明する。
もし、 何らかのシステム障害でシステムがダウンした場合、 更新要求 格納用ディスク 4 0 3からメモリプールの内容の読出しを行なってメモ リ 4 0 6に更新要求キュ一を復旧する。
4 . データ更新機能
本機能はデータ更新部 5 0 4が持つ機能であり、 更新規則による当機 能の動作、 更新要求データ 8 0 0のデキュー、 更新要求の吟味メカニズ ムについて主に説明する。
本システムにおいて、 データ更新機能は市場営業日の午後 9時に更新 規則管理機能により起動される： 本実施例において結果的にデータ更新 はバッチ的に処理されるがもちろんこれは本発明の制限するところでは ない。
本データ更新処理を図 1 0のフローを用いて説明する。
すでに更新要求キューは各レコ一ド毎に利用者の更新要求発行時刻に 基づいて整理されているので、 当更新処理はステップ 1 0 0 1で各レコ 一ドについて発行時刻の古い順に更新要求キューをアクセスして以下に 述べるようにキューデータを処理し、 処理したキュ一データをデキュ一 (削除） していく。 すべての更新要求キューのキューデータの処理を終 了したところで本処理は終了となる。
ステップ 1 0 0 2で、 更新要求キューの買い注文と売り注文の照合を 行う。 更新要求キューの先頭にあるキューデータ （未処理のキューデー タの中で更新要求発行時刻の最も古い注文） が買い注文であれば、 売り 注文のキューデータを昇順にサーチし、 発見した売り注文に対し、 ステ ップ 1 0 0 3で価格が合致するかどうかをチェックする。 合致していれ ば （売り価格 買い価格であれば）、 さらにステップ 1 0 0 4で、 この 売り注文の数量と買い注文の数量を比較し、 売り注文の数量が買い注文 の数量を満足する場合 （売り注文の数量≥買い注文の数量の場合） は、 この取り引きは成立したものと し価格をデータベースに登録する。 そし て、 成立した買い注文のキューデータと売り注文のキュ一データをステ ップ 1 0 1 0でデキュ一する。 この時、 売り注文の数量の方が多く （売 り注文の数量 >買い注文の数量） 残数がある場合は、 この残数 （残数- 売り注文の数量一買い注文の数量） を新たにこの売り注文の数量と設定 し直す。 買い注文のキューデータはデキューする （ステップ 1 0 1 0 ) c 価格、 あるいは、 数量が合致しなかった場合、 ステップ 1 0 0 2に戻り 次の候補をサーチする。 ただし、 数量が満足されなかった場合は、 続け て売り注文のキューデータを読出して、 価格および数量が満足される売 り注文を検索し、 条件の合う売り注文がなかった場合は、 この買い注文 は不成立となる。 この不成立となった買い注文のキューデータはデキュ —される （ステップ 1 0 0 9 ) c 以上の場合は、 買い注文が本発明にお ける主注文、 売り注文が対応注文となる。
更新要求キューの先頭にあるキューデータが売り注文の場合はキュー 上の買い注文を対象に同様の処理を行う。 この場合は、 売り注文が本発 明における主注文、 買い注文が対応注文となる。
サーチして最後まで、 売買が成立しなかった売り注文または買い注文 と、 売り注文の中で残数があるものが残注文と して更新要求キューから のデキュー時に抽出される ,」 以上のように、 注文が成立してもしなくて も、 先頭のキューデータを更新要求キューから削除 （デキュー） する。 このキューデータの削除はヘッダのボインタのつけかえにより行われる c こう してキューデータが順に先頭にく りあげられ処理される。
売買が成立した場合、 すなわち、 更新条件が合致したならばステップ
1 0 0 5で更新要求データ中に設定されたオペレーシヨン 8 0 5 (買い なら減算、 売りなら加算） とオペラン ド 8 0 6 (当システムにおいては 商品数量） で、 共有データを更新する。 つまり、 当システムが利用する データベース中の当該レコードのデータを更新する。 また、 商品売買に 伴う清算を更新要求データ 8 0 0内に設定された清算用銀行口座 8 0 8 にて行なう。
共有データの更新が終了したならば、 利用者通知部 5 0 2を通して、 該更新を発行した利用者に売買が成立し、 該共有データ更新が終了した ことをステップ 1 0 0 6で通知する c この利用者への通知は夜間であるため、 利用者端末が起動されていな いことがあるが、 利用者端末に受信されなかった通知は、 次回利用者端 末が起動された際に再度送信される c
また、 利用者端末側からも、端末用通信プログラム 2 0 2を利用して、 自分が送信した更新要求の結果を問い合わせることが可能である。
さらに、 ステップ 1 0 0 7で共有データの更新通知要求を予め登録を しているユーザに、 更新したレコー ドの更新前レコードと更新後レコ一 ドの差分データを送信する この共有データの更新通知の登録について は、 以下の 「6 . 更新内容利用者通知機能」 において説明する。
もし、 条件に合致しない場合、 すなわち残注文となった場合は、 ステ ップ 1 0 0 8で該更新要求を発行した利用者に共有データの更新が行な われなかったことを通知する:： 当通知は更新要求キューに登録されてい るポートァ ドレスに通知する c
5 . 価格予測機能
本機能は、 データ更新機能と同じくデータ更新部 5 0 4が持つ機能 である。
上記データ更新機能は、 更新要求受け付け期間終了 （本実施形態では 午後 9時） 以後、 売り注文と買い注文のキューデータを照合して売買価 格を最終決定するものであるが、 本価格予測機能は、 有効更新要求発行 期間 （本実施形態では午前 9時〜 3時） 内に受信した買い注文と売り注 文を格納したキューデータを、 この有効更新要求発行期間内の一定時間 ごと （例えば 1 0分毎） に照合し、 その時点で成立する売買の価格を、 価格の予測値とするものである。 この時間帯には、 すでに発信されてい てもまだ受信されていない注文がある可能性があり、 データ更新機能が 起動してから正式に決定される価格とは異なる場合があるため、 誤差を 許容する予測値と して取り扱う- この一定時間内に複数の売買が成立した場合には、 その最高値と最低 値を予測値とする。 また、 平均値を予測値と してもよい。
6 . 更新内容利用者通知機能
本機能は利用者通知部 5 0 2が持つ機能である。
本システムは、 計時機能モジュ一ル 2 0 1 によるサーバ 1 1 0への利 用者登録の際、 サーバ 1 1 0の管理データと して利用者 I Dを登録する 力 この時、 サーバ 1 1 0には利用者の権限も登録される。 この権限は 本商品取り引き市場での実績に応じて与えられ、権限に応じて利用者は、 下記のデータ提供サービスを利用できる。 権限は権限 1から権限 3の 3 段階で与えられるので、 各段階の権限について説明する
1 ) 権限 1 ： 共有データ更新時に通知を受けることができる。
共有データの更新が終了したデータの最新情報を得ることができる。 当システムにおいて具体的には午後 9時以降、 決裁された商品取り引き データを更新通知により逐次参照することができる。 この権限 1は、 上 記 「4 . データ更新機能」 で述べた共有データの更新通知を受けること ができる権限である。
2 ) 権限 2 ： 共有データ更新前にサーバが管理する共有データ更新要求 の内容を受けとることができる。
午前 9時の市場開始時から、 更新要求受け付け終了までの到着した更 新要求データの内容を逐次受けとることができ、 最新の市場動向を知る ことができる。 また、 決裁前の更新要求データをもとにした市場動向の 予測値を得ることもできる。 この権限 2は、 上記 「 3 . 共有データ更新 要求管理機能」 で述べた更新要求データの転送を受けることができる権 限である。
3 ) 権限 3 ： 過去の共有データ更新履歴を得ることができる。
過去に渡り共有データの更新履歴を得ることができる。 ただし、 上記権限 2は権限 1 を包含し、 権限 3は権限 1 、 権限 2を包 含する。 利用者の権限は 1、 2、 3のいずれかで登録され、 データ参照 サービスへの登録要求が利用者からあった時は権限をチェック してデ一 タ参照サービスへの登録処理がなされる。
以下、 上記データ参照サービスの配信処理の説明を行うが、 これに先 立ち、 データ参照サービスの利用者登録について説明する。
図 1 1 に示すのは登録された内容を管理するシステムの利用者管理テ —ブル 1 1 0 0であり、 更新要求格納用ディスク 4 0 3に保存されてい る。 1 1 0 1 には利用者 I Dが格納され、 1 1 0 2には前述した利用者 権限が登録されている。 1 1 0 3以降には当利用者が発行した共有デ一 タ更新要求履歴が登録されている。
本実施形態におけるシステムの共有データアクセスは、 更新について はサーバ 1 1 0に依頼することによつて行なわれているが、 読出しにつ いては各利用者が直接データベースにアクセスすることにより行なわれ ている。 従って、 アクセス履歴と して共有データ更新要求発行のみに着 目 しているが、 これは、 本発明の制限するところではない。
図 1 2に更新内容通知サ一ビスへの利用者登録処理フローを示す。 図 1 2に示す利用者登録処理フローは権限 1に対応する共有データ更 新時の通知サービスと、 権限 2に対応する更新要求データの逐次報告サ —ビスにおいて利用される。
ステップ 1 2 0 1で利用者から通知サービスへの登録要求を受けとる と、 ステップ 1 2 0 2で当該利用者の権限をチェック し、 通知サービス を受ける権限があれば図 1 5に示す権限に応じた通知サービス登録テ一 ブル 1 5 0 1， 1 5 0 2にェン ト リ 1 5 0 3， 1 5 0 4を追加し、 通知 サービスが登録されたことを当該利用者に通知する。 通知サービス登録 テーブル 1 5 0 1， 1 5 0 2には利用者管理テーブル 1 1 0 0への利用 者ボイ ンタであるェン ト リ 1 5 0 3 とデータアクセス履歴による通知制 限情報であるェン トリ 1 5 0 4が格納される。 もし、 利用者の権限が該 通知サービスにそぐわなければステツプ 1 2 0 4で該利用者に通知サ一 ビス登録テ一ブルに登録されなかった旨を報告する。
共有データの更新が発生したとき、 共有データの更新通知要求を予め 登録した利用者 （権限 1 の利用者） に対して、 データ更新部 5 0 4が更 新通知を行なうことはすでに説明した。 ここでは、 データアクセス履歴 による制限によりステップ 1 0 0 5の共有データ更新処理がどのように 動作するかを説明する。
通知サービス登録テーブル 1 5 0 1 ， 1 5 0 2中のエン ト リ 1 5 0 4 には無制限であれば 0が、 一度アクセスした実績のあるレコ一ドに限る のであれば一 1力 最後のアクセスから一定期間にかぎるのであれば、 当該期間が一時間単位で登録されている。 エン トリ として 0が登録され ている時は、 無条件で差分データの送信を行なう （利用者の希望により 更新があった通知だけ行なわれるよう選択もできる）。 一 1が登録され ている場合は、 利用者管理テーブル 1 1 0 0への利用者ポインタから利 用者管理テ一ブル 1 1 0 0をアクセスし、 当該利用者が過去に当該レコ ―ドにアクセスしたことがあるかどうかを共有データ更新履歴 1 1 0 3 〜 1 1 0 5を参照し、 参照したことがあれば差分データを送信する。 参 照有効期間が登録されていれば、 履歴情報の当該レコードの最後のァク セス時刻 （更新要求発行時刻） を参照し、 当該レコー ドのアクセス履歴 があり、 最後のアクセス時刻が有効期間内であれば差分データを送信す る。
サーバ 1 1 0が更新要求を受け付けた場合、 共有データの更新要求デ ータ 8 0 0の転送登録がなされている利用者 （権限 2の利用者） に対し て、 更新要求データ 8 0 0の転送を行なうことはすでに述べた- 9 0 8 における通知制限も、 前述した 1 0 0 5における処理と同様の処理が行 なわれる c
本システムにおいて利用者は、 権限 3 を有していれば、 共有データの 更新履歴と共有データ更新前の更新要求データ 8 0 0との通知を要求で きる。 本システムは、 共有データ更新履歴問い合わせ用のポートと更新 要求データ問い合わせ用ボー トとを備えている。 本システムにおいて共 有データの更新履歴はデータベースの口グ機能をもって実現されており、 テーブル、 レコー ド、 期間を指定して、 利用者がサーバの共有デ一タ更 新履歴問い合わせ用のポートにデータ要求を出すと、 サーバは利用者の 権限チェ ックの上、 データべ一スに問い合わせを行ない、 当該レコー ド の利用者からの履歴を要求する期間の更新履歴を利用者へ返送する。 共有データ更新前の更新要求データ 8 0 0を利用者はテーブル指定、 レコード指定、 アクセス実績のあるレコードのみ指定、 あるいは、 最後 のアクセスから一定期間内にあるレコードのみ指定して、 あるいは、 こ れら条件を組合せ、 要求することができる。
サーバ 1 1 0は利用者から上記要求を更新要求データ問い合わせ用ポ 一卜に受けると、 ユーザ権限を確認の上、 キューに保持管理する更新要 求データを要求受付の古い順にサ一チし条件に合うもののリス トを作成 して利用者へ返送する。 サーバ 1 1 0は更新要求データ 8 0 0を受けと ると更新要求キューの排他制御用口ックを取得して更新要求データ 8 0
0を更新要求キューに挿入するが、 サーチ処理は更新要求キューの排他 制御用口 ックを適宜解放しながら実行する。
さて、 本システムは共有データと予測値のモニタ機能を備えている c モニタ機能は、 共有データそのものとサーバ 1 1 0が更新要求から算出 する予測値とをモニタリングする。 たとえば、 利用者があるレコード、 つまり、 銘柄に対し、 残数量、 取り引き値をモニタすることができる 本システムは、 共有データのモニタ要求を受信するモニタ登録ポートと 予測値のモニタ要求を受信するモニタ登録ポートを備えている。 利用者 は本サーバの共有データと、 更新要求からの予測値とのいずれかのモニ タ登録ポー トにテーブル、 レコード、 モニタ条件を指定してモニタ要求 をサーバへ送信する。 利用者の権限をチェックの上 （共有デ一タのモ二 タはすべての利用者が利用可能であるが、 予測値のモニタには 2以上の 権限が必要である）、 サーバは図 1 3に示すモニタキュー 1 3 0 0にモ ニタ要求の登録を行なう。 モニタキュー 1 3 0 0はレコード単位に管理 され、 各レコードはレコード名 （図 1 3においては、 " O R G 2— E ") をノヽッシユキ一とするハッシュェン ト リになってレ、る = 1 3 0 1 のへッ ダはハッシュキーであり、 モニタサービス登録テーブル 1 3 2 1 〜 1 3 2 3力 らなるハッシュ リンク 1 3 9 9に接続されている。 図 1 3には、 1つのキューしか図示していないが、 モニタキュー 1 3 0 0へのモニタ 要求の登録は共有データのモニタ要求と予測値のモニタ要求の 2つのキ ユーがある。
図 1 0に示した共有データ更新処理の 1 0 0 7では、 利用者へのデー タ更新通知処理 1 0 0 6の後、 該レコ一 ドの共有データのモニタサ一ビ ス登録テーブル 1 3 2 1 〜 1 3 2 3中のモニタ条件をサーチし、 現変更 により条件を満たしたユーザにその旨を通知する。 図 1 3の例で、 モニ タキユーの一番目のモニタサービス登録テーブル 1 3 2 1の利用者は 1 3 0 3の取り引き値と 1 3 0 4の数量の二つの条件を設定しているがい ずれか一つの条件が成立すると通知が行なわれる。
なお、 上記実施形態では、 買い注文と売り注文は商品取り引きにおけ る注文であつたが、 商品の売買における注文のみでなく、 例えばスーパ —マーケッ トにおける在庫管理等でもよい。 この場合は在庫補給要求が 買い注文、 在庫補給が売り注文に相当し、 本発明における買い注文と売 り注文とは、 あるシステムに対する需要と供給に相当するものであれば 他の形態でもよい。
また、 上記実施形態では、 有効更新要求発行期間と して午前 9時〜午 後 3時、 更新要求受け付け期間と して午前 9時〜午後 9時を設定してい るが、 それぞれ他の時間帯でもよく、 さらに数分単位あるいは数日単位 の設定でもよい。
また更新要求受け付け期間と有効更新要求発行期間が一致する形でも 運用可能である。
また、 上記各モジュール、 各部は、 ソフ ト ウェアで実現されても良い し、 ハー ドウェアで実現されても良いし、 ソフ トウェアとハードウェア の組み合わせで実現されても良い。 産業上の利用可能性
以上のように、 本発明に係るデータ更新方式及びデータ更新方法は、 データ更新要求発行時刻に基づいて上記共有データの更新を行うように したので、 利用者端末とサーバとの通信接続状態に依存しない公平なデ ータ更新を実行することができる。
また、 この要求受け付け期間の設定法により、 あるいは、 有効更新要 求発行期間の設定法により、 システムの柔軟な運用が可能になる。 また、 利用者端末はデータ更新条件の設定法により、 システムを柔軟 に利用することが可能になる。
また、 共有データ更新要求に応じて共有データ更新予測値を決定する ようにしたので、 利用者端末は自らの共有データ更新要求に対する評価 が効率的にくだせる。
また、 権限により各利用者端末に送信する情報を選択するようにした ので、 サーバは効率的に情報を送信できる = また、 サーバは、 一定以上の強度の権限を持つ利用者端末のみに共有 データの更新履歴や各利用者端末からのデータ更新要求の内容を送信す るようにしたので、 サーバはシステムの負荷や、 利用者のニーズにあわ せて、 効率的に情報を送信できる c
また、 サーバは、 共有データを更新した時に利用者端末に通知するよ うにしたので、 利用者は効率的に判断をくだせる。
また、 上記通知の内容には少なく とも共有データの更新前後の差の情 報を含むようにしたので、 利用者は共有データの再現を容易に行なうこ とができる。
また、 サーバが通知を行う利用者端末は、 共有データの更新前に該共 有データにアクセスしたことのある利用者端末のみであるようにしたの で、 システムの負荷や、 利用者の二一ズにあわせた運用が可能になる。 また、 サーバが通知を行う利用者端末は、 共有データの更新前の一定 期間内に該共有データにアクセスしたことのある利用者端末のみである ようにしたので、 システムの負荷や、 利用者のニーズにあわせた運用が 可能になる。
また、 サーバは、 利用者端末から情報送信要求があった場合、 該利用 者端末の共有データへのアクセス履歴を吟味し、 該利用者端末が該要求 の前に該共有データにアクセスしたことがある場合のみ、 該情報送信要 求に応答するようにしたので、 システムの負荷や、 利用者のニーズにあ わせた運用が可能になる。
また、 サーバは、 利用者端末が上記要求前の一定期間内に上記共有デ ータにアクセスしたことがある場合のみ、 応答するようにしたので、 シ ステムの負荷や、 利用者のニーズにあわせた運用が可能になる。
また、 情報送信要求は、 サーバにすでに到着している共有データ更新 処理前のデータ更新要求の内容に対する送信要求であるようにしたので、 利用者のニーズにあわせた運用が可能になる。
また、 利用者端末が共有データの更新に対して条件を登録し、 サーバ のデータ更新により該利用者端末が設定した条件が満たされた時に該共 有データ管理者が該利用者端末に通知するようにしたので、 利用者は共 有データの更新を監視することができる。
また、 利用者端末が共有データの更新に対して条件を登録し、 サーバ は、 上記の利用者端末または他の利用者端末からのデータ更新要求によ る共有データ更新予測値が利用者端末が設定した条件を満たした時に利 用者端末に通知するようにしたので、 利用者は共有データの予測値を知 ることができる。
また、 上記計時機能は、 上記システム管理者のみが解読可能な暗号化 処置が施されているので、 時系列データ更新を行なう上での不正を防止 する。
また、 上記計時機能に利用者認証機能を付加したので、 利用者を特定 し、 不正を防止する。
また、 サーバは、 利用者端末からの共有データ更新要求をメモ リ に 記憶するようにしたので、 管理者システムに障害が発生した場合でも、 受理したデータ更新を正しく共有データに管理者システム復旧後に反映 することができる。
また、 共通データ更新要求は、 第 1 の条件と数量の条件を含む売り注 文または買い注文であり、 共有データ更新要求キューにデータ更新要求 発行時刻を昇順として保持されており、 注文が買い注文の場合、 この買 い注文に対し昇順にまず第 1の条件が合う売り注文を検索し、 第 1の条 件が合えば、 次いで数量の条件が合うかどうかを検索するようにし、 逆 に、 注文が売り注文の場合、 この売り注文に対し昇順にまず第 1の条件 が合う買い注文を検索し、 第 1 の条件が合えば、 次いで数量の条件が合 うかどうかを検索するようにしたので、 効率的に条件が合う買い注文と 売り注文を検索することができる c

Claims

請求の範囲
1 . 複数の利用者端末と、 利用者間の共有データを管理す るサーバとを備え、
上記複数の利用者端末と上記サーバは上記利用者端末と上記サーバと の間で相互に同期が取られた時刻を計時する計時機能モジュールをそれ ぞれ保持し、
上記利用者端末は、 上記共有データの更新要求時、 上記計時機能モジ ユールより獲得した時刻をデータ更新要求発行時刻と して共有データ更 新要求に付して上記サーバに送信し、 共有データ更新要求が上記サーバ に受信されるまで、 上記データ更新要求発行時刻を当初の送信時と同一 としたまま繰り返し送信する更新要求送信処理部を有し、
上記サーバは、 上記利用者端末から受信した共有データ更新要求に付 されたデータ更新要求発行時刻に基づき、 上記共有データの更新順序を 決定する共有データ管理モジュールを有することを特徴とするデータ更 新方式。
2 . 共有データ管理モジュールは、
更新要求受け付け期間を設定する更新規則管理部と、
上記更新要求受け付け期間に受信した共有データ更新要求を受け付け る更新要求管理部とを備えたことを特徴とする請求項 1に記載のデータ 更新方式。
3 . 更新規則管理部は、 さらに、 上記更新要求受け付け期 間に含まれる有効更新要求発行期間を設定し、
更新要求管理部は、 受信した共有データ更新要求のデータ更新要求発 行時刻が該有効更新要求発行期間内にある共有データ更新要求を受け付 けることを特徴とする請求項 2に記載のデータ更新方式。
4 . 更新要求送信処理部は、 データ更新条件を含む共有デ —タ更新要求をサーバに送信し、
共有データ管理モジュールは、 上記更新要求受け付け期間の終了後、 上記共有データ更新要求に含まれたデータ更新条件をデータ更新要求発 行時刻の順に吟味し、 上記データ更新条件が満足される時、 上記共有デ ータ更新要求に応じて共有データ更新値を決定し、 上記共有データを該 共有データ更新値に更新するデータ更新部を備えたことを特徴とする請 求項 3に記載のデータ更新方式。
5 . データ更新部は、 上記有効更新要求発行期間内に、 す でに受信した共有データ更新要求に含まれるデータ更新条件をデータ更 新要求発行時刻の順に吟味し、上記データ更新条件が満足される場合は、 上記共有データ更新要求に基づく共有データ更新予測値を決定すること を特徴とする請求項 4に記載のデータ更新方式。
6 . 共有データ管理モジュールは、 利用者端末に対して所 定段階に強度が分類された権限の内の 1つの権限を付与し、 該権限によ り各利用者端末に送信する情報を選択する利用者通知部を有することを 特徴とする請求項 1 に記載のデータ更新方式。
7 . 利用者通知部は、 一定以上の強度の権限を持つ利用者 端末のみに共有データの更新履歴を送信することを特徴とする請求項 6 に記載のデータ更新方式。
8 . 利用者通知部は、 一定以上の強度の権限を持つ利用者 端末のみに、 各利用者端末からのデータ更新要求の内容を送信すること を特徴とする請求項 6に記載のデ一タ更新方式。
9 . 共有データ管理モジュールは、 共有データを更新した 時に利用者端末に通知する利用者通知部を有することを特徴とする請求 項 1 に記載のデータ更新方式：
1 0 . 利用者通知部は、 上記通知の内容に、 少なく とも共 有データの更新前後の差の情報を含むことを特徴とする請求項 9に記載 のデータ更新方式。
1 1 . 利用者通知部は、 共有データの更新前に該共有デ一 タにアクセスしたことのある利用者端末に対して通知をすることを特徴 とする請求項 9に記載のデータ更新方式。
1 2 . 利用者通知部は、 共有データの更新前の一定期間内 に該共有データにアクセスしたことのある利用者端末に対して通知する ことを特徴とする請求項 9に記載のデータ更新方式。
1 3 . 利用者端末は、 サーバに対して情報送信要求を送信 し、
共有データ管理モジュールは、利用者端末から情報送信要求を受信し、 該利用者端末の共有データへのアクセス履歴を吟味し、 該利用者端末が 情報送信要求の受信前に該共有データにアクセスしたことがある場合、 該情報送信要求に応答する利用者通知部を有することを特徴とする請求 項 1 に記載のデータ更新方式。
1 4 . 利用者通知部は、 利用者端末が上記情報送信要求の 受信前の一定期間内に上記共有データにアクセスしたことがある場合、 情報送信要求に応答することを特徴とする請求項 1 3に記載のデータ更 新方式。
1 5 . 利用者端末からの情報送信要求は、 サーバにすでに 到着している共有データ更新処理前のデータ更新要求の内容に対する送 信要求であることを特徴とする請求項 1 3に記載のデータ更新方式。
1 6 . 利用者端末は、 共有データの更新を監視する条件を 送信し、 共有データ管理モジュールは、 送信された条件を登録し、 共有データ 更新によ り条件が満たされた時に該利用者端末に共有データ更新を通知 する利用者通知部を有することを特徴とする請求項 1 に記載のデ一タ更 新方
1 7 . 利用者端末は共有データの更新を監視する条件を送 信し、 共有デ一タ管理モジュールは、 送信された条件を登録し、 上記共 有データ更新予測値が条件を満たす時に利用者端末に共有データ更新予 測値が条件を満たすことを通知する利用者通知部を有することを特徴と する請求項 5に記載のデータ更新方式。
1 8 . 上記計時機能モジュールは、 暗号化処理部を備えた ことを特徴とする請求項 1 に記載のデータ更新方式。
1 9 . 上記計時機能モジュールは、 利用者端末の認証機能 を備えたことを特徴とする請求項 1 に記載のデータ更新方式。
2 0 . サーバは、 共有データ管理モジュールが受信した各 利用者端末からの共有データ更新要求をデータ更新要求発行時刻の順に ならべた共有データ更新要求キューを記憶する記憶部を有することを特 徴とする請求項 1に記載のデータ更新方式。
2 1 . 複数の利用者端末と、 利用者間の共有データを管理 するサーバとを備え、
上記複数の利用者端末と上記サーバとが、 時刻を計時する計時機能モ ジュールをそれぞれ保持している計算機システムのデータ更新方法にお いて、
上記複数の利用者端末の計時機能モジュールと上記サーバの計時機能 モジュールとの間で相互に同期を取る工程と、
上記利用者端末により、 上記共有データの更新要求時、 上記計時機能 モジュールより獲得した時刻をデータ更新要求発行時刻と して共有デー タ更新要求に付して上記サーバに送信し、 共有データ更新要求が上記サ ーバに受信されるまで、 上記データ更新要求発行時刻を当初の送信時と 同一と したまま繰り返し送信する工程と、
上記サーバにより、上記利用者端末から共有データ更新要求を受信し、 受信した共有データ更新要求に付されたデータ更新要求発行時刻に基づ き、 上記共有データの更新順序を決定する工程を備えたことを特徴とす るデータ更新方法 c
2 2 . 共有データ更新要求は、 第 1の条件と数量の条件を 含む売り注文または買い注文であり、 データ更新要求発行時刻が昇順と なるように共有データ更新要求キューの形式でサーバの記憶部に保持さ れ、 下記ステップを有することを特徴とする請求項 2 1 に記載のデータ 更新方法。
a ) サーバの記憶部に記憶された共有データ更新要求キューの状態によ り、 下記 （ a 1 ) 〜 （ a 3 ) のいずれかのステップを実行するチェック ステップ ；
a 1 ) サーバの記憶部に記憶された共有データ更新要求キューに注文 が保持されていない場合、 処理を終了するステップ；
a 2 ) サーバ記憶部に記憶された共有データ更新要求キューの先頭の 注文が買い注文の場合、 この買い注文を主注文と し、 売り注文を対応注 文と して下記 （b ) 第 1条件比較ステップに進むステップ ；
a 3 ) サーバ記憶部に記憶された共有データ更新要求キューの先頭の 注文が売り注文の場合、 この売り注文を主注文と し、 買い注文を対応注 文と して下記 （b ) 第 1条件比較ステップに進むステップ ；
b ) サーバ記憶部に記憶された共有データ更新要求キューから対応注文 を昇順に読出し、 上記主注文と第 1の条件が一致する対応注文があるか 否かにより次のいずれかのステップを実行する第 1条件比較ステップ； 1 ) 第 1 の条件が一致する対応注文がない場合、 この主注文を不成 立注文と して上記共有データ更新要求キューから削除し、 上記 （ a ) チ エックステップに戻るステップ ；
b 2 ) 第 1 の条件が一致する対応注文がある場合、 主注文と対応注文 である買い注文と売り注文の数量を比較し、 その結果により下記いずれ かのステップを実行するステップ ；
b 2 1 ) 買い注文の数量が売り注文の数量を超えている場合、 この 買い注文とこの売り注文は不成立と し、 共有データ更新要求キュ一内の 該対応注文の次の対応注文から読出しを再開し、 上記第 1条件比較ステ ップに戻るステップ ；
b 2 2 ) 買い注文の数量が売り注文の数量と等しい場合、 この買い 注文と売り注文は成立と し、 この買い注文と売り注文をそれぞれ共有デ ータ更新要求キューから削除し、 上記 （ a ) チェックステップに戻るス テツプ ；
b 2 3 ) 売り注文の数量が買い注文の数量を越える場合、 この買い 注文と売り注文は成立と し、 この買い注文は共有データ更新要求キュー から削除し、 この売り注文の数量をこの買い注文の数量を超えた数量に 置き換えて、 売り注文のキューデータを更新して記憶し、 上記 （ a ) チ エックステップに戻るステップ。
PCT/JP1998/002550 1997-11-14 1998-06-10 Procede et dispositif pour la mise a jour de donnees WO1999026165A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP51656699A JP3617997B2 (ja) 1997-11-14 1998-06-10 データ更新方式
US09/284,736 US6981061B1 (en) 1997-11-14 1998-06-10 Method and system for updating a data system in conjunction with synchronized clock modules
EP98924554A EP0952510A4 (en) 1997-11-14 1998-06-10 SCHEME AND METHOD FOR DATA UPDATE

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP9/313073 1997-11-14
JP31307397 1997-11-14

Publications (1)

Publication Number Publication Date
WO1999026165A1 true WO1999026165A1 (fr) 1999-05-27

Family

ID=18036878

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP1998/002550 WO1999026165A1 (fr) 1997-11-14 1998-06-10 Procede et dispositif pour la mise a jour de donnees

Country Status (4)

Country Link
US (1) US6981061B1 (ja)
EP (1) EP0952510A4 (ja)
JP (1) JP3617997B2 (ja)
WO (1) WO1999026165A1 (ja)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1087304A2 (en) * 1999-09-24 2001-03-28 Nec Corporation Information management technique
JP2001331647A (ja) * 2000-03-17 2001-11-30 Sony Corp 移動体投資システム及び投資方法
JP2002312661A (ja) * 2001-04-13 2002-10-25 Sony Corp データ処理システム、データ処理方法、データ処理装置、記録媒体及びコンピュータプログラム
JP2006257915A (ja) * 2005-03-15 2006-09-28 Fujitsu Ten Ltd 機械制御装置、保守制御システム、及び、保守制御方法

Families Citing this family (44)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6065120A (en) * 1997-12-09 2000-05-16 Phone.Com, Inc. Method and system for self-provisioning a rendezvous to ensure secure access to information in a database from multiple devices
US7167892B2 (en) * 1998-03-19 2007-01-23 Isochron, Inc. System, method and apparatus for vending machine wireless audit and cashless transaction transport
US20010056508A1 (en) * 2000-05-12 2001-12-27 Kenneth Arneson Event notification system and method
US8255791B2 (en) * 2000-11-29 2012-08-28 Dov Koren Collaborative, flexible, interactive real-time displays
US7240231B2 (en) * 2002-09-30 2007-07-03 National Instruments Corporation System and method for synchronizing multiple instrumentation devices
JP2004260274A (ja) * 2003-02-24 2004-09-16 Nec Corp 携帯端末データメモリ共有システム及び携帯端末データメモリ共有機能を実現させるためのプログラム
US7724716B2 (en) 2006-06-20 2010-05-25 Apple Inc. Wireless communication system
US8094804B2 (en) 2003-09-26 2012-01-10 Avaya Inc. Method and apparatus for assessing the status of work waiting for service
US7266573B2 (en) * 2003-12-23 2007-09-04 Sap Ag Cross-system update method and system
EP1723541B1 (en) * 2004-03-12 2017-05-03 Microsoft Technology Licensing, LLC Application programming interface for administering the distribution of software updates in an update distribution system
US7953859B1 (en) 2004-03-31 2011-05-31 Avaya Inc. Data model of participation in multi-channel and multi-party contacts
US7734032B1 (en) 2004-03-31 2010-06-08 Avaya Inc. Contact center and method for tracking and acting on one and done customer contacts
US8000989B1 (en) 2004-03-31 2011-08-16 Avaya Inc. Using true value in routing work items to resources
US8738412B2 (en) 2004-07-13 2014-05-27 Avaya Inc. Method and apparatus for supporting individualized selection rules for resource allocation
US7949121B1 (en) 2004-09-27 2011-05-24 Avaya Inc. Method and apparatus for the simultaneous delivery of multiple contacts to an agent
US8234141B1 (en) 2004-09-27 2012-07-31 Avaya Inc. Dynamic work assignment strategies based on multiple aspects of agent proficiency
US7809127B2 (en) 2005-05-26 2010-10-05 Avaya Inc. Method for discovering problem agent behaviors
US7779042B1 (en) 2005-08-08 2010-08-17 Avaya Inc. Deferred control of surrogate key generation in a distributed processing architecture
US7822587B1 (en) 2005-10-03 2010-10-26 Avaya Inc. Hybrid database architecture for both maintaining and relaxing type 2 data entity behavior
US7787609B1 (en) 2005-10-06 2010-08-31 Avaya Inc. Prioritized service delivery based on presence and availability of interruptible enterprise resources with skills
US7752230B2 (en) * 2005-10-06 2010-07-06 Avaya Inc. Data extensibility using external database tables
US8737173B2 (en) 2006-02-24 2014-05-27 Avaya Inc. Date and time dimensions for contact center reporting in arbitrary international time zones
JP2007264814A (ja) * 2006-03-27 2007-10-11 Fujitsu Ltd レプリケーションデータ作成プログラム、レプリケーションデータ反映プログラムおよびデータベース装置
US7936867B1 (en) 2006-08-15 2011-05-03 Avaya Inc. Multi-service request within a contact center
US8391463B1 (en) 2006-09-01 2013-03-05 Avaya Inc. Method and apparatus for identifying related contacts
US8811597B1 (en) 2006-09-07 2014-08-19 Avaya Inc. Contact center performance prediction
US8938063B1 (en) 2006-09-07 2015-01-20 Avaya Inc. Contact center service monitoring and correcting
JP5105922B2 (ja) * 2007-03-22 2012-12-26 日本電気株式会社 情報更新システム、情報記憶サーバ、情報更新方法、及び、プログラム
US7801258B2 (en) * 2007-04-02 2010-09-21 National Instruments Corporation Aligning timebases to share synchronized periodic signals
US8959028B2 (en) 2007-07-02 2015-02-17 Crane Merchandising Systems, Inc. Apparatus and method for monitoring and control of remotely located equipment
US8504534B1 (en) 2007-09-26 2013-08-06 Avaya Inc. Database structures and administration techniques for generalized localization of database items
US8843942B2 (en) 2007-09-28 2014-09-23 Xcerion Aktiebolag Interpreting semantic application code
US8108465B2 (en) * 2007-10-31 2012-01-31 Oracle America, Inc. Method and system for request processing
US8726260B2 (en) * 2007-11-26 2014-05-13 Lenovo (Singapore) Pte Ltd Techniques for providing software patches to a computer system
US8856182B2 (en) 2008-01-25 2014-10-07 Avaya Inc. Report database dependency tracing through business intelligence metadata
US7996360B2 (en) * 2008-06-27 2011-08-09 International Business Machines Corporation Coordinating updates to replicated data
US8565386B2 (en) 2009-09-29 2013-10-22 Avaya Inc. Automatic configuration of soft phones that are usable in conjunction with special-purpose endpoints
US9516069B2 (en) 2009-11-17 2016-12-06 Avaya Inc. Packet headers as a trigger for automatic activation of special-purpose softphone applications
US9229970B2 (en) * 2009-12-07 2016-01-05 International Business Machines Corporation Methods to minimize communication in a cluster database system
US8489775B2 (en) 2010-07-21 2013-07-16 Dell Products L.P. System-wide time synchronization across power management interfaces and sensor data
US9106645B1 (en) * 2011-01-26 2015-08-11 Symantec Corporation Automatic reset for time-based credentials on a mobile device
US10296964B1 (en) * 2014-08-26 2019-05-21 Amazon Technologies, Inc. Effortless and automated reordering
CN105791339B (zh) * 2014-12-18 2020-03-31 中兴通讯股份有限公司 资源操作请求的处理方法及装置
CN112559467B (zh) * 2020-12-07 2021-08-31 掌阅科技股份有限公司 分布式系统多服务器的请求处理方法及电子设备

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH03505938A (ja) * 1989-03-28 1991-12-19 シカゴ　ボード　オブ　トレード 模擬生き市況取引システム

Family Cites Families (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US3648256A (en) * 1969-12-31 1972-03-07 Nasa Communications link for computers
US4007450A (en) * 1975-06-30 1977-02-08 International Business Machines Corporation Data sharing computer network
DE2827270A1 (de) * 1978-06-21 1980-01-03 Siemens Ag Schaltungsanordnung fuer eine vermittlungsanlage
US4432057A (en) * 1981-11-27 1984-02-14 International Business Machines Corporation Method for the dynamic replication of data under distributed system control to control utilization of resources in a multiprocessing, distributed data base system
JPS62209635A (ja) 1986-02-07 1987-09-14 Fujitsu Ltd 非同期通信におけるシステム管理フアイルアクセス方式
US5050213A (en) * 1986-10-14 1991-09-17 Electronic Publishing Resources, Inc. Database usage metering and protection system and method
EP0388162A3 (en) 1989-03-14 1993-03-03 Chicago Board Of Trade Apparatus for market trading
CA2029893A1 (en) * 1989-03-14 1990-09-15 Glen W. Belden Method and apparatus for auction market trading
JPH03158037A (ja) 1989-11-15 1991-07-08 Nec Corp 障害復旧方式
JP2575543B2 (ja) * 1990-04-04 1997-01-29 インターナショナル・ビジネス・マシーンズ・コーポレイション 同時アクセス管理方法
JPH0827755B2 (ja) * 1991-02-15 1996-03-21 インターナショナル・ビジネス・マシーンズ・コーポレイション データの単位を高速度でアクセスする方法
US5355474A (en) * 1991-09-27 1994-10-11 Thuraisngham Bhavani M System for multilevel secure database management using a knowledge base with release-based and other security constraints for query, response and update modification
EP0583196B1 (en) * 1992-08-06 2002-05-02 Fujitsu Limited Transaction processing system utilizing teletext broadcasting system
EP0586768A1 (en) * 1992-09-11 1994-03-16 International Business Machines Corporation Efficient multi-users timer
JP3146276B2 (ja) * 1994-03-10 2001-03-12 富士通株式会社 共有メモリの更新及び参照管理方式並びに参照タイミング制御方式
US5796999A (en) * 1994-04-15 1998-08-18 International Business Machines Corporation Method and system for selectable consistency level maintenance in a resilent database system
JPH089053A (ja) 1994-06-15 1996-01-12 Casio Comput Co Ltd 情報転送方法及び情報転送システム並びにそれに用いられる情報転送装置、情報受信端末
US5579318A (en) * 1994-06-30 1996-11-26 Bellsouth Corporation Processes and apparatus for maintaining data concurrence between databases in telecommunications networks
GB2296167A (en) * 1994-12-16 1996-06-19 Ibm Serialising updates in a data conferencing network
JP3367589B2 (ja) 1995-11-20 2003-01-14 株式会社富士通ゼネラル 競りシステム
JPH09282376A (ja) 1996-04-17 1997-10-31 Sharp Corp 移動通信を用いた取引システム
US6119104A (en) * 1997-11-24 2000-09-12 Keycorp Composite banking desktop system
US6182197B1 (en) * 1998-07-10 2001-01-30 International Business Machines Corporation Real-time shared disk system for computer clusters
US6209106B1 (en) * 1998-09-30 2001-03-27 International Business Machines Corporation Method and apparatus for synchronizing selected logical partitions of a partitioned information handling system to an external time reference
US6304924B1 (en) * 1999-02-02 2001-10-16 International Business Machines Corporation Two lock-free, constant-space, multiple-(impure)-reader, single-writer structures
JP3254434B2 (ja) * 1999-04-13 2002-02-04 三菱電機株式会社 データ通信装置
US20010034770A1 (en) * 2000-04-21 2001-10-25 O'brien Terry Method and device for implementing networked terminals in graphical operating environment

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH03505938A (ja) * 1989-03-28 1991-12-19 シカゴ　ボード　オブ　トレード 模擬生き市況取引システム

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
MAEKAWA M., ET AL.: "DISTRIBUTED OPERATING SYSTEM - WHAT IS COMING NEXT TO UNIX.", DISTRIBUTED OPERATING SYSTEM - WHAT IS COMING NEXT TO UNIX, XX, XX, 25 December 1991 (1991-12-25), XX, pages 169 - 176., XP002920617 *
See also references of EP0952510A4 *

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1087304A2 (en) * 1999-09-24 2001-03-28 Nec Corporation Information management technique
EP1087304A3 (en) * 1999-09-24 2002-12-11 Nec Corporation Information management technique
JP2001331647A (ja) * 2000-03-17 2001-11-30 Sony Corp 移動体投資システム及び投資方法
JP4529235B2 (ja) * 2000-03-17 2010-08-25 ソニー株式会社 移動体投資システム及び投資方法
JP2002312661A (ja) * 2001-04-13 2002-10-25 Sony Corp データ処理システム、データ処理方法、データ処理装置、記録媒体及びコンピュータプログラム
JP4734749B2 (ja) * 2001-04-13 2011-07-27 ソニー株式会社 データ処理システム、データ処理方法、データ処理装置、記録媒体及びコンピュータプログラム
JP2006257915A (ja) * 2005-03-15 2006-09-28 Fujitsu Ten Ltd 機械制御装置、保守制御システム、及び、保守制御方法
JP4578289B2 (ja) * 2005-03-15 2010-11-10 富士通テン株式会社 機械制御装置、保守制御システム、及び、保守制御方法

Also Published As

Publication number Publication date
JP3617997B2 (ja) 2005-02-09
EP0952510A4 (en) 2006-05-31
EP0952510A1 (en) 1999-10-27
US6981061B1 (en) 2005-12-27

Similar Documents

Publication Publication Date Title
WO1999026165A1 (fr) Procede et dispositif pour la mise a jour de donnees
CN111727428B (zh) 基于区块链的房间库存管理系统
KR100310264B1 (ko) 스케줄관리시스템
US8700458B2 (en) System, method, and database for processing transactions
US7383289B2 (en) Updating and maintaining data in a multi-system network using asynchronous message transfer
CN111344706A (zh) 区块链上的高容量交易性能的优化
US6622151B1 (en) Data-transfer-management system and transfer history-collection device
US7603354B2 (en) Method for enhancing the operation of a database
JPH10511793A (ja) データ管理用コンピュータシステムおよびこのシステムを動作させる方法
JP5007239B2 (ja) 分散取引照合サービス
US20220172196A1 (en) Electronic money exchanging apparatus, electronic money exchanging method, and electronic money exchanging system
US20030046226A1 (en) System and method for electronic funds transfers
US20200097889A1 (en) Delivery system and non-transitory computer readable medium
JP5670992B2 (ja) キャッシュマネージメントシステム、プログラム、及び支払代行方法
US7689567B2 (en) Error handling for intermittently connected mobile applications
US20230231922A1 (en) Device control apparatus and control method
EP0924631A2 (en) Method and system for performing work flow control in accordance with an input state of data
JP2003331171A (ja) 予約サーバ、予約販売方法、及び、プログラム
JP2008135013A (ja) 注文システム
KR102113938B1 (ko) 국부적 거래승인을 위한 네트웍 브리지
CN110262892A (zh) 一种基于分布式存储数据链的票务发布方法、装置及数据链节点
CN113449493A (zh) 基于历史数据生成报告的方法、装置、设备及存储介质
JP2002140483A (ja) 勤怠状況申告システムおよび方法
JP2002342497A (ja) 個人情報管理方法、個人情報管理装置、個人情報管理システム、個人情報管理プログラム、個人情報管理プログラムを記録したコンピュータ読み取り可能な記録媒体
JP2000322390A (ja) 分散データ処理システム

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 09284736

Country of ref document: US

AK Designated states

Kind code of ref document: A1

Designated state(s): JP US

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE

WWE Wipo information: entry into national phase

Ref document number: 1998924554

Country of ref document: EP

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWP Wipo information: published in national office

Ref document number: 1998924554

Country of ref document: EP

WWW Wipo information: withdrawn in national office

Ref document number: 1998924554

Country of ref document: EP