TWI851985B - Blockchain-based hotel room inventory management system, method, and non-transitory computer readable media thereof - Google Patents

Abstract

A blockchain-based hotel room inventory management system includes a property management system (PMS) module and an intermediate server system. The PMS module may be under a hotel’s direct control. The intermediate server system communicates with at least one online travel agency (OTA) module and/or at least one booking engine using Ethereum-based smart contracts for confirming and processing a room reservation event. If the room reservation event is confirmed to be a successful transaction, the intermediate server system also updates the successful transaction into the PMS module and a blockchain formed by multiple node servers. The blockchain contains multiple blocks arranged in a chronological order for distinguishing successful transactions of different moments. In this way, each successful transaction is prevented from wrongly preceded by a later successful transaction. And the room inventory management system neutralizes an overbooking issue accordingly.

Description

Blockchain-based hotel room inventory management system, method, and non-transitory thereof Computer-readable media

The present invention relates to a room inventory management system, and in particular to a room inventory management system based on blockchain technology.

Room reservation is an important service for hotels or travel agencies. In general room reservation services, the booking engine or online travel agency will represent the hotel and provide customers with a remote user interface so that customers can book available rooms in the hotel in advance at the planned time.

An online travel agent is a travel website that specializes in selling travel products to customers, and these travel products include room reservation services. The online travel agent signs an online agency contract with a room provider (such as a hotel) to sell its room reservation services on behalf of the room provider. In this case, the online travel agent will receive payment from customers who have reserved at least one available room and transfer the net amount of the reserved room to the hotel.

A booking engine for hotel room reservation services refers to a website that enables customers to book available rooms. The booking engine also introduces customized prices and/or payment rules to customers to make it easier for them to make decisions when booking room services.

However, if more than one customer logs into the remote user interface in a short period of time and reserves the same available room in a hotel, overbooking may occur more easily. Overbooking may cause significant damage to both the customer and the hotel. For example, in order to cope with overbooking, the hotel must arrange additional rooms, services, and/or compensation measures. Similarly, overbooking may force customers to change their travel plans within a limited time and ruin their travel experience. These inconveniences become more frequent and severe during peak travel seasons. However, the hotel is limited by the technological limitations faced by existing online travel agencies and/or booking engines in handling overbooking. Therefore, hotels need to use technological solutions to effectively mitigate room overbooking incidents.

The present invention discloses a method for a hotel room inventory management system based on a blockchain, comprising: maintaining a blockchain in each of a plurality of nodes in the hotel room inventory management system, the blockchain storing all successful transactions for a particular hotel room object, wherein the blockchain comprises a plurality of blocks individually linked in a chronological order, each block cryptographically references its direct predecessor. The block before the previous block is changed so that the data in any block cannot be changed without changing all subsequent blocks. Each block stores a successful transaction related to the specific hotel room object; when a room reservation event is received from the computer network communication coupling to the hotel room inventory management system, the master node among the multiple nodes submits a new transaction representing the room reservation event to the smart contract stored in the blockchain to confirm the room reservation. The smart contract includes a programmed standard that is configured to determine whether the submitted transaction represents a conflict among all existing successful transactions for the specific hotel room object currently stored in the blockchain based on the current quantity balance of the specific hotel room object; when the new transaction representing the room reservation event is determined to be successful based on the smart contract, the master node creates a new transaction to be attached to the room reservation event. A new block of the blockchain, wherein the new block stores data representing the new transaction as successful, wherein the creation of the new block causes the new block to be added to the blockchain in each of the multiple nodes in the hotel room inventory management system; and when the room reservation event causes the current quantity balance to meet a predetermined floating threshold, the smart contract automatically adjusts the market price of the specific hotel room object according to the predetermined floating parameter.

Another embodiment of the present invention also discloses a hotel room inventory management system, comprising: a plurality of nodes, wherein each of the plurality of nodes is configured to maintain a blockchain, the blockchain storing all successful transactions for a particular hotel room object, and wherein the blockchain comprises a plurality of blocks individually linked in chronological order, each block cryptographically references its immediately preceding block so that the block is not altered. a smart contract stored in the blockchain, wherein the smart contract includes programmed criteria configured to determine whether a submitted transaction represents a conflict among all existing successful transactions for the particular hotel room object currently stored in the blockchain based on a current quantity balance of the particular hotel room object; The master node is configured to: receive a room reservation event from a computer network communication coupled to the hotel room inventory management system; submit a new transaction representing the room reservation event to a smart contract stored in the blockchain to determine whether the room reservation event can be successful; when the new transaction representing the room reservation event is determined to be successful based on the smart contract, create a new block to be attached to the blockchain, wherein the new block stores the new transaction representing the new transaction. The transaction data is successful, and wherein the creation of the new block causes the new block to be added to the blockchain in each of the multiple nodes in the hotel room inventory management system; and wherein, when the room reservation event causes the current quantity balance to meet the predetermined floating threshold, the smart contract automatically adjusts the market price of the specific hotel room item according to the predetermined floating parameter, and the predetermined floating threshold includes the current quantity balance or the predetermined time period.

Yet another embodiment of the present invention also discloses a non-transitory computer-readable medium for a hotel room inventory management system, comprising a plurality of instructions, which when executed by one or more processors of a computerized hotel room inventory management system, causes the system to: maintain a blockchain in each of a plurality of nodes in the hotel room inventory management system, the blockchain storing all successful transactions for a particular hotel room item, wherein the blockchain comprises a chronological order of the transactions. A plurality of blocks individually linked in a blockchain, each block cryptographically references its immediately preceding block so that the data in any block cannot be changed without changing all subsequent blocks, each block storing a successful transaction for the particular hotel room item; upon receiving a room reservation event from a computer network communicatively coupled to the hotel room inventory management system, a master node among the plurality of nodes, by submitting a new transaction representing the room reservation event to an intelligent node stored in the blockchain, The smart contract is configured to determine whether the room reservation event can be successful, wherein the smart contract includes a programmed standard that is configured to determine whether the submitted transaction represents a conflict among all existing successful transactions for the specific hotel room object currently stored in the blockchain based on the current quantity balance of the specific hotel room object; and when it is determined based on the smart contract that the new transaction representing the room reservation event can be successful, a new block to be attached to the blockchain is created by the master node. Block, wherein the new block stores data representing the new transaction as successful, wherein the creation of the new block causes the new block to be added to the blockchain in each of the multiple nodes in the hotel room inventory management system; and wherein, when the room reservation event causes the current quantity balance to meet a predetermined floating threshold, the smart contract automatically adjusts the market price of the specific hotel room item according to a predetermined floating parameter, and the predetermined floating threshold includes the current quantity balance or a predetermined time period.

100, 200: Room inventory management system

120, 210: Property management system module

130: Memory

140, 218, 268, RI1, RI2, …, RIX, RIT: room inventory records

150:Channel Manager

212: Main transceiver

214: Main processor

216: Main memory

250:Intermediate servo system

260: Trading agent server

262:Intermediate transceiver

264:Intermediate processor

266: Intermediate memory

402, NPT_H: hash module

404, NPT_TS: Timestamp module

406, NPT_B: Block generation module

OTA1, OTA2, OTAM: Online travel agency module

BE1, BE2, BEN: Booking engine

NS1, NS2, NST, NSX: Node Server

NT1, NT2, NTX, NTT: Node transceiver

NP1, NP2, NPX, NPT: Node Processor

NM1, NM2, NMX, NMT: Node memory

BL1, BL2, BLY, BLXY: Blocks

S1, S2, S2.1, S3, S4: Steps

S5, S6, S7, S8, S8.1, S8.2: Steps

Figure 1 shows how a general room inventory management system works with various online travel agency modules and/or booking engines to handle customer room booking services.

FIG. 2 illustrates a room inventory management system based on blockchain according to one embodiment of the present invention.

Figure 3 is a schematic diagram showing the data exchange between a main memory, an intermediate memory, and multiple node memories in the room inventory management system of Figure 2.

Figure 4 is a schematic diagram showing a new incoming block generated by an intermediate processor in the room inventory management system of Figure 2.

FIG. 5 illustrates a room inventory management system based on blockchain that transfers the responsibility of the master node server to each node server according to an embodiment of the present invention.

Figure 6 is a schematic diagram showing the data exchange between a main memory, a temporary master node memory, and other node memories in the room inventory management system of Figure 5.

Figure 7 shows a schematic diagram of a temporary master processor generating a new incoming block in the room inventory management system of Figure 5.

Figure 8 illustrates a flow chart of the present invention for managing a blockchain-based hotel room inventory management system.

Figure 9 shows a flow chart of the dynamic pricing of the present invention.

FIG. 1 illustrates how a general room inventory management system 100 cooperates with each online travel agent module and/or booking engine to process a customer's room booking service through an intermediate channel manager 150, wherein the intermediate channel manager 150 is connected between the room inventory management system 100 and the online travel agent modules and/or booking engines and is controlled by the hotel. For example, the room inventory management system 100 cooperates with M online travel agent modules OTA1, OTA2, ..., OTAM and/or N booking engines BE1, BE2, ..., BEN, wherein both M and N are positive integers. Please note that in the above example, at least one online travel agent module and/or at least one booking engine that operates with the room inventory management system 100 can be replaced by at least one global distribution system (GDS) and/or at least one metasearch engine. However, the cost of using the above-mentioned global distribution system and/or metasearch engine for the hotel is much higher than the cost of renting the online travel agent module and/or booking engine, and the cost of using the global distribution system and/or metasearch engine may include at least building and maintaining a customized application programming interface (API) and service fees charged by a large number of customers. Therefore, general hotels tend to seek services from online travel agent modules or booking engines rather than global distribution systems or metasearch engines. The following description will focus on the use of online travel agent modules and/or booking engines, but is also applicable to the use of global analytics systems and metasearch engines.

The room inventory management system 100 is set in the domain managed by the hotel. The online travel agent modules OTA1, OTA2, ..., OTAM and/or the booking engines BE1, BE2, ..., BEN are generally set in a location far away from the hotel and are not under the control of the hotel. The channel manager 150 maintains a communication channel for each online travel agent module OTA1, OTA2, ..., OTAM and each booking engine BE1, BE2, ..., BEN to translate and forward its request to the room inventory management system 100, that is, the hotel. However, in general, each online travel agent module OTA1, OTA2, ..., OTAM and/or each booking engine BE1, BE2, ..., BEN will use different application programming interfaces and different communication protocols to convey different types of variables and parameters. Therefore, the hotel or the intermediate channel manager 150 always needs to spend a lot of money to design a customized application program interface for multiple communication channels maintained by the intermediate channel manager 150, in order to meet the different requirements of each online travel agency module OTA1, OTA2, ..., OTAM and/or each booking engine BE1, BE2, ..., BEN in terms of application program interface and communication protocol.

The room inventory management system 100 includes a traditional property management system (PMS) module 120 and a memory 130.

The traditional property management system module for hotel room reservation service includes a computerized system to facilitate the hotel's room reservation service. The traditional property management system module is a comprehensive software application that is used to cover the hotel's front-end management, sales operations, planning, reporting and other functional objectives. The traditional property management system module automates the hotel's operations, including guest room reservation services, customer information details, online reservation services, fee notices, sales hotspots, telephones, accounts receivable, sales and marketing, events, food and beverage expenses, material management, human resources and salary management, maintenance management, quality management and other facilities. The hotel's property management system module can be integrated or made to interface with third-party solutions, such as central reservation systems and yield management systems, online booking engines, back-end systems, sales hotspots, access control systems, room service optimization, energy management, payment card authorization and channel management systems. With the help of cloud computing technology, the hotel's property management system module can expand its functions to direct services to customers, such as online check-in services, room services, in-room control, communication between guests and front desk, and virtual concierge. These extended functions are mainly used by customers on their mobile phones or provided by the hotel in its lobby and/or room. Traditional property management system modules always need to provide accurate and timely information on the hotel's basic operating performance indicators, such as average daily rates or occupancy rates. Traditional property management system modules also control the inventory in storage space in food and beverage management, and decide which inventory to purchase, and decide the quantity and frequency of purchases. In this way, the traditional property management system module 120 allows customers to complete their room reservations for the hotel locally through the property management system module 120 or remotely through the above-mentioned online travel agent module and/or booking engine.

The memory 130 stores a room inventory record 140, which stores the availability of all rooms managed by the room inventory management system 100 (i.e., the hotel). According to the availability of all managed rooms, the room inventory management system 100 can classify the managed rooms into available rooms, reserved rooms, and occupied rooms. When a customer reserves an available room, the available room becomes a reserved room. When a customer checks into a reserved room, the reserved room becomes an occupied room. When a customer checks out from the hotel, the occupied room becomes an available room.

Similarly, each online travel agency module OTA1, OTA2, ..., OTAM has a room inventory record. And each booking engine BE1, BE2, ..., BEN has a room inventory record.

However, the online travel agent modules OTA1, OTA2, ..., OTAM and the booking engines BE1, BE2, ..., BEN have no motivation to dynamically synchronize the contents of their respective room inventory records with the contents of the room inventory record 140. This is because dynamically synchronizing with the contents of the room inventory record 140 will significantly increase their burden of waiting for the response of the traditional property management system module 120. Furthermore, since the channel manager 150 is only responsible for translating and conveying requests, the channel manager 150 cannot reduce the above burden on the traditional property management system module 120. More seriously, if more and more online travel agency system modules and booking engines continue to query the content of the room inventory record 140, the traditional property management system module 120 will sooner or later be unable to handle such a large number of queries and cause its system to crash. In order to avoid such a system crash, the traditional property management system module 120 can only give a longer waiting time to allow the online travel agency system module and booking engine to make a smaller number of queries, wherein the length of the waiting time can be from at least several minutes to several hours, and is determined by the number of online travel agency system modules and/or booking engines that the hotel requests services from. For example, when the number of online travel agency system modules and/or booking engines requesting services from the hotel is relatively small, the online travel agency or booking engine may be limited to querying the room inventory record 140 once every half an hour or every two hours. During the peak travel season, when the number of online travel agency system modules and/or booking engines requesting services from the hotel is larger, the above-mentioned waiting time may be set to be longer. As a result, it is inevitable that the contents of the room inventory records held by the online travel agency system module and/or the booking engine are inconsistent with the contents of the room inventory record 140, because when the online travel agency system module and/or the booking engine processes the room reservation request issued by the customer, the contents of its room inventory record may be incorrect. Even in some extreme cases, in order to reduce the unnecessary burden of both parties and concentrate on processing the incoming room reservation requests, the online travel agency system module and/or the booking engine may occasionally or more frequently skip the query to the traditional property management system module 120 to save the huge cost of querying the room inventory information. Even worse, if the hotel has actually used up all available rooms, and the online travel agency system module and/or the booking engine does not promptly query the traditional property management system module 120 to obtain the information, the subsequent overbooking of rooms is inevitable.

The origin of room overbooking incidents in traditional room inventory management systems

Figure 1 shows the details of how room overbooking events are caused in traditional technology.

Assume that a first customer accesses the property management system module 120 through the online travel agency module OTA1 to reserve an available room R1 managed by the room inventory management system 100. First, the online travel agency module OTA1 first confirms the room inventory record it holds to confirm whether the hotel has available rooms, wherein the room inventory record held by the online travel agency module OTA1 may not be consistent with the content of the room inventory record 140. If the online travel agency module OTA1 confirms that the hotel has available rooms, the online travel agency module OTA1 will forward the room reservation request of the first customer to the traditional property management system module 120. The traditional property management system module 120 then checks the content of the room inventory record 140 to confirm whether there are indeed available rooms to meet the room reservation request of the first customer. If the traditional property management system module 120 does confirm that there are available rooms in the content of the room inventory record 140, the traditional property management system module 120 will translate the room reservation request of the first customer into a successful transaction (Successful Transaction) and update the content of the room inventory record 140 accordingly to record the successful transaction. The content update of the room inventory record 140 this time includes changing the availability of room R1 to a reserved state and reducing the hotel's available room quota.

However, if a second customer accesses the traditional property management system module 120 through the reservation engine BE1 to reserve the same room R1 after the first customer issues the room reservation request, the reservation engine BE1 does not have time to be informed of the fact that the first customer has successfully reserved the room R1, and the reservation engine BE1 mistakenly confirms that the room R1 is still available. Then, the reservation engine BE1 forwards the room reservation request of the second customer to the traditional property management system module 120. Obviously, the traditional property management system module 120 will quickly determine that the second customer has not successfully reserved the room R1 after checking the content of the room reservation record 140. However, the traditional property management system module 120 still needs to wait until the booking engine BE1 queries the room booking record 140 again before it can inform the booking engine BE1 that the second customer has not successfully booked the room. If, unfortunately, the second customer has already gone to the hotel to check in before the booking engine BE1 queries again, the second customer and the hotel will inevitably face the problem of overbooking.

If the second customer is lucky enough, the hotel can still prepare an alternative available room for the second customer and give appropriate compensation. However, if the hotel confirms that the first customer's room reservation request is a successful transaction and happens to use up all available rooms, the second customer still needs to face the problem of overbooking and needs to search for available rooms in other hotels immediately. Under strong uncertainty, the second customer's travel experience is likely to be completely destroyed, and this will also reversely damage the reputation of the hotel and booking engine BE1. Worse, as mentioned above, if the hotel cooperates with more online travel agency modules and/or booking engines, or if it is in the peak travel season, the above-mentioned room overbooking problem will become more and more serious.

From a technological perspective, traditional room inventory management systems 100 have the following disadvantages:

(1) The online travel agent module and the booking engine cannot dynamically query the traditional property management system module 120 to determine the accuracy of their respective room inventory records.

(2) If the online travel agency module and the booking engine each increase the frequency of querying the traditional property management system module 120, the traditional property management system module 120's own computing workload and/or communication bandwidth will not be able to cope with the load, and thus it is more likely to cause computing errors or communication errors.

(3) The inconsistency between the data of the traditional room inventory management system 100 and the online travel agency module and/or booking engine will lead to the hotel's room overbooking incident. The room overbooking incident will be more serious when the hotel cooperates with more online travel agency modules and/or booking engines or during the peak travel season.

(4) Hotels must spend more money on developing customized application programming interfaces and communication protocols so that online travel agency modules and/or booking engines can receive the required variables and parameters to process their own room reservation requests, and even process room cancellation requests or check-out requests.

Room inventory management system of the present invention: In order to effectively reduce the room overbooking incidents caused by the above-mentioned traditional room inventory management system 100, the present invention discloses a room inventory management system based on blockchain according to an embodiment, that is, the room inventory management system based on blockchain 200 as shown in Figure 2. The room inventory management system 200 introduces an intermediate server system, which can reduce the data asymmetry between the traditional property management system module and the online travel agency and/or booking engine, and can reduce the burden of the traditional property management system module. Furthermore, the room inventory management system 200 effectively reduces the communication and maintenance costs of online travel agency modules, booking engines, and even the above-mentioned global distribution systems and meta-search engines for each hotel.

The blockchain contains multiple physical nodes, each of which theoretically stores the same content (e.g., multiple blocks). For example, each node stores multiple blocks, and the multiple blocks stored by each node have the same content. In order to respond to the occurrence of a specific event, such as a successful transaction, a new block will be generated to record the specific event. As more blocks are generated, a successful transaction history can be established, and the successful transaction history can be tracked in the blockchain. Therefore, the first benefit of using blockchain technology is traceability. Furthermore, if a specific block in a physical node is successfully hacked, since all physical nodes theoretically contain the same content, that is, the same block, such a successful hack can be easily detected and repaired by referring to the blocks in other physical nodes that have not been hacked. In other words, the second advantage of applying blockchain lies in its ability to resist hacking.

When blockchain technology is applied, the room inventory management system 200 based on blockchain can effectively ensure the correctness of each successful transaction, that is, ensure the correctness of each room reservation event. Therefore, the room inventory management system 200 based on blockchain can effectively solve the problem of room overbooking caused by using traditional room inventory management systems.

Furthermore, the blockchain-based room inventory management system 200 uses a smart contract based on Ethereum to generate a common application programming interface (API) and/or a common communication protocol to communicate with the online travel agencies and/or the booking engines. In some examples, the shared API is used for multiple online travel agencies and/or multiple booking engines based on Ethereum, and the common communication protocol is used for multiple online travel agencies and/or multiple booking engines that are not based on Ethereum. In this way, the system maintenance costs and communication costs incurred by the online travel agencies and/or the booking engines can be significantly reduced, wherein the system maintenance and communication include transmitting room booking events or updating room inventory records to the online travel agency modules and/or booking engines. This is because the Ethereum-based smart contracts are open and easy to use in programming language design, including the transfer of fewer and easier to understand variables and parameters. The above-mentioned cost reduction benefits are also valid for the same reason when the blockchain-based room inventory management system 200 cooperates with the global distribution system and/or meta-search engine.

Smart contracts are a technology developed under Ethereum and are also an important auxiliary technology in the blockchain technology used in this invention. Ethereum is an open source, blockchain-based distributed computing system and operating system characterized by the functionality of smart contracts. Ethereum provides a decentralized and Turing-complete virtual machine, namely the Ethereum virtual machine, which can use a node network to execute scripts.

Ethereum's smart contracts are based on different computer languages, which developers use to program their own functions. Smart contracts are high-level programming abstractions that are translated into Ethereum virtual machine bytecode and deployed in the Ethereum blockchain for execution. Smart contracts can open up the possibility of proving functionality, such as a self-contained provably fair casino. Ethereum blockchain applications generally point to decentralized applications because they are based on the decentralized Ethereum virtual machine and its smart contracts. Application examples of the Ethereum blockchain include: digital signature algorithms, securitized tokens, digital rights management, crowdfunding, prediction markets, remittances, online gambling, social media platforms, financial transactions, and identity systems. Due to the Turing-complete nature of Ethereum, smart contracts can provide high flexibility in functional design and implementation. Furthermore, due to the open source and easy-to-implement nature of Ethereum-based smart contracts, the blockchain-based room inventory management system 200 has the above-mentioned advantages when communicating with online travel agency modules and/or booking engines with the assistance of Ethereum-based smart contracts.

The room inventory management system 200 based on blockchain includes a novel property management system module 210 and an intermediate server system 250. The property management system module 210 can be set in a hotel, so that the hotel can directly control the property management system module 210. The intermediate server system 250 can be set remotely from the property management system module 210. In one example, the intermediate server system 250 pre-processes or processes room reservation events for the property management system module 210, so that the intermediate server system 250 can greatly reduce the processing burden for the property management system module 210. In one example, a room booking event includes at least an internal room booking request and an internal room cancellation/check-out request issued by a hotel, and an external room booking request and an external room cancellation request issued by an online travel agent module and/or a booking engine. The external room booking request and the external room cancellation request can be issued by an online travel agent module and/or a booking engine to book or cancel at least one room of the hotel with the assistance of the application programming interface or the communication protocol, wherein the application programming interface and the communication protocol are developed using smart contracts based on Ethereum. The internal room booking/internal room check-out request occurs when a customer directly handles a room booking procedure in the hotel, or when a customer in the hotel decides to check out. Furthermore, the intermediate server system 250 uses an Ethereum-based smart contract to communicate about room reservation events to achieve low-cost communication with the online travel agency module and/or the reservation engine. This is because the application programming interface and/or communication protocol used for communication is implemented using an Ethereum-based smart contract, which makes the design simple.

In one example, the property management system module 210 is specially designed to work with the intermediate server system 250 by sharing the same application program interface, that is, the same remote procedure call (RPC) program. In this way, the communication between the property management system module 210 and the intermediate server system 250 can take less processing time and achieve higher efficiency. This high efficiency will be more obvious when the room inventory management system 200 needs to process a large number of room reservation events in a short time, such as during the peak travel season.

The property management system module 210 includes a main transceiver 212, a main processor 214, and a main memory 216. In each example of the present invention, the main processor 214 is a computer processor, and the main memory 216 is a non-volatile computer readable memory. The main transceiver 212 can handle the communication with the intermediate server system 250, but does not directly communicate with the online travel agent OTA1, OTA2, ..., OTAM and/or the booking engine BE1, BE2, ..., BEN. The main memory 216 maintains a room inventory record 218 (as shown in Figure 3) for the property management system module 210 for the hotel to manage its rooms. The room inventory record 218 records at least the availability of each room in the hotel and the number of available rooms in the hotel. The main processor 214 can refer to and/or update the room inventory record 218 in response to the occurrence of a room reservation event. For example, the main processor 214 can reduce the number of available rooms in the hotel and/or turn off the availability of the reserved room in response to a room reservation request. The main processor 214 can also increase the number of available rooms in the hotel and/or turn on the availability of the reserved room in response to a room reservation cancellation request or a check-out request.

The intermediate server system 250 applies blockchain technology. Furthermore, the intermediate server system 250 includes a transaction proxy server 260 and a plurality of node servers, such as X node servers NS1, NS2, ..., NSX as shown in FIG. 2, where X is a positive integer. The node servers NS1, NS2, ..., NSX will form a blockchain, and each node server will store substantially the same data to ensure data consistency and data traceability between each other.

The transaction proxy server 260 is like the core of the intermediate server system 250, and includes an intermediate transceiver 262, an intermediate processor 264, and an intermediate memory 266. In some examples, the transaction proxy server 260 plays the role of a trusted node, which is authorized to generate new blocks in the blockchain formed by the intermediate server system 250. Similarly, in some examples, the intermediate processor 264 is a computer processor, and the intermediate memory 266 is a non-volatile computer readable memory. When any of the online travel agent modules OTA1, OTA2, ..., OTAM, booking engines BE1, BE2, ..., BEN, or property management system module 210 issues a room reservation request, the intermediate transceiver 262 receives the room reservation request and forwards it to the intermediate processor 264. In some examples, the intermediate transceiver 262 can be implemented as an application programming interface server, and the application programming interface server translates the room reservation request into a form that can be easily understood by the property management system module 210 and the intermediate server system 250 based on the Ethereum-based smart contract stored in the intermediate memory 266, that is, replaces the function of the channel manager 150. The intermediate memory 266 maintains a room inventory record 268 as shown in FIG. 3 , wherein the room inventory record 268 is implemented by at least one of the smart contracts based on Ethereum, so that the intermediate processor 264 can operate (e.g., access, update, or audit) the room inventory record 268 based on instructions compatible with the smart contracts based on Ethereum. The communication between the intermediate server system 250 (especially the transaction agent server 260), the online travel agent module OTA1, OTA2, ..., OTAM, and/or the booking engine BE1, BE2, ..., BEN is supported by the smart contracts stored in the intermediate memory 266. The intermediate processor 264 uses at least one of the smart contracts to access and/or update the content of the room inventory record 268. In some examples, the intermediate transceiver 262 can be located at a distance from the intermediate processor 264 and/or the intermediate memory 266 to separate the translation process of the application programming interface server from the management process of the room inventory record to avoid overloading the system burden of the transaction agent server 260.

In some examples, the intermediate processor 264 determines whether a room booking event is a successful transaction, wherein the room booking event may be a room booking request, a check-out request, or a room cancellation request, and the subject that issues the room booking event may be one of the property management system module 210, the online travel agency module OTA1, OTA2, ..., OTAM, and/or the booking engine BE1, BE2, ..., BEN. The room booking event issued by one of the online travel agency modules OTA1, OTA2, ..., OTAM, and/or the booking engine BE1, BE2, ..., BEN may be an external room booking request or an external room cancellation request initiated by a customer (when the customer has previously successfully booked a room). The room reservation event issued by the property management system module 210 may be an internal room reservation request, an internal room cancellation request, or an internal check-out request. When receiving a room reservation request, the intermediate processor 264 checks the room inventory record 268 to confirm whether the room reservation request is approved, for example, based on the availability of the requested room or based on whether the hotel will be oversold if the room reservation request is approved. If the intermediate processor 264 approves the room reservation request, the intermediate processor 264 generates a successful transaction accordingly. Similarly, upon receiving an internal check-out request, an internal room cancellation request, or an external room cancellation request, the intermediate processor 264 checks the room inventory record 268, releases the room being canceled or checked out, and generates a successful transaction accordingly.

In order to support various complex functions running under blockchain technology, the intermediate server system 250 applies at least one Ethereum-based smart contract stored in the intermediate memory 266. As mentioned earlier, through the flexibility of smart contracts in designing and implementing functions, the intermediate server system 250 can combine traditional room reservation requirements and most of the latest blockchain technology to achieve a variety of different functions.

In some examples, after the intermediate processor 264 determines that the room reservation event is a successful transaction, the intermediate processor 264 adds the successful transaction to the room inventory record 268 to update the room inventory record 268. Furthermore, the intermediate processor 264 can synchronize the content of the updated room inventory record 268 to each node server NS1, NS2, ..., NSX, that is, update the blockchain formed by the node servers NS1, NS2, ..., NSX. Therefore, the node servers NS1, NS2, ..., NSX can be used as backup records of the room inventory record 268.

In some examples, as shown by the widely known blockchain technology, the block updates of the node servers NS1, NS2, ..., NSX mentioned above may include block competition between different node servers in the same blockchain, so that some blocks are added to some node servers of the blockchain and then abandoned. However, the block updates of the node servers NS1, NS2, ..., NSX described here are also assumed to include such a situation where blocks are added and then abandoned, and will not be elaborated separately. Therefore, each node server NS1, NS2, ..., NSX is assumed to include multiple substantially identical blocks, and these blocks ultimately include substantially identical transaction history.

In this way, the content of the room inventory record 268 can be better protected from being tampered with or destroyed because the intermediate processor 264 can always find the correct backup of the room inventory record 268 in any node server of the node servers NS1, NS2, ..., NSX.

Each node server NS1, NS2, ..., NSX has a node transceiver, a node processor, and a node memory. The node processor is a computer processor. And the node memory is a computer readable memory. The node transceiver can receive instructions from the intermediate processor 264 and transmit data to the intermediate processor 264 when a successful transaction corresponding to a room reservation request occurs. The node memory can store a backup of the content of the room inventory record 268 for future updates and/or audits. The node processor can process instructions from the intermediate processor 264 and decide which data to use to respond to the intermediate processor 264. As shown in FIG. 2, for example, the node server NS1 has a node transceiver NT1, a node processor NP1, and a node memory NM1; the node server NS2 has a node transceiver NT2, a node processor NP2, and a node memory NM2; and the node server NSX has a node transceiver NTX, a node processor NPX, and a node memory NMX.

FIG. 3 is a conceptual diagram showing the relationship between the main memory 216, the intermediate memory 266, and the room inventory records of the node memories NM1, NM2, ..., NMX, that is, the relationship between the room inventory record 218, the room inventory record 268, and the room inventory records RI1, RI2, ..., RIX. Each node memory NM1, NM2, ..., NMX stores the same plurality of smart contracts as those stored in the room inventory record 268. And the room inventory records RI1, RI2, ..., RIX are also implemented using the smart contracts stored in the node memories NM1, NM2, ..., NMX. Similar to the intermediate processor 264 and the intermediate memory 266, each node processor NP1, NP2, ..., NPX uses the smart contracts implementing the room inventory records RI1, RI2, ..., RIX to access and update the contents of the room inventory records RI1, RI2, ..., RIX.

In some examples, the intermediate processor 264 first updates the room inventory record 268 in response to the generation of a successful transaction. Furthermore, the intermediate processor 264 transmits the updated content of the room inventory record 268 to the property management system module 210 through the main transceiver 212, so that the main processor 214 can update the room inventory record 218 accordingly, and synchronize the content of the room inventory record 218 with the updated content of the room inventory record 268. The intermediate processor 264 also generates a new block in response to the updated content of the room inventory record 268, and the new block stores at least all the latest successful transactions of the property management system module 210. In some examples, the intermediate processor 264 requires at least one smart contract stored in the intermediate memory 266 to execute a complete instruction (such as calculating or updating a variable) to generate the new block. For example, when encountering Y different successful transactions that occur in chronological order, the intermediate processor 264 may generate block BL1 at time t1, block BL2 at time t2, ..., and a most recent block BLY at time tY, where Y is a positive integer. Time t1 is earlier than time t2. Time t2 is earlier than time t(Y-1), and time t(Y-1) is earlier than time tY. Time tY represents the most recent time point at which a successful transaction occurred. Block BL1 contains all successful transactions that have occurred at time t1. Block BL2 contains one more successful transaction that occurred at time t2 than block BL1, that is, block BL2 contains all successful transactions that occurred at time t2. Similarly, block BLY contains all successful transactions that occurred at time tY.

Under blockchain technology, each node server NS1, NS2, ..., NSX is obliged to synchronize and update the room inventory records RI1, RI2, ..., RIX contained therein so that the contents thereof are synchronized with the contents of the room inventory record 268. Therefore, after receiving the most recently produced block BLY through the respective node transceivers NT1, NT2, ..., NTX, the node processors NP1, NP2, ..., NPX each merge the most recently produced block BLY into their own room inventory records RI1, RI2, ..., RIX. In some examples, the node processors NP1, NP2, ..., NPX require the assistance of at least one smart contract to synchronously execute the instructions involved in the most recent successful transaction to complete the content update of their respective room inventory records RI1, RI2, ..., RIX. These updates may include updating specific local variables or specific global variables. The local variables may include the availability or price of each room. The global variables may include conditional discounts or dynamically adjusted room prices.

FIG. 4 illustrates the details of how the intermediate processor 264 generates a new block. The intermediate processor 264 includes a hashing module 402, a timestamp module 404, and a block generation module 406. As previously described, the intermediate processor 264 generates a new block in response to a successful transaction. After the intermediate processor 264 confirms the successful transaction, the hashing module 402 generates a hash value for the new block, and the timestamp module 404 generates a unique timestamp for the new block. For example, the hash module 402 generates a substantially unique corresponding hash value HS1, HS2, ..., HSY for each of the Y blocks BL1, BL2, ..., BLY, and the timestamp module 404 generates a substantially unique corresponding timestamp TS1, TS2, ..., TSY for each of the Y blocks BL1, BL2, ..., BLY.

Methods for generating hash values are well known to those skilled in the art of blockchain technology, and therefore, these methods are not specifically described here. However, each generated hash value has its own randomness, so that each generated hash value can be substantially unique. In some examples, the generated timestamp may correspond to the moment when the intermediate processor 264 confirms the successful transaction, or to, for example, the moment when the room reservation request is issued by the property management system module 210, the online travel agent module OTA1, OTA2, ..., OTAM, or the booking engine BE1, BE2, ..., BEN. In this way, each block BL1, BL2, ..., BLY will each have a substantially unique hash value and a substantially unique timestamp. And the most recently generated block BLY will have the latest timestamp among all generated blocks.

Corresponding to the successful transaction, the block generation module 406 introduces a substantially unique hash value from the hash module 402 and a substantially unique timestamp from the timestamp module 406 to generate a block header. For example, when a recent successful transaction occurs, the block generation module 406 introduces the hash value HSY and the timestamp TSY to generate a block header BHY for the block BLY to be generated. In this way, the block generation module 406 can generate block headers BH1, BH2, ..., BHY respectively.

Furthermore, in response to the successful transaction, the block generation module 406 generates a new block, which integrates a corresponding block header, the content of the successful transaction, at least one smart contract, and the content of the previous generated block. For example, in response to a recent successful transaction, the block BLY generated by the block generation module 406 includes the block header BHY, at least one smart contract loaded from the intermediate memory 266, and the content of the previous block BL(Y-1), wherein the block BL(Y-1) is not marked due to the need for simplicity of the diagram. In this way, the recently generated block BLY can include the content of all previous blocks BL1, BL2, ..., BL(Y-1). In addition, all previously generated blocks BL1, BL2, ..., BL(Y-1) corresponding to all existing successful transactions can also be audited by only referring to the most recently generated block BLY.

Finally, the block generation module 406 adds the new block to the blockchain formed by the node servers NS1, NS2, ..., NSX to update the blockchain. For example, the block generation module 406 adds the latest generated block BLY to the blockchain that already includes multiple blocks BL1, BL2, ..., BL(Y-1) to update the blockchain.

In some examples, each online travel agent module OTA1, OTA2, ..., OTAM and/or booking engine BE1, BE2, ..., BEN is allowed to access the blockchain formed by node servers NS1, NS2, ..., NSX directly or through the transaction agent server 260. In this way, by using the blockchain that always substantially maintains the latest transactions, each online travel agent module OTA1, OTA2, ..., OTAM and/or booking engine BE1, BE2, ..., BEN can always actively confirm the number of available rooms and/or the availability of a specific room by timely referring to a recently generated block. In this way, the problem of room oversale events can be substantially solved.

In addition, since most of the tasks of the property management system module 210 are transferred to the intermediate server system 250, the overload problem of the property management system module in the prior art can also be effectively and substantially avoided.

In some examples, the multiple blocks included in the blockchain formed by the access node servers NS1, NS2, ..., NSX are established and audited through their respective block headers (more precisely, through their respective hash values). In some examples, the blockchain formed by the access node servers NS1, NS2, ..., NSX uses Merkle Tree technology, so that each block of the blockchain has a substantially unique Merkle Root. If a block (e.g., block BL1) is tampered with on one of the node servers NS1, NS2, ..., NSX, any individual with access to the blockchain can simply audit the blockchain and find the tampered block BL1 on the specific node server. The auditing process includes: (1) calculating the Merkle root value of block BL1 on each of the node servers NS1, NS2, ..., NSX; (2) comparing the Merkle root values of block BL1 calculated by each of the node servers NS1, NS2, ..., NSX to find inconsistencies in the tampered block BL1 on at least one of the node servers. More precisely, since the hacked block BL1 will definitely have a different Merkle root value from the unhacked block BL1 on other node servers, the above comparison procedure can easily find such different Merkle root values. The hacked block BL1 can also be corrected by referring to the unhacked block BL1 on other node servers. In this way, the blocks on the blockchain can be guaranteed to be correct, so that the room inventory records stored on each node server can also be preserved. In some examples, an individual is authorized to access the blockchain to audit or even modify the blockchain, where the individual may be a processor of the property management system module 210, the transaction agent server 260, or any of the node servers NS1, NS2, ..., NSX. The above examples of auditing and modifying block BL1 are also applicable to other blocks in the blockchain.

In some examples, each successful transaction can be correctly tracked by referring to the block header of any block BL1, BL2, ..., BLY on any node server NS1, NS2, ..., NSX (more precisely, by the respective timestamp of the block), which is part of the above-mentioned auditing process. The tracking process can also be implemented using at least one auditing smart contract stored in the intermediate memory 266 or each node memory NM1, NM2, ..., NMX, and its host can be the above-mentioned individual authorized to access the blockchain. Such an individual may include the intermediate processor 264 included in the transaction proxy server 260, or the node processor of any node server NS1, NS2, ..., NSX. Preferably, such an auditing process is led by the intermediate processor 264 to perform real-time and non-confusion updates. The tracking process includes: (1) searching for the block headers BH1, BH2, ..., BHY of blocks BL1, BL2, ..., BLY; (2) tracking the time stamps TS1, TS2, ..., TSY of blocks BL1, BL2, ..., BLY to successfully identify each successful transaction that caused the blocks BL1, BL2, ..., BLY. With the help of the time stamps TS1, TS2, ..., TSY, the order of occurrence of each successful transaction can be correctly confirmed according to the time arrangement. In this way, overbooking events can be better identified and avoided, where the overbooking event is caused by the failure to promptly notify the online travel agent module or booking engine of an earlier successful transaction, resulting in the erroneous acceptance of another later successful transaction.

In some examples, the multiple smart contracts stored in the room inventory record 268 include at least one dynamic pricing smart contract, which can determine at least one temporary and variable room price based on a temporary number of available rooms stored in the room inventory record 268. The intermediate processor 264 dynamically adjusts the temporary room price and transmits the adjusted room price to the property management system module 210, the online travel agent module OTA1, OTA2, ..., OTAM and/or the booking engine BE1, BE2, ..., BEN via the intermediate transceiver 262. Similarly, after the main transceiver 212 receives the adjusted room price, the main processor 214 also dynamically updates the adjusted room price to the room inventory record 218.

Compared to the conventional room inventory management system 100, the room inventory management system 200 has the following advantages: (1) by ensuring that all successful transactions are recorded in chronological order, the problem of overselling is overcome; (2) with the assistance of the intermediate server system 250, the burden, processing time and bandwidth of the property management system module in confirming successful transactions and/or updating room inventory records are reduced; and (3) the accuracy and traceability of room inventory records are improved.

In the above-mentioned embodiment, the room inventory management system 200 applies a central module (i.e., the transaction agent server 260) to manage the main tasks between the node servers NS1, NS2, ..., NSX included in the intermediate server system 250. However, another embodiment of the present invention will better balance the responsibility of managing the above-mentioned tasks between the node servers NS1, NS2, ..., NSX. More precisely, any node server NS1, NS2, ..., NSX can be temporarily designated as a master node server (Master Node Server) to manage all node servers NS1, NS2, ..., NSX for a period of time, and after the end of the period, another node server can be designated as a new master node server to continue to manage all node servers NS1, NS2, ..., NSX for another period of time. In some examples, the transfer of the master node server responsibility between node servers NS1, NS2, ..., NSX can be performed from time to time, periodically, or randomly. Furthermore, the method of designating the master node server among node servers NS1, NS2, ..., NSX can include selection, sequential rotation, or according to a predetermined rule. The predetermined rule can include dynamically designating a node server with a smaller burden or the smallest burden as the master node server, wherein the calculation of the burden can be determined based on information including real-time system load, real-time data storage, and/or real-time transmission bandwidth. Therefore, any node server NS1, NS2, ..., NSX can avoid bearing an unbearable load or even causing a failure.

FIG. 5 illustrates a room inventory management system 500 according to another embodiment of the present invention. The room inventory management system 500 includes a property management system module 210 and an intermediate server system 520. The nature and layout of the property management system module 210 are the same as those described in FIG. 2 above, so they will not be described separately. As shown in FIG. 2 above, the intermediate server system 520 includes a plurality of node servers NS1, NS2, ..., NSX. However, the main difference between the room inventory management system 200 and the room inventory management system 500 is that, with the assistance of a consensus algorithm, the room inventory management system 500 can select any one of the plurality of node servers NS1, NS2, ..., NSX as a master node server to replace the transaction agent server 260. The master node server and the components it contains inherit at least the same structure and function as the transaction proxy server 260 and its components. Therefore, the parts of the master node server that are the same as the transaction proxy server 260 will not be described in detail below.

The consensus algorithm used to select the master node server from multiple node servers NS1, NS2, ..., NSX may include sequential determination, random determination, and/or determination by introducing polling consensus of all node servers. The selected master node server will be responsible for management work for a period of time. After the end of the period, another election will be held to determine the next master node server, so that the previously selected master node server can be relieved of its responsibilities until it is selected as the master node server again. The following description is based on the node server NST being temporarily selected as the master node server and performing functions similar to those of the previous transaction agent server 260.

FIG. 6 is a schematic diagram showing the relationship between the multiple room inventory records included in the main memory 216 and the multiple room inventory records in other node memories NM1, NM2, ..., NMX (including the master node memory NMT included in the master node server MNS), that is, a schematic diagram showing the relationship between the room inventory record 218 and the multiple room inventory records RI1, RI2, ..., RIX (including the room inventory record RIT in the master node memory NMT). Similarly, the multiple room inventory records RI1, RI2, ..., RIX are implemented by multiple smart contracts stored in the node memories NM1, NM2, ..., NMX respectively. And the node processors NP1, NP2, ..., NPT, ..., NPX will use these smart contracts to access and/or update their respective room inventory records RI1, RI2, ..., RI. X. In some examples, the master node processor NST will first update the temporary master room inventory record RIT in response to the occurrence of a successful transaction. Furthermore, the master node processor NST will transfer the updated content of the temporary master room inventory record RIT to the property management system module 210 through the master node transceiver NTT and the main transceiver 212, so that the main processor 214 can update the room inventory record 218 to substantially synchronize with the updated content of the temporary master room inventory record RIT. The master node processor NPT also corresponds to the updated content of the temporary master room inventory record RIT, generating a new block that stores at least all currently successful transactions of the property management system module 210. It should be noted that the smart contracts stored in the respective memories NM1, NM2, ..., NMX of each node server NS1, NS2, ..., NSX are similar to the smart contracts stored in the intermediate memory 266. Therefore, in some examples, the master node processor NPT can load at least one smart contract stored in the master node memory NMT to execute complete instructions to generate a new block, such as calculating and updating variables. For example, after Y different successful transactions occurred in chronological order, the previous master node processor and/or transient master node processor NPT may generate a block BL1 at time point t1, a block BL2 at time point t2, ..., and a most recent block BLY at time point tY, where Y is a positive integer. Time point t1 is earlier than time point t2, time point t2 is earlier than time point t(Y-1), and time point t(Y-1) is earlier than time point tY. Time point tY represents the time point when the most recent successful transaction occurred. Block BL1 contains all successful transactions up to time point t1. Compared with block BL1, block BL2 contains one more successful transaction that occurred at time point t2, that is, block BL2 contains all successful transactions until time point t2. Similarly, block BLY contains all successful transactions until time point tY.

As mentioned above, in blockchain technology, each node server NS1, NS2, ..., NSX needs to synchronize the room inventory records RI1, RI2, ..., RIX held by each node with the contents of the master room inventory record RIT at that time. Therefore, after receiving the most recently generated block BLY through each node transceiver NT1, NT2, ..., NTX (except the master node transceiver NTT at that time), each node processor NP1, NP2, ..., NPX (except the master node processor NPT at that time) integrates the most recently generated block BLY into each room inventory record RI1, RI2, ..., RIX (except the master room inventory record RIT at that time). In some examples, node processors NP1, NP2, ..., NPX require the assistance of at least one smart contract to synchronously execute the instructions involved in the most recent successful transaction to complete the update of each room inventory record RI1, RI2, ..., RIX. These updates may, for example, include updates to certain local variables (such as room availability or room prices), or include updates to certain global variables (such as conditional discounts or dynamically adjusted room prices).

FIG. 7 illustrates the details of how the transient master node processor NPT generates a new block. The transient master node processor NPT includes a hash module NPT_H, a timestamp module NPT_TS, and a block generation module NPT_B. As previously described, the transient master node processor NPT generates a new block corresponding to a successful transaction. When the transient master node processor NPT confirms the successful transaction, the hash module NPT_H generates a substantially unique hash value for the new block, and the timestamp module NPT_TS generates a substantially unique timestamp for the new block. For example, the hash module NPT_H generates Y substantially unique hash values HS1, HS2, ..., HSY for Y blocks BL1, BL2, ..., BLY, and the timestamp module NPT_TS generates Y substantially unique timestamps TS1, TS2, ..., TSY for Y blocks BL1, BL2, ..., BLY.

Similar to the previous embodiments, the method of generating hash values is well known to those skilled in the art of blockchain technology, and therefore, the method of generating hash values will not be described in detail here. Furthermore, in some examples, the generated timestamp may correspond to the time point when the transient master node processor NPT confirms the successful transaction or the time point when the room booking event is initiated, wherein the room booking event may be initiated by one of the property management system module 210, the online travel agent module OTA1, OTA2, ..., OTAM, and/or the booking engine BE1, BE2, ..., BEN. In this way, each block BL1, BL2, ..., BLY should have its substantially unique hash value and timestamp. And the most recently generated block BLY has the most recent timestamp among all the blocks at that time.

The block generation module NPT_B generates a new block header by introducing the actual unique hash value from the hash module NPT_H and the actual unique timestamp from the timestamp module NPT_TS corresponding to the successful transaction. For example, in order to generate the latest block BLY to be generated corresponding to the occurrence of the latest successful transaction, the block generation module NPT_B introduces the hash value HSY and the timestamp TSY to generate a block header BHY. In this way, the block generation module NPT_B generates block headers BH1, BH2, ..., or BHY respectively.

Furthermore, in response to the successful transaction, the block generation module NPT_B generates a new block, wherein the new block includes a corresponding block header, the content of the successful transaction, at least one smart contract, and the content of the previously generated block. For example, in response to a recent successful transaction, the block generation module NPT_B generates a block BLY, which includes a block header BHY, the content of the recent successful transaction, at least one smart contract loaded by the transient master node memory NMT, and the content of the previously generated block BL(Y-1) (not shown for the sake of simplifying the diagram). In this way, the recently generated block BLY will include the content of all previously generated blocks BL1, BL2, ..., BL(Y-1). Furthermore, all previously generated blocks BL1, BL2, ..., BL(Y-1) corresponding to all previously generated successful transactions can be audited by only referring to the most recently generated block BLY.

Finally, the block generation module NPT_B will add the most recently generated block to the blockchain formed by the node servers NS1, NS2, ..., NSX to update the blockchain. For example, the block generation module NPT_B will add the most recently generated block BLY to the blockchain that already contains blocks BL1, BL2, ..., BL(Y-1) to update the blockchain.

Similar to the room inventory management system 200, the room inventory management system 500 has substantially the same variation embodiments, properties, and advantages as previously described for the room inventory management system 200. In addition, the responsibility of the master node server is transferred between the node servers NS1, NS2, ..., NSX occasionally, randomly, periodically, or according to a predetermined rule, wherein the predetermined rule is used to balance the responsibility of the master node server between the node servers NS1, NS2, ..., NSX. In this way, the node servers NS1, NS2, ..., NSX can better balance their respective burdens and avoid unnecessary failure events.

In a preferred embodiment of the present invention, as shown in the flow chart of Figure 8, the management method of the room inventory management system 200 based on the blockchain of the present invention includes the following steps: Step S1, maintaining a blockchain in each of the multiple node servers of the hotel room inventory management system 200, the blockchain storing all successful transactions regarding specific hotel room items, wherein the hotel room inventory management system 200 has multiple node servers and each node server maintains a copy of the blockchain. The blockchain consists of 10 blocks BLY that are individually linked in chronological order. Each block cryptographically references its immediate preceding block, so the data in any block cannot be changed without changing all subsequent blocks BLY. Each block stores data on successful transactions for a specific hotel room item.

In step S2, a room reservation event is received by a master node server among a plurality of node servers by being communicatively coupled to the hotel room inventory management system 200 via a computer network, and a room reservation event is determined by submitting a new transaction representing the room reservation event to a basic smart contract, which is stored in a blockchain. The room reservation event is received from a hotel, a reservation engine, an online travel agency (OTA), a global distribution system, and/or a meta-search engine via a computer network. The communication of the hotel room inventory management system 200 via the computer network at least partially complies with a remote procedure call (RPC) protocol. The transaction agent server 260 maintains the room inventory record 268, and before step S2, it also checks whether the current room inventory record 268 satisfies the room reservation event (the room inventory record 268 and the current room inventory are recorded based on the previous room reservation event and may not be completely equivalent to the actual room inventory in the blockchain). When the room inventory record 268 satisfies the room reservation event, in step S2.1, the basic smart contract receives a new transaction of the room reservation event, and based on the actual quantity balance of the specific hotel room object from the blockchain, executes a formatted standard to confirm whether the submitted new transaction conflicts with all existing successful transactions for the specific hotel room object currently stored in the blockchain. In a preferred embodiment, based on programming standards, the underlying smart contract confirms the current quantity balance stored in the latest block of the blockchain, the hotel location of the specific hotel room item, the room type of the specific hotel room item, and/or the time range of the room reservation event with respect to the specific hotel room item to determine whether the submitted new transaction causes any conflict.

The transaction proxy server 260 can be considered as an oracle. When the blockchain-based room inventory management system 200 is built on a private blockchain, an oracle is not necessary. However, if the blockchain-based room inventory management system 200 is built on a public blockchain, such as Ethereum, the transaction proxy server 260 may have to be an oracle based on a decentralized consensus algorithm.

In step S3, when it is determined based on the basic smart contract that the new transaction representing the room reservation event can be successful, the master node server creates a new block to be attached to the blockchain. A new block is created only when the new transaction representing the room reservation event can be confirmed as successful by the basic smart contract. The new block stores data indicating the success of the new transaction, and the creation of the new block causes the new block to be added to the blockchain in each of the multiple node servers of the hotel room inventory management system 200. If the submitted transaction indicates a conflict, the transaction will be considered failed and immediately abandoned. Block BLY of the blockchain may contain successful transactions of one of room booking request, room cancellation request or room checkout request, and it is linked in chronological order with a timestamp to register when the successful transaction was issued/received. All successful transactions are recorded in the blockchain and cannot be changed.

In step S4, the basic smart contract is configured to, in response to a query about the current quantity balance of a specific hotel room item received through a computer network or transaction proxy server 260, contact the latest block in the blockchain (or the corresponding block according to a verification algorithm such as a Merkle tree) representing the actual quantity balance of the specific hotel room item to the sender of the query. The transaction proxy server 260 pushes or synchronizes the current quantity balance to the PMS module 210 to keep track of the room inventory record 268 and the room inventory record 218 of the PMS module 210, so that the OTA module M and the booking engine BEN can access the current quantity balance of the room inventory.

In addition to the new transaction, the data stored in the new block further represents all previous successful transactions for a specific hotel room object. The data stored in the new block includes a unique header, a date representing the new transaction, and encrypted data representing the contents of the block immediately preceding the new block. The unique block header includes a unique hash value of the new block, a unique timestamp representing the time when the new transaction was issued or received. The specific hotel room object is a selected room type in a selected hotel on a selected date or a selected time period. A room booking event can be a room reservation/booking request, a room checkout request, or a room cancellation request.

In a preferred embodiment, each hotel has its own blockchain, and different hotels have different blockchains. In another preferred embodiment, all different hotels can share the same blockchain. Another successful transaction from a different hotel room object may occur substantially at the same time as the new transaction, and all successful transactions of different hotel room objects may occur substantially at the same time as the new transaction in the hotel room inventory management system 200 as a new transaction about the hotel room object, which is confirmed by the basic smart contract and encapsulated into a new block by the master node server.

When the base smart contract receives a room booking event and the room booking event is a room booking request, the programmatic standards of the base smart contract verify whether the current quantity balance of a specific hotel room item exceeds the predetermined maximum threshold after executing the room booking request (to ensure that the room inventory is sufficient). The base smart contract calculates the actual quantity balance, and the master node server encapsulates the actual quantity balance, unique timestamp, unique hash value, and room booking request into a new block. The new block is attached to the blockchain of the master node server and broadcast to other node servers. When a new block is successfully appended to the blockchain, the transaction agent server 260 automatically updates its room inventory record 268 from the new block in the blockchain (through the underlying smart contract) to make the current quantity balance close to the actual quantity balance so that the user can reserve/book a hotel room. The room inventory record 268 (or the current quantity balance) may be different from the actual quantity balance because the next new block is broadcast from time to time, and the transaction agent server 260 can only obtain information from the block that is newly added to the blockchain and confirmed by the majority of node servers through the underlying smart contract. After the new block is added to the blockchain, the current quantity balance on the specific hotel room item in the room inventory record 268 is reduced by the quantity specified in the new transaction. If there are several new blocks BL1Y, BL2Y...BLXY generated by the master node server, which are the same or overlapping room reservation events from different OTAs (or users), then the one of the several new blocks BL1Y, BL2Y...BLXY that is broadcast and accepted by the majority of the node servers is the latest/latest block. Only when the latest/latest block is confirmed, the room reservation request is considered complete, and the other new blocks will be discarded. Similarly, room cancellation requests and room checkout requests are processed through the same procedure.

When the room reservation event is a room cancellation request or a room checkout request, the programmatic standard verifies whether the current quantity balance of the specific hotel room item is lower than the predetermined minimum threshold after executing the room cancellation request or the room checkout request. After the new block is added to the blockchain, the current quantity balance of the specific hotel room item in the room inventory record 268 is increased by the quantity specified in the new transaction. In a preferred embodiment, the predetermined minimum threshold is zero. Since all successful transactions are recorded on the blockchain with a unique timestamp and new blocks are appended to the blockchain only when the transactions of the new blocks are successful, the current quantity balance recorded on the blockchain is reliable and dependable. The blockchain-based room inventory management system 200 of the present invention will not have overbooking problems.

In a preferred embodiment, the management method of the blockchain-based room inventory management system 200 also includes an audit procedure, which is based on reading the header of each block in the blockchain to locate the immediate previous block of each block; and confirming the timestamp of each block in the blockchain to identify the successful transaction of executing each block, thereby ensuring the integrity of the blockchain by verifying the timestamps listed in chronological order in all blocks BLY.

Based on the predetermined selection rules, a master node server is selected from a specific node server group among the multiple node servers of the hotel room inventory management system 200, and the master node server is the only node server among all the node servers NS1-NSX of the room inventory management system 200, which can package all records and contents to create new blocks BL1Y, BL2Y...BLXY. The predetermined selection rules include selecting the master node server based on one or more of the following rules: sequence, random order, election, consensus involving polling multiple node servers, comparison of the current workload of the system, available storage size, and/or the transmission bandwidth of the existing master node server relative to the new candidate node server.

Dynamic pricing

As shown in step S5 of FIG. 9 , when a block with a room reservation event is attached to the blockchain, the current amount balance is calculated by the basic smart contract based on the successful transaction and reaches a predetermined floating threshold (which may be a lower or higher value than the threshold), and the predetermined floating threshold may be the ratio of the number of unreserved rooms in the room inventory to the number of reserved rooms, the current date is close to the scheduled date, a specific period, or a specific holiday. The basic smart contract triggers the floating smart contract. The floating smart contract may be integrated as part of the basic smart contract, or it may be modularized into another smart contract stored in a different block in the blockchain. The original room price written in the basic smart contract is multiplied by a predetermined floating parameter, including a price discount parameter or a price increase parameter, which can be pre-written in the floating smart contract (for example, when the room inventory record 268 has a room inventory/stock of one-fifth of the current quantity balance in a certain period, the floating smart contract is triggered by the basic smart contract, and then the price of these remaining rooms is multiplied by a discount parameter, such as a 50% discount, to stimulate sales). The transaction agent server 260 can obtain and display the adjusted price from a new block of the blockchain through the basic smart contract or the floating smart contract when the transaction with the room reservation event causes the current quantity balance to change to trigger the floating smart contract. The scheduled float parameter can be written to the float smart contract or written to another block of the blockchain. The float smart contract can search/track the new scheduled float amount written to the corresponding block of the blockchain.

After executing several successful transactions with room booking events, such as room cancellation requests or room settlement requests, the base smart contract calculates the actual increased amount balance when processing new transactions to reach the amount far away from the predetermined floating threshold, and the base smart contract stops triggering the floating smart contract and uses the original room price, which can be initially written to the base smart contract. When a new block representing a new transaction of a room booking event is appended to the blockchain, the transaction proxy server 260 obtains the updated room price from the new block through the base smart contract (and the master node server).

In step S6, a new transaction can be submitted as a new block attached to the blockchain to update the scheduled floating threshold and/or the scheduled floating parameter through the basic smart contract. The new transaction represents the new scheduled floating rule and/or the new scheduled floating parameter to be updated. When the content of the new scheduled floating rule and/or the new scheduled floating parameter is confirmed, the basic smart contract accepts the new transaction. The master node server encapsulates the new transaction as a new block attached to the blockchain. When the basic smart contract calculates the current quantity balance and obtains the remaining room quantity, the basic smart contract checks the new scheduled floating threshold to see if the current quantity balance is within the new scheduled floating threshold range. In step S7, when the programmed criteria are configured to determine the new transaction submitted based on the current quantity balance of a specific hotel room object, the base/floating smart contract checks whether the predetermined floating parameter/threshold is newly updated. In a preferred embodiment, when the floating smart contract is triggered to ensure that the room price based on dynamic pricing is new and correct, the floating smart contract checks whether the predetermined floating parameter is new (searching the corresponding block through the Merkle tree). In step S8, the floating smart contract (or, through the base smart contract) can respond to inquiries about market prices, regardless of whether the market price is adjusted for a specific hotel room object. If the market price is adjusted (step S8.1), the floating smart contract can search for data representing the adjusted market price (using the Merkle tree algorithm) from the new block (or corresponding block) of the blockchain and send it to the sender of the query. When the market price is not adjusted, the basic smart contract can search for data from the basic smart contract itself and send it to the sender of the query (step S8.2). The dynamic land price of the smart contract of the present invention is recorded on the blockchain and is publicly readable, which is fair to both customers and travel agents. Based on the characteristics of the blockchain, the market price is automatically adjusted and is not secretly manipulated by anyone, but can truly reflect the price based on the market mechanism.

In another preferred embodiment, the room inventory management system 200 based on blockchain of the present invention includes multiple node servers, basic smart contracts and master node servers. Each node server in the multiple node servers is configured to maintain a blockchain that stores all successful transactions for a specific hotel room object. The blockchain includes a number of blocks BLY that are individually linked in chronological order, each block cryptographically references its immediate preceding block, so that the data in any block cannot be changed without changing all subsequent blocks BLY, and each block stores successful transactions for the specific hotel room object. The basic smart contract is stored in the blockchain. The basic smart contract includes a programmatic standard, which is configured to determine whether the submitted transaction represents a conflict among all existing successful transactions for the specific hotel room object currently stored in the blockchain based on the current quantity balance of the specific hotel room object. The master node server is configured to: receive a room reservation event from a computer network communication coupled to the hotel room inventory management system; submit a new transaction representing the room reservation event to the basic smart contract stored in the blockchain to determine whether the room reservation event can be successful; when it is determined based on the basic smart contract that the new transaction representing the room reservation event can be successful, create a new block to be attached to the blockchain, and the new block stores data representing that the new transaction is successful. The creation of the new block causes the new block to be added to the blockchain in each of the multiple node servers in the hotel room inventory management system 200. When the room reservation event causes the current quantity balance to meet the predetermined floating threshold, the basic smart contract can trigger the floating smart contract, which automatically adjusts the market price of the specific hotel room object according to the predetermined floating parameters. The predetermined floating threshold includes the current quantity balance of the specific hotel room object calculated by the smart contract, the current date close to a specific date, or a specific time period: and the adjusted market price of the specific hotel room object is communicated to the agent or manager of the specific hotel object through a computer network.

In another preferred embodiment, the non-transitory computer-readable medium of the present invention includes a plurality of instructions, which when executed by one or more processors of the computerized hotel room inventory management system 200 causes the system to: maintain a blockchain in each of a plurality of nodes in the hotel room inventory system 200, the blockchain storing all successful transactions for a particular hotel room item. The blockchain includes a plurality of blocks BLY individually linked in a chronological order, each block cryptographically references its immediately preceding block, so that the data in any block cannot be changed without changing all subsequent blocks BLY, and each block stores successful transactions for the particular hotel room item. When receiving a room reservation event from a computer network communicatively coupled to the hotel room inventory management system 200, a master node among the plurality of nodes submits a new transaction representing the room reservation event to a basic smart contract stored in the blockchain to determine whether the room reservation event can be successful. The basic smart contract includes a programmed standard that is configured to determine whether the submitted transaction represents a conflict among all existing successful transactions for the specific hotel room object currently stored in the blockchain based on the current quantity balance of the specific hotel room object. When the new transaction representing the room reservation event is determined to be successful based on the basic smart contract, a new block to be attached to the blockchain is created by the master node, wherein the new block stores data representing the new transaction as successful. The creation of the new block causes the new block to be added to the blockchain in each of the multiple nodes in the hotel room inventory management system 200. When the room reservation event causes the current quantity balance to meet the predetermined floating threshold, the basic smart contract can trigger the floating smart contract to automatically adjust the market price of the specific hotel room object according to the predetermined floating parameter, and the predetermined floating threshold includes the current quantity balance or the predetermined time period.

The above is only the preferred embodiment of the present invention. All equivalent changes and modifications made according to the scope of the patent application of the present invention shall fall within the scope of the present invention.

S5, S6, S7, S8, S8.1, S8.2: Steps

Claims (25)

A method for a hotel room inventory management system based on a blockchain, comprising: maintaining a blockchain in each of a plurality of nodes in the hotel room inventory management system, the blockchain storing all successful transactions for a specific hotel room object, wherein the blockchain comprises a plurality of blocks individually linked in a chronological order, each block cryptographically references its immediately preceding block so that the data in any block cannot be changed without changing all subsequent blocks, each block storing successful transactions for the specific hotel room object; When a room reservation event is received by the hotel room inventory management system through a computer network communication coupling, a master node among the plurality of nodes submits a new transaction representing the room reservation event to a first smart contract stored in the blockchain to determine whether the room reservation event can be successful, wherein the first smart contract includes a programmed standard configured to determine whether the submitted transaction represents a conflict among all existing successful transactions for the specific hotel room object currently stored in the blockchain based on the current quantity balance of the specific hotel room object; and When the first smart contract determines that the new transaction representing the room reservation event can be successful, the master node creates a new block to be attached to the blockchain, wherein the new block stores data representing the successful new transaction, wherein the creation of the new block causes the new block to be added to the blockchain in each of the multiple nodes in the hotel room inventory management system; when the first smart contract determines that the new transaction representing the room reservation event can be successful and the new transaction of the room reservation event causes the current quantity balance of the specific hotel room object to meet the predetermined floating threshold, the first smart contract triggers the second smart contract to trigger ... A smart contract, the second smart contract searches for a corresponding block to check whether the predetermined floating parameter or the predetermined floating threshold is newly updated, and multiplies the original price of the remaining rooms of the specific hotel room object by the predetermined floating parameter to automatically adjust the market price of the specific hotel room object; and Wherein, the predetermined floating parameter or the predetermined floating threshold is updated by submitting the new transaction to the first smart contract, wherein the new transaction representing the updated floating threshold or the updated floating parameter is confirmed by the first smart contract and packaged into the new block attached to the blockchain. The method of claim 1, wherein the data stored in the new block indicates, in addition to the new transaction, all previously successful transactions for the particular hotel room object. The method as claimed in claim 1, wherein the new block further includes: another successful transaction regarding a different hotel room object, the successful transaction regarding the different hotel room object and the new transaction regarding the hotel room object occurring substantially simultaneously. The method as claimed in claim 1, wherein the new block further comprises: all successful transactions related to different hotel room items occur in the hotel room inventory management system at approximately the same time as the new transaction related to the hotel room item. The method of claim 1, wherein the room reservation event is a booking event, and wherein the programmed criteria include verifying whether the current quantity balance of the specific hotel room object becomes higher than a predetermined maximum threshold after executing the booking event; and wherein, after the new block is added to the blockchain, the current quantity balance of the specific hotel room object is reduced by the amount specified in the new transaction. The method of claim 1, wherein the room reservation event is a cancellation event or a settlement event, and wherein the programmed criteria include verifying whether the current quantity balance of the specific hotel room object becomes lower than a predetermined minimum threshold after executing the cancellation event or the settlement event; wherein the current quantity balance of the specific hotel room object is increased after the new block is added to the blockchain; and wherein the predetermined minimum threshold is zero. The method of claim 1, wherein the first smart contract is configured to determine that the conflict is based on: the hotel location of the particular hotel room object; the room type of the particular hotel room object; and/or the time range of the room reservation event with respect to the particular hotel room object. The method as described in claim 1, wherein creating the new block includes: generating a unique hash value for the new block; generating a unique timestamp for the new block; and generating a unique block header for the new block based on the unique hash value and the unique timestamp, wherein the unique timestamp is generated based on the publishing time or receiving time of the room reservation event. The method of claim 1, wherein the new block is created only if the new transaction representing the room reservation event can succeed. The method of claim 1, wherein the new block includes: a unique block header; data representing the new transaction; and cryptographically generated data representing the contents of the immediately preceding block of the new block. The method as described in claim 1 further includes performing an audit procedure based on the following steps: reading the block header of each block in the blockchain to locate the immediately preceding block of each block; and confirming the timestamp of each block in the blockchain to identify the successful transaction that initiated each block, thereby ensuring the integrity of the blockchain by verifying that the timestamps in all the blocks are listed in chronological order. The method as described in claim 1 further includes: selecting the master node from a specific node group of the plurality of nodes in the hotel room inventory management system based on a predetermined selection rule, wherein the master node in the hotel room inventory management system is the only node that can create a new block. The method of claim 12, wherein the predetermined selection rule includes one or more of sequential, random, selection, and/or consensus involving polling the plurality of nodes to select the master node. The method as described in claim 12, wherein the predetermined selection rule includes selecting the master node based on the current workload of the system, the size of available storage, and/or the comparison of the transmission bandwidth of the existing master node and the new candidate node. The method as described in claim 1, wherein the specific hotel room object is a selected room type in a selected hotel on a selected date, and wherein the room reservation event is a reservation request, a room checkout request, or a room cancellation request. The method as claimed in claim 1, further comprising: receiving the room reservation event from a hotel, a reservation engine, an online travel agency (OTA), a global distribution system, and/or a metasearch engine through the computer network, wherein the communication with the hotel room inventory management system through the computer network at least partially complies with a remote procedure call (RPC) protocol. The method as described in claim 1, wherein the predetermined floating threshold is the current quantity balance of the specific hotel room item calculated by the second smart contract, the current date close to a specific date, or a specific time period. The method as described in claim 1, wherein the first smart contract is a basic smart contract for managing the booking event and submitting the new transaction to the blockchain, and the second smart contract is a floating smart contract for automatically managing the market price of the specific hotel room item, and the floating smart contract can be integrated as a part of the basic smart contract or modularized into another smart contract stored in a different block in the blockchain. The method of claim 1, wherein the second smart contract is configured to, in response to a query about the market price received through the computer network, determine whether to adjust the market price for the particular hotel room item; if the market price is adjusted, search for data representing the adjusted market price from a new block of the blockchain to the sender of the query; if the market price is not adjusted, obtain data from the second smart contract to the sender of the query. The method of claim 1, wherein the first smart contract is configured to, in response to a query received via the computer network regarding the current amount balance of the particular hotel room item, transmit data representing the current amount balance from the new block of the blockchain to the sender of the query. A hotel room inventory management system based on blockchain, comprising: a plurality of nodes, wherein each of the plurality of nodes is configured to maintain a blockchain, the blockchain storing all successful transactions for a particular hotel room object, and wherein the blockchain comprises a plurality of blocks individually linked in chronological order, each block cryptographically references its immediately preceding block so that the data in any block cannot be changed without changing all subsequent blocks, each block storing successful transactions for the particular hotel room object; A first smart contract, wherein the first smart contract includes a programmed standard configured to determine whether a submitted transaction represents a conflict among all existing successful transactions for the specific hotel room object currently stored in the blockchain based on a current quantity balance of the specific hotel room object; and a master node configured to: receive a room reservation event from a computer network communication coupled to the hotel room inventory management system; submit a new transaction representing the room reservation event to the first smart contract stored in the blockchain to determine whether the room reservation event can be successful; and determine whether the room reservation event can be successful based on the first smart contract; When a smart contract determines that the new transaction representing the room reservation event can be successful, a new block to be attached to the blockchain is created, wherein the new block stores data representing the successful new transaction, and wherein the creation of the new block causes the new block to be added to the blockchain in each of the multiple nodes in the hotel room inventory management system; wherein, when the first smart contract determines that the new transaction representing the room reservation event can be successful and the new transaction of the room reservation event causes the current quantity balance to meet a predetermined floating threshold, the first smart contract triggers the second smart contract, the The second smart contract searches for a corresponding block to check whether the predetermined floating parameter or the predetermined floating threshold is recently updated, and multiplies the original price of the remaining rooms by the predetermined floating parameter to automatically adjust the market price of the specific hotel room item, wherein the predetermined floating threshold includes the current quantity balance or the predetermined time period; and wherein the predetermined floating parameter or the predetermined floating threshold is updated by submitting the new transaction to the smart contract, and the new transaction representing the updated floating threshold or the updated floating parameter is confirmed by the first smart contract and packaged into the new block attached to the blockchain. The system as claimed in claim 21, wherein the first smart contract is a basic smart contract for managing the booking event and submitting the new transaction to the blockchain, and the second smart contract is a floating smart contract for automatically managing the market price of the specific hotel room item, and the floating smart contract can be integrated as a part of the basic smart contract or modularized into another smart contract stored in a different block in the blockchain. The system of claim 21, wherein the second smart contract is configured to, in response to a query about the market price received through the computer network, determine whether to adjust the market price for the particular hotel room item; if the market price is adjusted, search for data representing the adjusted market price from a new block of the blockchain to the sender of the query; if the market price is not adjusted, obtain data from the second smart contract to the sender of the query. The system of claim 21, wherein the first smart contract is configured to, in response to a query received via the computer network regarding the current quantity balance of the particular hotel room item, transmit data representing the current quantity balance from the new block of the blockchain to the sender of the query. A non-transitory computer-readable medium for a blockchain-based hotel room inventory management system, comprising a plurality of instructions that, when executed by one or more processors of the computerized hotel room inventory management system, cause the system to: maintain, in each of a plurality of nodes in the hotel room inventory management system, a blockchain storing all successful transactions for a particular hotel room item, wherein the blockchain comprises a plurality of blocks individually linked in chronological order, each block cryptographically referencing its immediately preceding block such that all subsequent blocks are encrypted without changing any of the subsequent blocks. , the data in any block cannot be changed, each block stores successful transactions related to the specific hotel room object; when receiving a room reservation event from the computer network communication coupled to the hotel room inventory management system, the master node among the multiple nodes submits a new transaction representing the room reservation event to the first smart contract stored in the blockchain to determine whether the room reservation event can be successful, wherein the first smart contract includes a programmed standard, which is configured to determine the submitted transaction based on the current quantity balance of the specific hotel room object stored in the blockchain at the time. whether there is a conflict in an existing successful transaction; and when it is determined based on the first smart contract that the new transaction representing the room reservation event can be successful, the master node creates a new block to be attached to the blockchain, wherein the new block stores data representing the successful new transaction, wherein the creation of the new block causes the new block to be added to the blockchain in each of the multiple nodes in the hotel room inventory management system; wherein, when the first smart contract determines that the new transaction representing the room reservation event can be successful and the new transaction of the room reservation event causes the current quantity balance to meet the predetermined floating threshold, the first smart contract The second smart contract triggers a second smart contract, which searches for a corresponding block to check whether the predetermined floating parameter or the predetermined floating threshold is newly updated and multiplies the original price of the remaining room by the predetermined floating parameter to automatically adjust the market price of the specific hotel room item, wherein the predetermined floating threshold includes the current quantity balance or the predetermined time period; and wherein the predetermined floating parameter or the predetermined floating threshold is updated by submitting the new transaction to the second smart contract, and the new transaction representing the updated floating threshold or the updated floating parameter is confirmed by the first smart contract and packaged into the new block attached to the blockchain.