Method for performing bim privacy protection using an interstellar file system blockchain integration network

Abstract

A method for performing building information modeling (BIM) design collaboration via a confidentiality framework by a server using an Interplanetary-File-System (IPFS) blockchain integrated network. The method includes: separating sensitive and non-sensitive BIM parts of a BIM object; uploading a target BIM component into an IPFS network to receive a target content identifier (CID) of the target BIM component from the IPFS network; if the target BIM component has one or more of the sensitive parts, encrypting the target CID to obtain a target encrypted CID (ECID), and adding the target ECID as a target transaction into a target blockchain ledger via a target smart contract; a user authorized to access data decrypting the ECID by an asymmetric encryption technique to obtain a CID to access the target transaction to download the target BIM component from the IPFS network; and performing a design coordination operation on the target BIM component to distribute a revised target BIM component to a recipient terminal.

Description

Technical Field

[0001] The present invention generally relates to techniques for performing Building Information Modeling (BIM) design collaboration via a Confidentiality Framework (CMF) using an InterPlanetary File System (IPFS) blockchain-integrated network. Background Art

[0002] Design collaboration in the architecture, engineering, and construction (AEC) industry is a complex, iterative process involving designers from multiple disciplines and continuous data exchange. Building Information Modeling (BIM) technology represents a paradigm shift in data management. Powered by shared BIM models, designers can electronically share design attributes and address design issues in real time, facilitating integrated decision-making, streamlining collaboration, and improving product quality. However, existing BIM-based design platforms are primarily based on centralized system architectures. Consequently, these platforms present cybersecurity risks, particularly vulnerabilities to data manipulation. Because the central database serves as the sole source of BIM data, malicious insiders seeking to absolve themselves of liability could inadvertently tamper with design records and documents. Consequently, project teams could lose the traceability and authenticity of BIM data. Third-party vendors or project members with full access / control over the platform also present a high risk of single points of failure or access denial, leading to project delays, data loss, and even additional costs.

[0003] Blockchain technology is an emerging and promising solution to prevent data manipulation problems caused by centralization. Blockchain is a distributed database technology that ensures the traceability, authenticity, and immutability of data by integrating peer-to-peer networks, consensus mechanisms, and hash functions. Without an intermediary or central authority, the data in the blockchain is collectively maintained, and each peer holds a complete copy of the data locally (i.e., the blockchain ledger). A recent wave of research has proposed the feasibility of integrating BIM with blockchain. For example, Xue et al. [F.Xue, W.Lu, A semantic differential transaction approach to minimizing information redundancy for BIM and blockchain integration, Automation in Construction, 118, (2020), pp. 103-270] collected semantic changes in BIM models and stored them in a blockchain to track design changes. Liu et al. [Z. Liu, L. Jiang, M. Osmani, P. J. Edemian, Building information management (BIM) and blockchain (BC) for sustainable building design information management framework, Electronics, 8, (7), (2019), p. 724] proposed a sustainable building design framework using blockchain and BIM; the results showed that blockchain formed a trustworthy environment and increased the confidence of designers to join the collaboration. Combining blockchain with smart contracts can automatically distribute design data, thereby reducing the time required to issue permits during the design process [A. J. McNamara, S. M. E. Sepasgozar, Intelligent contract adoption in the construction industry: Concept development, Automation in Construction, 122, (2021), pp. 103452].The Winfield Rock report [M. Winfield, The Winfield Rock Report: Overcoming the Legal and Contractual Barriers of BIM, UK BIM Alliance, 2018, last accessed, pp. 1–60] concludes that BIM collaboration would benefit from decentralized mechanisms such as blockchain, which securely record data flows and track accountability between peers.

[0004] However, due to the lack of access control methods, integrating BIM with blockchain faces the challenge of leaking sensitive data. Blockchain is a transparent network, and each peer (or project member) has unlimited local access to all design data in the blockchain ledger, so there is a high risk of unauthorized access to sensitive BIM data. According to the latest ISO 19650-5:2020 standard, confidential or sensitive BIM data refers to data whose loss or modification or unauthorized access will adversely affect personal privacy, damage intellectual property and organizational trade secrets, cause commercial or economic damage, and even endanger national security. BIM models, especially some critical infrastructure (such as banks, prisons and military assets) or commercial buildings, often contain a large amount of confidential information (as shown in the Appendix Table), including but not limited to (1) sensitive area layout in the architectural model, (2) proprietary steel reinforcement ratio of the core tube structure in the structural model; (3) design details of the power system in the MEP (mechanical, electrical and plumbing) model. During the design process, such sensitive information must be kept confidential and not disclosed to all participants. Developing strategies to control unauthorized access to confidential BIM data has been highlighted as a top priority for design collaboration, according to ISO 19650-5:2020.

[0005] However, limited research has been conducted on protecting BIM confidentiality in transparent blockchains, resulting in a high risk of leaking sensitive data as long as peers have uncontrolled access to their local blockchain ledgers. Boyes et al. [H. Boyes, Resilience and Cyber ​​Security of Technology in the Built Environment, Institution of Engineering and Technology, 2013, last accessed July 21, 2021] note that a lack of access control in blockchains could undermine intellectual property and even jeopardize the security of sensitive infrastructure such as banks, courts, and prisons. Traditional access control solutions for centralized databases (e.g., lock-based protocols or multi-level relational models) cannot be directly applied to blockchains due to their chained data model and decentralized database architecture. These methods, which are used for relational or ER models (in centralized databases), are not applicable to chained data models (in blockchains). Furthermore, these methods are ineffective at synchronously managing access to distributed (or multiple) databases. Zheng et al. [R. Zheng, J. Jiang, X. Hao, W. Ren, F. Xiong, Y. Ren, bcBIM: A bockchain-based big data model for BIM modification audit and provenance in mobile cloud, Mathematical Problems in Engineering (2019), pp. 5349-538] designed a "bcBIM" system in which project members share hashes of BIM models in a blockchain. Although this approach prevents data leakage, it only provides data proof (i.e., hash values), and members cannot obtain any source design data (e.g., BIM models) from or through the blockchain.Li et al. [X. Li, L. Wu, R. Zhao, W. Lu, F. Xue, Two-layer adaptive blockchain-based supervision model for off-site modular housing production, Computers in Industry, 128, (2021), pp. 103437] attempted to protect sensitive project data by placing it in a “sidechain” (i.e., another blockchain channel). However, such an approach increases the difficulty of blockchain development and the complexity of data management, as project members may join multiple blockchain networks.

[0006] That is, technical personnel in the field need to find solutions to the following problems: (1) how to protect access to sensitive BIM data when collaborating with blockchain systems and IPFS network systems; and (2) how to conduct design coordination in an access-controlled IPFS blockchain integrated network. Summary of the Invention

[0007] Therefore, the present disclosure aims to provide a confidentiality framework (CMF), i.e., a blockchain-based and access-controlled environment for secure BIM design collaboration to effectively enforce privacy protection for BIM. In brief, CMF is built on two decentralized networks, where the InterPlanetary File System (IPFS) network is responsible for storing large design files (e.g., BIM models) and the blockchain network is used to save and exchange design information (e.g., design changes). In CMF, two new modules are developed: (1) an access control module and (2) a design coordination module. The access control module prevents unauthorized access to sensitive BIM data in a transparent blockchain.

[0008] According to one aspect of the present invention, a computer-implemented method for performing building information modeling (BIM) design collaboration via a confidentiality framework (CMF) using an InterPlanetary File System (IPFS) blockchain integrated network through a server is provided. The method includes: an access control module executed by a processor of the server separating one or more sensitive and non-sensitive BIM parts of a BIM object; uploading a target BIM component to the IPFS network by a provider terminal; receiving, by an access model, a target content identifier (CID) of the target BIM component from the IPFS network; determining whether the target BIM component has one or more of the sensitive parts, wherein if the target BIM component has one or more of the sensitive parts, encrypting the target CID by the access control module to obtain a target encrypted CID (ECID), and adding the target ECID as a target transaction to a target blockchain ledger via a target smart contract; otherwise, if the target BIM component does not have any of the sensitive parts, adding the target CID as a target transaction to the target blockchain ledger by the access control module via the target smart contract. In addition, the method further includes: accessing the target transaction by the revising party terminal to download the target BIM component from the IPFS network; and performing a design coordination operation on the target BIM component by the revising party terminal to distribute the revised target BIM component to the receiving party terminal via the access control module, the target blockchain ledger and the target smart contract.

[0009] According to another aspect of the present invention, a server connected to an IPFS blockchain integrated network for executing the aforementioned method is provided, and the server includes at least one processor configured to execute machine instructions to implement the method described above.

[0010] According to another aspect of the present invention, a system for performing BIM design collaboration via CMF using an IPFS blockchain integrated network is provided, and the system includes one or more processors configured to execute machine instructions to implement the method described above.

[0011] Since this paper is one of the first works on BIM-based design collaboration in an access-controlled blockchain network, the design coordination module proposes a corresponding new design strategy. The provided method can achieve the following goals:

[0012] (1) Provide access control modules / models in CMF. In CMF, a decomposition method is proposed to divide the BIM model into sensitive and non-sensitive components (data separation). This method helps to define which part of the BIM data should be subject to access control. Subsequently, an encrypted blockchain integration method is designed to implement access control by encrypting sensitive BIM data within the blockchain. All project members will save these encrypted design records in their ledgers, but only authorized members have the right to decrypt this data. In addition, blockchain smart contracts are developed to propagate encryption keys and share design information.

[0013] (2) The Design Coordination Module provides a new strategy for BIM design coordination in CMF. Unlike traditional design platforms where members collaborate to complete BIM models, CMF allows members to process partial BIM models (i.e., BIM components) in an access-controlled blockchain network. Therefore, a new component-based design workflow is proposed for design coordination. In addition, the Design Coordination Module provides the original BIM Merkle Tree (BMT) data model and BMT algorithm for BIM data version management in CMF. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Embodiments of the present invention are described in more detail below with reference to the accompanying drawings, in which:

[0015] Figure 1 Depicting a block diagram illustrating a system for performing BIM design collaboration via CMF using an IPFS blockchain integrated network according to one embodiment of the present invention;

[0016] Figure 2 a flow chart depicting a method implemented by the provided server;

[0017] Figure 3A and Figure 3B A schematic diagram depicting the data flow managed by the provided methods;

[0018] Figure 4A A diagram depicting the regular IPFS network and the IPFS blockchain integrated network;

[0019] Figure 4B A flowchart depicting the operations performed on the provided IPFS blockchain integrated network;

[0020] Figure 4C A diagram depicting the operations performed in the IPFS blockchain integrated network;

[0021] Figure 5A Schematic diagram depicting the proposed confidentiality framework (CMF) for blockchain-based BIM design collaboration;

[0022] Figure 5BA diagram depicting the architecture of CMF;

[0023] Figure 5C Describe the proposed access control model;

[0024] Figure 6 A flowchart depicting the CMF access control method for managing sensitive data / portions to be communicated within the provided IPFS blockchain integrated network;

[0025] Figure 7 A flowchart depicting a CMF access control method for managing non-sensitive data / portions transmitted within the provided IPFS blockchain integrated network;

[0026] Figure 8A a diagram depicting an example of a decomposed architecture model;

[0027] Figure 8B A schematic diagram depicting the BIM model / object decomposition process;

[0028] Figure 9A A diagram depicting asymmetric encryption;

[0029] Figure 9B A diagram depicting the smart contract algorithm provided in CMF;

[0030] Figure 9C A schematic diagram depicting a provided asymmetric encryption method used by a provided access control module for a provided IPFS blockchain integrated network;

[0031] Figure 10A A schematic diagram depicting the coordination workflow of sensitive BIM components;

[0032] Figure 10B A schematic diagram depicting the rules for sharing / distributing revised BIM components and performing design coordination;

[0033] Figure 11A A schematic diagram depicting the BMT initialization algorithm;

[0034] Figure 11B A schematic diagram depicting the BMT update algorithm;

[0035] Figure 11C Describe the flowchart of the BMT update algorithm;

[0036] Figure 12 Schematic diagram depicting the CMF diagramming method;

[0037] Figure 13 A diagram depicting BIM components and access requirements in an illustrative example;

[0038] Figure 14Schematic diagrams depicting illustrated scenarios and indicators;

[0039] Figure 15 A process diagram depicting Scenario 1; and

[0040] Figure 16 Describe the process diagram for Scenario 2. DETAILED DESCRIPTION

[0041] In the following description, a method and apparatus for performing Building Information Modeling (BIM) design collaboration using an Interplanetary File System (IPFS) blockchain integrated network and the like via a Confidentiality-Minded Framework (CMF) is described as a preferred example. Those skilled in the art will appreciate that modifications, including additions and / or substitutions, may be made without departing from the scope and spirit of the present invention. Certain details may be omitted to avoid obscuring the present invention; however, this disclosure is prepared to enable those skilled in the art to practice the teachings herein without undue experimentation.

[0042] refer to Figure 1 The following description is provided. According to various embodiments of the present invention, a design collaboration system 1 is provided, which includes a server 100 and one or more terminal devices 200(1)-200(N). Each of the terminal devices can be, for example, a smartphone, a PC, a computer device, a mobile device, or an electronic device. Each terminal device has one or more processors configured to manage the overall operation of the terminal device.

[0043] The server 100 includes a processor 110, a non-transitory memory circuit 120, and a data communication circuit 130. The non-transitory memory circuit 120 is configured to store machine instructions (or programs) 121 and host a database 122. The database 122 can be used to store parameters / models (e.g., a BIM Merkle Tree model) and corresponding smart contracts for running the CMF, as well as received data (design models, original design data, and partial design models).

[0044] The data communication circuit 130 is configured to establish a network connection NC to the terminal device 200, the IPFS network, the CMF smart contract, the blockchain ledger, and the Internet (not shown). In addition, the terminal device also establishes a network connection to the IPFS network, the CMF smart contract, the blockchain ledger, and the Internet (not shown). The network connection can be a wired or wireless data communication connection and is configured to transmit data. The transmitted data includes: encryption keys, private keys, public keys, complete data models (e.g., overall BIM models), partial data models (e.g., BIM components), content identifications (CIDs), transactions, requests, responses, and instructions.

[0045] Processor 110 executes machine instructions 121 to implement a method provided according to an embodiment of the present invention. Machine instructions 121, or program 121, include an access control module (program module) and a design coordination module (program module). The access control module includes a data decomposition module, an encrypted blockchain integration module, and a CMF smart contract. The design coordination module manages component-based design workflows using the BIM Merkle Tree (BMT) data model and corresponding BMT algorithm. Details of the provided method and related models are described below.

[0046] refer to Figure 2 In step S210, the access control module executed by the processor 110 separates one or more sensitive and non-sensitive BIM parts of the BIM object (such as Figure 8A and Figure 8B Next, in step S220, the provider terminal uploads the target BIM component to the IPFS network. The provider terminal is, for example, one of the terminal devices 200 that provides the BIM component or CID / ECID or encryption key.

[0047] Next, at step S230, the access model receives the target content identifier (CID) of the target BIM component from the IPFS network. Next, at step S240, the access control module determines whether the target BIM component has one or more of the sensitive parts. If the target BIM component has one or more of the sensitive parts, the process proceeds to step S250; otherwise, if the target BIM component does not have any sensitive parts, the process proceeds to step S260.

[0048] In step S250, the access control module encrypts the target CID to obtain a target encrypted CID (ECID), and adds the target ECID as a target transaction to the target blockchain ledger via the target smart contract. In step S260, the access control module adds the target CID as a target transaction to the target blockchain ledger via the target smart contract.

[0049] Next, in step S270, the revising terminal accesses the target transaction to download the target BIM component from the IPFS network. The revising terminal, for example, one of the terminal devices 200 or the server 100, revises the received one or more updated BIM components, reconstructs the complete BIM model based on the received updated BIM components and the original BIM components, and distributes the BIM components to one or more recipient terminals.

[0050] Next, at step S280, the revising terminal performs a design coordination operation on the target BIM component to distribute the revised target BIM component to the receiving terminal via the access control module, the target blockchain ledger, and the target smart contract. The design coordination operation is performed by the processor executing the design coordination module.

[0051] refer to Figure 3A For example, it is assumed that the provider terminal 200 (1) is about to send a BIM component to the revision party terminal 100 for review. In this case, the provider terminal 200 (1) uploads the BIM component BC1 (assuming that BC1 has sensitive parts / data in this example) to the IPFS network (as shown by arrow A21), where BC1 is stored in a storage device (e.g., HDD) of the IPFS network. In addition, it is assumed that the revision party terminal 100 uploads its public key (i.e., Key1) to the IPFS network. pub ) is added to the blockchain ledger BL, where the revising party terminal 100 has a key corresponding to Key1 pub The private key (ie, Key1 pri ); and the receiving terminal 200 (2) sends its public key (ie, Key2 pub ) is added to the blockchain ledger BL, where the recipient terminal 200(2) has a key corresponding to Key2 pub The private key (i.e., Key2 pri ).

[0052] The processor for managing the IPFS network generates a unique content identifier CID1 based on the data / file of BC1 and sends CID1 to the access control module executed by the processor 110 of the server 100 (as shown by arrow A22). In response to determining that CID1 corresponds to BC1 with a sensitive portion, the access control module uses an encryption key (e.g., Key1 of the revising party terminal) to identify the content identifier CID1. pub ) encrypts CID1 into an encrypted CID (ie, ECID1). The access control module adds the transaction corresponding to ECID1 to the blockchain ledger BL via the CMF smart contract (as shown by arrow A23).

[0053] The reviser terminal 100 then accesses the ECID1 in the blockchain ledger BL (as indicated by arrow A24). In response to determining that the ECID1 corresponds to a BIM component with a sensitive portion, the reviser terminal 100 encrypts the CID1 via its own Key1 pri decrypts the ECID1 to CID1. The CID1 is then sent to the IPFS network (as indicated by arrow A25) to download the corresponding BC1 (as indicated by arrow A26).

[0054] After obtaining the BC1, the reviser terminal 100 revises the BC1 and updates the BC1 to BC2, and sends the BC2 to the design coordination module (as indicated by arrow A27). The design coordination can determine how to distribute the BC2 via the access control module (as indicated by arrow A28).

[0055] Referring to Figure 3B , assuming that the BC2 should be distributed to the recipient terminal 200(2) according to the design coordination module, the Key2 pub corresponding to the recipient terminal 200(2) is downloaded by the access control module.

[0056] The access control module uploads the BC2 to the IPFS network (as indicated by arrow A29), and the IPFS network generates a unique content identifier CID2 according to the BC2, and sends the CID2 to the access control module (as indicated by arrow A30).

[0057] In response to determining that the BC2 has a sensitive portion, the access control module encrypts the CID2 to ECID2 via the Key2 pub corresponding to the recipient terminal 200(2). The access control module then adds the ECID2 to the blockchain ledger BL via a smart contract (as indicated by arrow A31).

[0058] The recipient terminal 200(2) accesses the ECID2 in the blockchain ledger BL (as indicated by arrow A32). In response to determining that the ECID2 corresponds to a BIM component BC2 with a sensitive portion, the recipient terminal 200(2) decrypts the ECID2 to CID2 via its own Key2 pri . The CID2 is then sent to the IPFS network (as indicated by arrow A34) to download the corresponding BC2 (as indicated by arrow A34).

[0059] Blockchain itself is not suitable for storing large data (e.g., BIM models of hundreds of megabytes), so storing BIM data is a challenge for blockchain adoption. If the data size exceeds the block limit, problems such as high latency and network collapse will occur. Therefore, most existing research attempts to store BIM models in a central database while sharing design changes or other attributes in a blockchain ledger. However, this concept is still limited in conceptualization as BIM data formats such as “.rvt” are not acceptable in blockchain. Xue et al. proposed a semantic difference transaction (SDT) model to reduce data redundancy. The semantic difference between IFC files is extracted using SDT and then stored as a design record in the blockchain. In this way, the design record is protected by the blockchain, but the central administrator still has the BIM model (or design file).

[0060] Storing BIM models and changes in a secure and decentralized manner requires the adoption of other distributed database systems, similar to the Interplanetary File System (IPFS). IPFS is considered a proper technical complement to blockchain for storing large files. IPFS is a peer-to-peer network that uses content addressing to uniquely identify each file. Referring to Figure 4A , a conventional IPFS network shows that each peer in IPFS is a file receiver and provider. For example, when peer 1 uploads a file in IPFS, a unique hash content identifier (CID) is generated based on the file content (step 1). The CID is used as a proof of file integrity and as a file hyperlink. This file is currently stored in the local repository of peer 1 and can be downloaded by other peers using the file CID (step 2). Now, if other peers (e.g., peer 3) have the CID, the file can be accessed from any provider (step 3). In addition, the receiver can hash the file and compare the hash value with its CID (step 4). The same value can verify the integrity and authenticity of the data.

[0061] A conventional IPFS blockchain integrated network shows a general approach to integrating blockchain with IPFS. Project members can store BIM models in the IPFS network (step 1) and distribute the CID (a 256-bit long string) as a transaction in the blockchain (step 2). Some research summaries that combining blockchain with IPFS can: (1) improve network stability and prevent BIM data loss by providing multiple data providers, (2) ensure BIM data integrity, as blockchain provides immutable record storage and IPFS provides verifiable file proof (i.e., CID). However, since there is no access control in the blockchain ledger, all members can see the shared CID, and they can download the corresponding BIM model without restriction, so there will be a security problem of leaking sensitive design data / information.

[0062] Therefore, reference Figure 5A , provides a confidentiality framework (CMF) for blockchain-based BIM design collaboration. In CMF, multidisciplinary designers collaborate in a distributed network where blockchain is integrated with IPFS to store design records and large design files respectively. Two new modules are developed in CMF: (1) access control module and (2) design coordination module. The access control model (Module 1) is developed through three research and development elements: (i) developing a BIM model decomposition method to separate sensitive and non-sensitive BIM data; (ii) proposing an encrypted blockchain integration method to encrypt sensitive BIM data in the blockchain ledger, and (iii) developing CMF smart contracts to manage encryption keys and share design data. In addition, regarding design coordination in CMF, project members exchange partial BIM data (decomposed BIM components in Module 1) rather than complete BIM models. Component-based design procedures in access-controlled blockchains have not yet been formalized. Therefore, a design coordination module is provided to facilitate BIM design coordination in CMF. This module (i.e., the second new module) contains two elements: (i) a new design workflow for coordinating sensitive and non-sensitive BIM components, and (ii) a new BIM Merkle Tree (BMT) approach for BIM data version management.

[0063] In the embodiments, for example, reference Figure 4B and Figure 4C , the operation method in the provided IPFS blockchain network includes steps S410-S490.

[0064] In step S410, the provider terminal uploads the target BIM component to the IPFS network. Next, in step S420, the IPFS network generates a target CID based on the uploaded target BIM component's content. Next, in step S430, the access control module adds the generated target CID from the IPFS network to the target blockchain ledger as the target transaction corresponding to the uploaded BIM component.

[0065] Next, at step S440, the recipient terminal downloads the target CID from the target blockchain ledger. Next, at step S450, the recipient terminal determines whether the target CID is encrypted. If the target CID is encrypted, the process proceeds to step S460; otherwise, if the target CID is not encrypted, the process proceeds to step S470.

[0066] In step S460, the receiving terminal generates a valid target CID according to the target CID and the encryption key (eg, decrypts the target CID into a valid target CID via the private key).

[0067] In response to determining that the target CID is not encrypted, it is determined that the target CID is a valid target CID, and in step S470, the recipient terminal sends the valid target CID to the IPFS network.

[0068] Next, in step S480, the receiving terminal downloads the target BIM component from the IPFS network. Next, in step S490, the receiving terminal verifies the downloaded target BIM component by comparing the hash value of the target BIM component with the valid target CID.

[0069] refer to Figure 5B , provides the architecture of CMF. In the application layer, project members (1) perform design coordination (e.g., building BIM models, checking conflicts, managing versions) (2) use domain-specific tools locally (e.g., Revit and the developed BIM Merkle tree tool), and (3) follow the proposed design workflow. In the CMF smart contract layer, when a project member attempts to share a design transaction or issue a new encryption key, he calls a smart contract in the CMF smart contract layer. A smart contract is a trusted algorithm or computer program that can be automatically executed after the preset conditions are met. In the network layer, the network layer represents each member joining two distributed networks, namely blockchain and IPFS. The access control layer protects only authorized members from accessing sensitive or confidential BIM data in the blockchain ledger. The database layer shows four databases owned by each member (i.e., blockchain ledger, IPFS database, private key database, and BMT database). The blockchain stores design transactions (records), the IPFS database stores large design files, the private key is placed in the private key database, and the BIM version data is placed in the BMT database. A consortium blockchain platform called Hyperledger Fabric is used in CMF because it is suitable for collaboration in the construction industry, which only allows registered project members to join and requires minimal computing resources for "mining."

[0070] Figure 5C The proposed access control model is described, which helps in three aspects: (1) providing a BIM data separation method to define and extract sensitive BIM components (step 1); (2) revealing the mechanism of how asymmetric encryption is integrated with blockchain to achieve access control (steps 2 and 4), and (3) presenting the logic of how smart contracts interact with blockchain to distribute design information and manage encryption keys (step 3).

[0071] To handle BIM components with sensitive parts, refer to Figure 6At step S610, the access control module performs a BIM data separation operation to define and separate one or more sensitive BIM parts and one or more non-sensitive BIM parts from a BIM object (e.g., a complete BIM data model).

[0072] Next, at step S620, the provider terminal performs a BIM component registration to register the target sensitive BIM component to the access control module via the target smart contract when uploading the target sensitive BIM component to the IPFS network, where the target sensitive BIM component contains at least one defined sensitive BIM part. In other words, the provider terminal can tell the access control module whether the uploaded BIM component has any sensitive parts, and if it has one or more sensitive parts, which encryption key of the receiver terminal should be used to encrypt the target CID corresponding to the uploaded BIM component.

[0073] Next, at step S630, the IPFS network generates a target CID (content identifier) of the target sensitive BIM component.

[0074] Next, at step S640, the access control module performs an encryption operation on the target CID to generate a target ECID according to a target public key, where the target public key corresponds to the receiver terminal indicated by the BIM component registration. Then, at step S650, the access control module adds a target transaction corresponding to the target ECID to the target blockchain ledger via the target smart contract.

[0075] Next, at step S660, the receiver terminal obtains the target ECID from the target transaction of the target blockchain ledger. Next, the receiver terminal decrypts the target ECID via a target private key corresponding to the target public key to obtain the target CID (i.e., a valid target CID). Then, the receiver terminal downloads the target sensitive BIM component from the IPFS network through the decrypted target CID.

[0076] To handle a BIM component without any sensitive parts, refer to Figure 7 At step S710, the access control module performs a BIM data separation operation to define and separate one or more sensitive BIM parts and one or more non-sensitive BIM parts from a BIM object.

[0077] Next, at step S720, the provider terminal performs a BIM component registration to register the target non-sensitive BIM component to the access control module when uploading the target non-sensitive BIM component to the IPFS network, where the target non-sensitive BIM component does not contain any sensitive BIM parts defined by the BIM data separation.

[0078] Next, at step S730, the IPFS network generates a target CID (content identifier) ​​for the target non-sensitive BIM component. Next, at step S740, the access control module adds the target transaction corresponding to the target CID to the target blockchain ledger via the target smart contract. In other words, since the target CID does not correspond to a BIM component with any sensitive parts, the access control module can directly add the target transaction for the target CID without encrypting the target CID.

[0079] Next, in step S750, the receiving terminal obtains the target CID from the target transaction of the target blockchain ledger. Next, in step S760, the receiving terminal downloads the target non-sensitive BIM component from the IPFS network using the obtained target CID.

[0080] refer to Figure 8A , which shows that any shared BIM model containing sensitive information will be decomposed to separate sensitive data from non-sensitive data. The basic idea of ​​the decomposition process is to divide the root BIM model (i.e., the complete BIM model) into non-sensitive and sensitive components. Non-sensitive components are parts of the BIM model where all sensitive information (e.g., the layout of sensitive areas / sections) has been "deleted", i.e., without any sensitive information. Sensitive components are parts of the BIM model that contain sensitive information.

[0081] In addition, if Figure 8A As shown in Figure 1, a BIM model containing n sensitive parts (e.g., zones) is decomposed into m components. Component 1 is a non-sensitive BIM model and is accessible to all members. For example, the sensitive component of component 2 contains both non-sensitive parts and sensitive parts. Figure 8B , which shows an example showing that an architecture model with three sensitive area layouts is decomposed into three components. Component 1 is non-sensitive because all sensitive area layouts have been deleted. Component 2 retains the layouts of sensitive areas 1 and 2. Component 3 contains the layout of sensitive area 3.

[0082] The decomposition approach is the basis for access control in CMF because it filters out sensitive BIM data that needs to be protected. In addition, this decomposition approach is universal and can be applied to separate models in different domains. For example, structural engineers can share non-sensitive components by removing sensitive structures or related design details. In addition, this is an easy-to-handle approach, and designers only need to delete certain elements in the model to achieve data isolation. Currently, decomposition and sharing of graphic documents are limited to 3D BIM models (for example, built by Revit or AutoCAD), which are common models for most project practices. In addition, these models can be linked to open source standards for design issue management, such as the BIM Collaboration Format (BCF).

[0083] In CMF, BIM models and components are stored in the IPFS network and can only be accessed by project members who hold the corresponding CID. In other words, protecting access to sensitive CIDs can prevent the leakage of sensitive BIM data. Therefore, a novel method of integrating asymmetric encryption with blockchain was developed in CMF. Asymmetric encryption ( Figure 9A ) is a cryptographic system that uses key pairs, each of which consists of a public key (K pub ) and the private key (K pri ). Each peer generates a pair of keys and shares K in the public space pub , while making K pri Confidential. Any peer can use the recipient’s K pub Encrypt the message, but the encrypted message can only be read using the receiver's K pri Asymmetric encryption is a fundamental technology used in blockchain for peer authenticity verification, but existing research has not yet adopted this technology to implement blockchain ledger access control.

[0084] In the access control model, project members will share their K pub Before a designer shares the CID of a BIM component, he / she will check if the CID is sensitive. If not, the designer will directly propose a blockchain transaction (containing the component name, CID, version, etc.). Otherwise, he / she will use the K pub To encrypt the CID ( Figure 5C After that, he will broadcast the transaction with the encrypted CID (ECID) in the blockchain. In this way, the transaction with the corresponding K pri The recipient can decrypt the ECID to obtain the data link (i.e., CID) and download the sensitive BIM data. pub Different, project members will K pri Secrets are kept in their local key storage database. This integrated approach allows project members to share any design data in the blockchain network for collaboration, while keeping sensitive data encrypted and accessible to authorized members.

[0085] The proposed method has three main innovations. (1) The method shows how to integrate asymmetric encryption with blockchain to protect BIM confidentiality. In addition, it defines which design information (CID of sensitive BIM data) should be encrypted and where the key is stored and shared (K pub Shared in the blockchain, and K pri(2) The method enables the blockchain to balance data transparency (each project member can receive all encrypted or unencrypted design records) and data confidentiality (only authorized members can access sensitive data). (3) The method is the first time asymmetric encryption is integrated with the blockchain for BIM access control. Instead of managing access to each block, this method is more practical because it precisely encrypts sensitive BIM data (CID) in certain blocks to prevent unauthorized access.

[0086] Smart contracts in the blockchain allow transactions to interact with the ledger, containing the execution of payments, sharing of information, and automatic approval. Smart contracts are an integral part of the CMF because they are the intermediary between project members and the blockchain ledger. Project members (end devices) can only distribute data in the blockchain ledger by invoking smart contract functions. This section identifies the smart contract functions and explains their algorithms in the CMF (as shown in Figure 9B

[0087] Three functions are designed in the proposed CMF smart contract, namely (1) Key distribution (Keydist), (2) Information exchange (InfoExc), and (3) Query (Query). Keydist allows project members to share or update their K pub . The input is a transaction containing the member’s ID and its K pub . The output is a new block containing the input transaction. Six steps are involved in this function. Steps 1 and 2 are used to define and validate the input. A legal transaction will get the pre-execution peer’s signature and endorsement. In step 3, the smart contract sends the encryption key and signature to the customization service, which will package the transaction in chronological order to ensure data consistency. In steps 4 and 5, the smart contract will broadcast the transaction, and the project members will validate the transaction and add it to the local ledger. Finally, the initiator will get a notification that the encryption key has been successfully shared or updated. InfoExc supports sharing design information on the blockchain network. The input is a design transaction containing the ID of the design file, the file version, data ownership, CID, etc., and the output is a new block containing the design transaction. The steps of this function are similar to the KeyDist function, except for the input transaction data model. The Query function allows users to access K pub and existing design information in the blockchain ledger. For a query public key, the input is the ID of a specific member, and the smart contract will return the latest K pub . Similarly, if the input is a file ID, the smart contract will return the attributes of the design file.

[0088] Referring to Figure 9C , for example, end device 1 200 shares / registers a public key (Key1 pub ​) (as indicated by arrow A91). Terminal 2 100 accesses Key1 from the blockchain ledger BL via a smart contract pub (As shown by arrow A92), and download CID from IPFS network (As shown by arrow A93). Terminal 2 receives Key1 from receiver 200 pub The CID is encrypted into an ECID (as shown by arrow A94). The ECID is added to the blockchain ledger BL as a transaction TS1 via a smart contract (as shown by arrow A95). The receiving terminal 2 200 downloads the transaction TS1 from the blockchain ledger BL (as shown by arrow A96) and obtains the ECID through the transaction TS1. The terminal 1 200 uses the private key (Key1 pri ) decrypts the ECID into a CID (as indicated by arrow A97). The decrypted CID can then be used to download the corresponding uploaded BIM component from the IPFS network.

[0089] refer to Figure 10A and Figure 10B The following description is given, Figure 10A Shows the coordination workflow of sensitive BIM components, and Figure 10B Showing the rules for sharing revised BIM components and performing design coordination. One assumption is that project members have full access to the BIM model of their own domain, and only authorized members can access sensitive components from other domains.

[0090] exist Figure 10A In this process, a design team (e.g., the architecture team) decomposes the BIM model (step 1) and shares the encrypted CID (ECID) of a sensitive component (component n in version m) on the blockchain (step 2). Only authorized members of the structural or MEP team can download (step 3) and decrypt it. In this way, sensitive data in one domain is visible to authorized members of the other domain; therefore, coordination can continue (step 4). During this process, structural and MEP designers can combine this component with the complete BIM model of their respective domains for reference design or clash detection. They will then raise encrypted design questions (e.g., design issues) on the blockchain (step 5). The architecture team will review these questions (step 6) and modify the root architectural BIM model (step 7). Finally, the architecture team will decompose the revised BIM model (step 8) and share the updated component (component n in version m+1), repeating steps 2 to 6.

[0091] Considering that modifications to non-sensitive data may affect sensitive data in the model (and vice versa), the revised model sharing rules will be adjusted after step 8. Details are as follows Figure 10BAs shown. When root model changes occur on non-sensitive data, the modeler should determine whether these modifications affect sensitive data. If not, he only needs to decompose the revised non-sensitive components and share them with all members; otherwise, the affected sensitive components must be identified and encrypted to authorized members. Similarly, when root model changes occur on sensitive data, the modeler should immediately check if the modification affects non-sensitive data and he should share the affected components with all members. Otherwise, only the revised sensitive components should be encrypted and shared. From the receiver's perspective, there are three rules for cross-domain coordination: (1) Each member can see the overall model of his own domain; (2) Any member can perform model coordination using the complete domain model with external non-sensitive BIM components, and (3) Authorized members can coordinate using the complete domain model with external sensitive BIM components because, as mentioned above, this data is only visible to them. In this way, any design decision (regarding sensitive or non-sensitive areas) can be identified and made.

[0092] This workflow is consistent with most existing practices in terms of (1) coordination methods, (2) data access control, and (3) collaborative workflow. Figure 10A In , project teams can follow their conventions and software systems to build models, detect conflicts, and execute reference designs. Access control rules ( Figure 10A Step 4) in the previous section also complies with existing practices that only authorized members can access sensitive BIM data. In addition, the workflow was developed with reference to a common and standard coordination solution - the Common Data Environment (CDE) framework (introduced by the ISO 19650 standard) - where members create design data locally and share approved data in a common container (blockchain and IPFS network in this disclosure). Considering that project teams collaborate in an access-controlled and distributed environment, there are two mandatory changes: (1) models containing sensitive information should be decomposed before sharing, and (2) sensitive data (or data CID) must be encrypted.

[0093] These workflows have two novel features: “partial and whole coordination” and “root BIM model revision” mechanisms. First, although the data granularity in CMF (the smallest unit of BIM data exchange) is the BIM component, this workflow does not choose to unite external BIM components (models from other domains) with local components (models of its domain) in coordination ( Figure 10A4 in the previous section), which will inevitably increase collaboration difficulties and errors. Instead, this workflow uses a "partial and whole coordination" mechanism that allows members to combine external BIM components (partial BIM data) with their local complete BIM model (whole BIM data). This mechanism provides a more manageable and feasible coordination process, as well as protects sensitive data from unauthorized access. In addition, since there is common data (e.g., non-sensitive data) between parallel BIM components (components with the same root model), any revision of a component will not be completely independent (i.e., a revision will also affect other components). The "root BIM model revision" mechanism ( Figure 10A Step 7) of the previous section ensures that if a BIM component requires a design change, revisions are made to its corresponding root model rather than to the component itself. Updated components are generated by further decomposing the root BIM model. This mechanism ensures data consistency when all parallel components are updated simultaneously.

[0094] Version management of a complete BIM model only requires managing the version of this single model. In CMF, BIM data has a two-layer structure (i.e., a root model layer and a component layer) for access control purposes. Therefore, in CMF, it is a challenge to simultaneously manage (1) the versions of the root model and the components and (2) the relationship between the two layers. A Merkle tree or hash tree is a hash-based data structure in which a leaf node is a data hash and each non-leaf node is a hash of its child nodes. Merkle trees have been used in distributed systems for efficient data verification and version management. Merkle trees can only track changes by comparing the top hash values ​​of two model files. However, traditional Merkle trees have two limitations in managing BIM versions. First, Merkle tree nodes only contain hash values ​​and cannot store metadata such as BIM model names and versions. Second, Merkle trees only allow one-way data verification from leaf to root and cannot retrieve data in the reverse direction, so it is difficult to manage the relationship between BIM components (leaf nodes) and the root BIM model. Therefore, the present disclosure proposes a novel BIM Merkle tree (BMT) data structure for BIM data version management.

[0095] Figure 11AThe initialization of the BMT is shown. The BMT has two layers, with leaf nodes containing component version information and root nodes containing root model version information. In the leaf node, the component number (CN) is the ID of a specific component. The component version (CV) is the current version status of the component. The block number (BN) indicates which block in the blockchain stores the component's metadata (e.g., CID). Therefore, project members can query the blockchain ledger to access detailed component information. In the root node, the root version (RV) refers to the current version of the root BIM model. The chain hash (LH) set consists of hash values ​​of the data of each leaf node. These chain hashes serve as pointers between the root node and the leaf nodes. In this way, project members can retrieve leaf nodes from the root node via the corresponding LH. These hashes are hashed again to generate the root hash (RH) for data verification.

[0096] Figure 11A The right side of the diagram shows the BMT initialization algorithm. The input is component information. In step 1, leaf nodes are generated to form a component information (or leaf node) set. In step 2, chain hashes are calculated for the leaf nodes to form a chain hash set in the root node. In step 3, a root hash is calculated based on the chain hashes. The output is the four parts of the BMT: the component information (or leaf node) set, the chain hash set, the root hash, and the root version.

[0097] Figure 11B This paper presents how BMT facilitates BIM data version management. When there is a version update on a component, a new BMT (i.e., BMT 2) will be generated (e.g., Figure 11B ). A new leaf node with an updated version and a new root node with an updated chain hash set will be created. It should be noted that the new BMT does not copy the leaf nodes for the unchanged components. Instead, this root node is linked to the unchanged leaf nodes via the chain hash inherited from the previous BMT. In this way, each BMT retains a complete chain set between the root model (root node layer) and the components (leaf node layer) without data redundancy. More importantly, project members can (1) check the latest BMT tree to see the current version of each BIM component, and (2) view all BMTs to track the change history between versions. For example, querying BMT 2 will return results indicating that the root model is version 2, component m is version 2, and the remaining components are version 1. Figure 11B The right side of the diagram shows the BMT update algorithm. The input is the information about the component being updated. In step 1, any unchanged leaf nodes and their chain hashes are identified. The remaining steps for generating a new set of leaf nodes, a new set of chain hashes, a root hash, and a root version are the same as for the initialization algorithm.

[0098] For example, reference Figure 11C In step S1110 , the design coordination module executed by the processor 110 or the processor of the revision party terminal receives the updated BIM component.

[0099] Next, at step S1120, the design coordination module identifies the component number and the component version number of the received BIM component. Further, at step S1130, the design coordination module identifies the root version number of the root node of the BIM Merkle Tree (BMT).

[0100] In detail, the design coordination module maintains a BIM Merkle Tree (BMT) for the BIM design collaboration, wherein the BMT is configured to manage the design coordination operations. The BMT comprises: a root node; and one or more leaf nodes. The root node is configured to record: a root version number of the BMT; one or more chain hashes of the leaf nodes; and a root hash. Each of the leaf nodes is configured to record: a component number configured to identify a corresponding BIM component; a component version number configured to identify a version of the corresponding BIM component; a block number configured to record a block index of a target block for storing a target transaction corresponding to a CID of the corresponding BIM component; and an update date configured to record a date when the corresponding BIM component is updated.

[0101] At step S1140, the design coordination module identifies a target leaf node according to the component number and the one or more non-target leaf nodes of the BMT.

[0102] Next, at step S1150, the design coordination module generates a new target leaf node of the BMT according to the component number, the component version number, and the root version number. Next, at step S1160, the design coordination module generates a target chain hash of the target leaf node. Next, at step S1170, the design coordination module generates a new root node of the BMT according to the target chain hash and the old root node. Next, at step S1180, the design coordination module constructs a new BMT according to the new root node, the new target leaf node, and the non-target leaf nodes.

[0103] The BMT has three advantages. First, unlike the traditional Merkle Tree which only allows one-way data verification, the novel BMT facilitates leaf-to-root data verification and root-to-leaf data retrieval via chain hashes. This mechanism ensures that any version of the root node will always link to the correct leaf node, thereby maintaining the relationship between the BIM root model and its BIM components. Second, the BMT eliminates any unnecessary computation by only creating new links to any already up-to-date components, thereby improving the efficiency of version management. In addition, each leaf node has component version and block number information, thereby enabling fast localization of component data in a distributed blockchain network.

[0104] Reference Figure 12 The CMF framework is applied in a design example to demonstrate its feasibility and performance. Figure 12The proposed method is presented. Design teams coordinate in two scenarios to determine whether the proposed framework can achieve confidential design collaboration. Specific indicators include: (1) whether sensitive BIM data can be protected using the provided access control model, (2) whether project members can collaborate on both non-sensitive and sensitive BIM components using workflows presented through operations performed by the design coordination module, and (3) whether the provided BMT can be successfully initialized and updated to track BIM data versions.

[0105] The test environment is described as follows: (1) A Linux (Ubuntu 18.04) system with eight Intel(R) Core(TM) i7-10700 CPUs @ 2.90GHz and 16GB of memory was used to develop the blockchain network. (2) Hyperledger Fabric 1.4.0 (a long-term supported version) was selected as the blockchain platform in the CMF. (3) Different design teams were configured using independent Docker containers in the blockchain. (4) The blockchain smart contract was developed using the Go language (version 1.14), and the BMT was developed using the Python language (version 2.7).

[0106] The design collaboration example uses a BIM model of a university campus building with a total floor area of ​​8,300 square meters. The building has six floors and eight main areas, including lecture halls, seminar rooms, lounges, conference rooms, facilities rooms, laboratories, and open spaces. Three design teams (architecture, structure, and MEP teams) participated in the design phase, developing the architecture model, the structure model, and the MEP model respectively. In this case, the two laboratory areas on the third floor are sensitive. Figure 13 As shown, the architectural model has been decomposed into three BIM components. Components 1 and 2 are sensitive components that maintain the layout of zones 1 and 2, respectively. Figure 13 The access requirements for architecture team members to have full access to ARCH models / components are also presented. STRUCT 1 and MEP 1 have access to all architecture models, while STRUCT 2 and MEP 2 can only access non-sensitive components (i.e., component 3 in this study). This project generates 500 design transactions per day, with each block containing ten transactions. This study assumes that each model is updated 20 times per day to measure maximum latency and storage costs. All models have the same decomposition as the architecture model (i.e., one root model with three components).

[0107] refer to Figure 14 Data flow examples for scenario 1 and scenario 2.

[0108] Scenario 1: Coordination of non-sensitive BIM components. Project members from different domains will coordinate on component 3. They will perform design activities such as sharing component CIDs, raising design issues, and updating versions.

[0109] Reference Figure 15 which involves five activities. In activity 1, BMT 1 for the architectural model is initialized with one root node and three leaf nodes. Both the root model and components are version 1. In activity 2, ARCH 1 proposes a transaction in the blockchain sharing the CID of component 3 (COMP 3). Given that this is a non-sensitive component, it is accessible to any member in other domains. MEP designer, i.e., MEP 2, downloads component 3 and joins it with the complete MEP BIM model to perform conflict detection in activity 3. The design error of the wall on the third floor blocking the cable tray is identified. Therefore, MEP 2 proposes a design issue file in BIM Collaboration Format (BCF) and shares the file in the blockchain. ARCH 1 revises the non-sensitive zone in the root BIM model and decomposes the root model again to share the updated component 3. In activity 4, ARCH 1 prepares a new transaction broadcasting the CID of component 3 in version 2.

[0110] Further, in activity 5, the architectural team updates the BMT. As Figure 13 shown, the sensitive component is composed of non-sensitive components and partial (or full) sensitive data, and all sensitive components share common non-sensitive data (i.e., ARCH COMP 3). Therefore, any modification to the non-sensitive zone will cause data changes to all components. For example, if a designer tries to change the wall in the non-sensitive zone, he will modify the root model and decompose again, referring to the “root BIM model revision” process described above. In this way, all newly decomposed components have the updated wall. Since this design change is valid and consistent with other data in the asset model, two subsequent actions should be taken: updating the version of all components and sharing the revised BIM data. The new BMT updates all leaf nodes, instead of inheriting the leaf nodes from the previous tree. Currently, the root architectural model and all architectural components are version 2. Then, the sharing process follows the rules specified in Figure 10B In the case of scenario 1, the design change of COMP 3 does not affect the sensitive zone; therefore, it can be directly shared by all members.

[0111] Scenario 2: Coordination of sensitive BIM components. In this case, project members from different domains will coordinate on a sensitive BIM component (i.e., component 1). Design activities are performed, such as encrypting the component CID, sharing the ECID, and proposing an encrypted design issue.

[0112] In this scenario, ARCH 1 and MEP 1, the two designers, share their public keys (activities 6 and 7) to perform data encryption. Figure 16is a process diagram of Scenario 2. In Activity 8, ARCH 1 encrypts the CID of Component 1 (COMP1) using the public key of MEP 1. Then, ARCH 1 shares the ECID in the blockchain network by invoking the smart contract. Although all members receive the ECID, only the authorized recipient (e.g., MEP 1) can decrypt it to obtain the CID and download Component 1 from IPFS. In Activity 9, MEP 1 joins Component 1 with the complete MEP BIM model for design coordination. A design conflict in sensitive zone 1 is detected. Therefore, MEP 1 raises a design issue and encrypts the issue file CID using the public key of ARCH 1. After receiving the issue file, ARCH 1 revises the sensitive zone in the root BIM model accordingly and decomposes the root model again to share the updated Component 1. In Activity 10, ARCH 1 prepares a new transaction to share the ECID of Component 1 of version 3. The sensitive design data in the blockchain is encrypted, thus preventing unauthorized access.

[0113] The functional units of the apparatus and method according to embodiments disclosed herein can be implemented using electronic devices, computer processors, or electronic circuits containing, but not limited to, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), and other programmable logic devices that are configured or programmed to perform the teachings of the present disclosure. Machine instructions running in electronic devices, computer processors, or programmable logic devices can be readily prepared by software or those skilled in the electronic field based on the teachings of the present disclosure.

[0114] Based on the above, the present disclosure provides a confidentiality framework (CMF) for blockchain-based BIM design collaboration. Three objectives have been achieved.

[0115] First, an access control model is developed. In this model, the BIM model is decomposed into sensitive and non-sensitive components for data separation. An encryption blockchain integration method is proposed to encrypt sensitive BIM data in the blockchain ledger to avoid unauthorized access. A smart contract is also developed to support encryption key distribution and design information sharing in the blockchain.

[0116] Second, new strategies are developed to support feasible design collaboration within the access-controlled blockchain network. In short, these strategies consist of a new workflow for BIM component-based design coordination and a new BIM Merkle Tree (BMT) data model for component version management.

[0117] Third, the feasibility and performance of the CMF are tested in two design scenarios, and the results show that the CMF is a promising solution to protect sensitive data access and implement secure design collaboration.

[0118] Although the provided method and related examples are described as being applied to BIM data coordination, in another embodiment, the provided method can be applied to other types of data coordination, and the present invention is not limited thereto.

[0119] All or part of the method according to the embodiment may be executed in one or more computing devices including a server computer, a personal computer, a laptop computer, a mobile computing device such as a smartphone, and a tablet computer.

[0120] Embodiments include computer storage media having stored therein machine instructions that can be used to configure a microprocessor to perform any of the processes of the present invention. The storage medium can include, but is not limited to, floppy disks, optical disks, Blu-ray discs, DVDs, CD-ROMs and magneto-optical disks, ROMs, RAMs, flash memory devices, or any type of medium or device suitable for storing instructions, code, and / or data.

[0121] Each of the functional units according to various embodiments may also be implemented in a distributed computing environment and / or cloud computing environment, where all or part of the machine instructions are executed in a distributed manner by one or more processing devices interconnected by a communication network such as an intranet, a wide area network (WAN), a local area network (LAN), the Internet, and other forms of data transmission media.

[0122] The foregoing description of the present invention has been provided for purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form disclosed. Many modifications and variations will be apparent to those skilled in the art.

[0123] The embodiment was chosen and described in order to best explain the principles of the invention and its practical application, thereby enabling others skilled in the art to understand the invention for various embodiments and with various modifications as are suited to the particular use contemplated.

Claims

1. A computer-implemented method for performing Building Information Modeling (BIM) design collaboration via a server using an Interplanetary File System (IPFS) blockchain integrated network via a Confidentiality-Minded Framework (CMF), characterized in that: include: an access control module executed by a processor of the server to separate one or more sensitive and non-sensitive BIM portions of a BIM object; The provider terminal uploads the target BIM component to the IPFS network; Receiving, by the access model, a target content identifier (CID) of the target BIM component from the IPFS network; determining whether the target BIM component has one or more of the sensitive parts, Wherein, if the target BIM component has one or more of the sensitive parts, the access control module encrypts the target CID to obtain a target encrypted CID (ECID), and adds the target ECID as a target transaction to the target blockchain ledger via the target smart contract; otherwise If the target BIM component does not have any of the sensitive parts, adding, by the access control module, the target CID as the target transaction to the target blockchain ledger via the target smart contract; Accessing the target transaction by a revising party terminal to download the target BIM component from the IPFS network; and The revising terminal performs a design coordination operation on the target BIM component through the design coordination module to distribute the revised target BIM component to the receiving terminal via the access control module, the target blockchain ledger and the target smart contract.

2. The method according to claim 1, characterized in that The integrated network using the IPFS blockchain includes: The provider terminal uploads the target BIM component to the IPFS network; The IPFS network generates the target CID based on the content of the uploaded target BIM component; adding, by the IPFS network, the generated target CID as the target transaction corresponding to the uploaded BIM component to the target blockchain ledger; Downloading the target CID from the target blockchain ledger by the recipient terminal; determining whether the target CID is encrypted; If the target CID is encrypted, the receiving terminal generates a valid target CID based on the target CID and the encryption key; otherwise If the target CID is not encrypted, determining that the target CID is the valid target CID; The receiving terminal sends the valid target CID to the IPFS network; The receiving terminal downloads the target BIM component from the IPFS network; The receiving terminal verifies the downloaded target BIM component by comparing the hash value of the target BIM component with the valid target CID.

3. The method according to claim 2, characterized in that If the target BIM component has one or more of the sensitive parts, the method further includes: performing, by the access control module, a BIM data separation operation to define and separate the one or more sensitive BIM parts and the one or more non-sensitive BIM parts from the BIM object; performing BIM component registration by the provider terminal to register the target sensitive BIM component with the access control module via a target smart contract when uploading the target sensitive BIM component to the IPFS network, wherein the target sensitive BIM component includes at least one defined sensitive BIM part; Generating the target CID of the target sensitive BIM component by the IPFS network; performing, by the access control module, an encryption operation on the target CID according to a target public key to generate a target encrypted CID (ECID), wherein the target public key corresponds to the recipient terminal indicated by the BIM component registration; adding, by the access control module via the target smart contract, the target transaction corresponding to the target ECID to the target blockchain ledger; Obtaining, by the recipient terminal, the target ECID from the target transaction in the target blockchain ledger; Decrypting the target ECID by the receiving terminal using a target private key corresponding to the target public key to obtain the target CID; The receiving terminal downloads the target sensitive BIM component from the IPFS network through the decrypted target CID.

4. The method according to claim 3, characterized in that If the target BIM component does not have any sensitive parts, the method further includes: performing, by the access control module, a BIM data separation operation to define and separate the one or more sensitive BIM parts and the one or more non-sensitive BIM parts from the BIM object; performing BIM component registration by the provider terminal to register the target non-sensitive BIM component with the access control module when uploading the target non-sensitive BIM component to the IPFS network, wherein the target non-sensitive BIM component does not include any sensitive BIM part defined by the BIM data separation; Generating the target CID of the target non-sensitive BIM component by the IPFS network; adding, by the access control module via the target smart contract, the target transaction corresponding to the target CID from the IPFS network to the target blockchain ledger; obtaining, by the recipient terminal, the target CID from the target transaction of the target blockchain ledger; and The receiving terminal downloads the target non-sensitive BIM component from the IPFS network using the obtained target CID.

5. The method according to claim 1, characterized in that The method further comprises: The design coordination module maintains a BIM Merkle Tree (BMT) of the BIM design collaboration, wherein the BMT is configured to manage the design coordination operation. Wherein the BMT comprises: root node; and One or more leaf nodes, The root node is configured to record: The root version number of the BMT; One or more chain hashes of the leaf nodes; and root hash, Each of the leaf nodes is configured to record: A component number, wherein the component number is configured to identify a corresponding BIM component; a component version number, the component version number being configured to identify a version of the corresponding BIM component; a block number configured to record a block index of a target block for storing a target transaction corresponding to the CID of the corresponding BIM component; and An update date is configured to record a date on which the corresponding BIM component is updated.

6. The method according to claim 5, characterized in that The method further comprises: Receive updated BIM components; Identify the component number and component version number of the received BIM component; A root version number identifying the root node of the BIM Merkle Tree (BMT); Identifying a target leaf node based on the component number and one or more non-target leaf nodes of the BMT; generating a new target leaf node of the BMT according to the component number, the component version number, and the root version number; Generate a target chain hash of the target leaf node; Generate a new root node of the BMT based on the target chain hash and the old root node; and A new BMT is constructed according to the new root node, the new target leaf node, and the non-target leaf nodes.

7. A server for performing Building Information Modeling (BIM) design collaboration via a Confidentiality Framework (CMF) using an InterPlanetary File System (IPFS) blockchain integrated network, characterized in that include: A processor configured to execute machine instructions to implement a method comprising: an access control module executed by a processor of the server to separate one or more sensitive and non-sensitive BIM portions of a BIM object; The provider terminal uploads the target BIM component to the IPFS network; Receiving, by the access model, a target content identifier (CID) of the target BIM component from the IPFS network; determining whether the target BIM component has one or more of the sensitive parts, Wherein, if the target BIM component has one or more of the sensitive parts, the target CID is encrypted by the access control module to obtain a target encrypted CID (ECID), and the target ECID is added as a target transaction to the target blockchain ledger via the target smart contract; otherwise If the target BIM component does not have any of the sensitive parts, adding, by the access control module, the target CID as the target transaction to the target blockchain ledger via the target smart contract; Accessing the target transaction by a revising party terminal to download the target BIM component from the IPFS network; and The revising terminal performs a design coordination operation on the target BIM component through the design coordination module to distribute the revised target BIM component to the receiving terminal via the access control module, the target blockchain ledger and the target smart contract.

8. The server according to claim 7, wherein: The integrated network using the IPFS blockchain includes: The provider terminal uploads the target BIM component to the IPFS network; The IPFS network generates the target CID based on the content of the uploaded target BIM component; adding, by the access control module, the generated target CID as the target transaction corresponding to the uploaded BIM component from the IPFS network to the target blockchain ledger; Downloading the target CID from the target blockchain ledger by the recipient terminal; determining whether the target CID is encrypted; If the target CID is encrypted, the receiving terminal generates a valid target CID based on the target CID and the encryption key; otherwise If the target CID is not encrypted, determining that the target CID is the valid target CID; The receiving terminal sends the valid target CID to the IPFS network; The receiving terminal downloads the target BIM component from the IPFS network; The receiving terminal verifies the downloaded target BIM component by comparing the hash value of the target BIM component with the valid target CID.

9. The server according to claim 8, wherein: If the target BIM component has one or more of the sensitive parts, the method further includes: performing, by the access control module, a BIM data separation operation to define and separate the one or more sensitive BIM parts and the one or more non-sensitive BIM parts from the BIM object; performing BIM component registration by the provider terminal to register the target sensitive BIM component with the access control module via a target smart contract when uploading the target sensitive BIM component to the IPFS network, wherein the target sensitive BIM component includes at least one defined sensitive BIM part; Generating the target CID of the target sensitive BIM component by the IPFS network; performing, by the access control module, an encryption operation on the target CID according to a target public key to generate a target encrypted CID (ECID), wherein the target public key corresponds to the recipient terminal indicated by the BIM component registration; adding, by the access control module via the target smart contract, the target transaction corresponding to the target ECID to the target blockchain ledger; Obtaining, by the recipient terminal, the target ECID from the target transaction in the target blockchain ledger; Decrypting the target ECID by the receiving terminal using a target private key corresponding to the target public key to obtain the target CID; The receiving terminal downloads the target sensitive BIM component from the IPFS network through the decrypted target CID.

10. The server according to claim 9, wherein: If the target BIM component does not have any sensitive parts, the method further includes: performing, by the access control module, a BIM data separation operation to define and separate the one or more sensitive BIM parts and the one or more non-sensitive BIM parts from the BIM object; performing BIM component registration by the provider terminal to register the target non-sensitive BIM component with the access control module when uploading the target non-sensitive BIM component to the IPFS network, wherein the target non-sensitive BIM component does not include any sensitive BIM part defined by the BIM data separation; Generating the target CID of the target non-sensitive BIM component by the IPFS network; adding, by the access control module via the target smart contract, the target transaction corresponding to the target CID to the target blockchain ledger; obtaining, by the recipient terminal, the target CID from the target transaction of the target blockchain ledger; and The receiving terminal downloads the target non-sensitive BIM component from the IPFS network using the obtained target CID.

11. The server according to claim 7, wherein: The method further comprises: maintaining a BIM Merkle Tree (BMT) of the BIM design collaboration by the design coordination module, wherein the BMT is configured to manage the design coordination operations, Wherein the BMT comprises: root node; and One or more leaf nodes, The root node is configured to record: The root version number of the BMT; One or more chain hashes of the leaf nodes; and root hash, Each of the leaf nodes is configured to record: A component number, wherein the component number is configured to identify a corresponding BIM component; a component version number, the component version number being configured to identify a version of the corresponding BIM component; a block number configured to record a block index of a target block for storing a target transaction corresponding to the CID of the corresponding BIM component; and An update date is configured to record a date on which the corresponding BIM component is updated.

12. The server according to claim 11, wherein: The method further comprises: Receive updated BIM components; Identify the component number and component version number of the received BIM component; A root version number identifying the root node of the BIM Merkle Tree (BMT); Identifying a target leaf node based on the component number and one or more non-target leaf nodes of the BMT; generating a new target leaf node of the BMT according to the component number, the component version number, and the root version number; Generate a target chain hash of the target leaf node; Generate a new root node of the BMT based on the target chain hash and the old root node; and A new BMT is constructed according to the new root node, the new target leaf node, and the non-target leaf nodes.

Images