Information processing system, information processing method and program
The information processing system addresses user concerns by matching users with architects, reducing costs, and ensuring their virtual building designs meet requirements through a networked system that converts CAD data to 3D data for the Metaverse space.
Patent Information
- Application Number
- JP2024195631
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- Priority Date
- 2023-11-13
- Filing Date
- 2024-11-08
- Publication Date
- 2025-12-12
- Estimated Expiration
- 2044-11-08
AI Technical Summary
Users are concerned about whether the design will meet their desired requirements in construction projects, particularly in virtual building environments like the Metaverse space, due to high costs associated with typical metaverse architecture created by game creators.
An information processing system that matches users with architects through a network of architects, receiving user requests, selecting suitable architects, transmitting design requirements, and converting CAD data into 3D data for virtual buildings in the Metaverse space, utilizing a management server, user, architect, and intermediary terminals connected via a communication network.
Provides support that satisfies user needs by efficiently matching architects with user requests, reducing costs, and enabling low-cost virtual building services in the Metaverse space.
Smart Images

Figure 0007784756000001 
Figure 0007784756000002 
Figure 0007784756000003
Abstract
Description
[Technical Field]
[0001] The present invention relates to an information processing system, an information processing method, and a program. [Background technology]
[0002] Patent Document 1 proposes a system that allows a customer to order construction work only after they are satisfied with the construction plan and the construction contractor. [Prior art documents] [Patent documents]
[0003] [Patent Document 1] Japanese Patent Application Laid-Open No. 2002-170014 Summary of the Invention [Problem to be solved by the invention]
[0004] However, users are concerned about whether the design will meet their desired requirements.
[0005] The present invention has been made in view of the above background, and aims to provide a technology that can provide support that satisfies the needs of users. [Means for solving the problem]
[0006] The main invention of the present invention for solving the above problem is an information processing system comprising a request receiving unit that receives requests from users regarding virtual buildings to be placed in a virtual space, an architect selection unit that selects an architect who can meet the requests, a requirement sending unit that sends requirements related to the requests to the architect terminal of the architect, and a building data receiving unit that receives CAD data of the building that corresponds to the requirements from the architect terminal.
[0007] Other problems and solutions disclosed in this application will be made clear in the section on preferred embodiments of the invention and the drawings. [Effects of the Invention]
[0008] According to the present invention, it is possible to provide support that satisfies the user's needs. [Brief explanation of the drawings]
[0009] [Figure 1] FIG. 1 is a diagram illustrating an example of the overall configuration of an information processing system. [Figure 2] FIG. 2 illustrates an example of a hardware configuration of a management server 2. [Figure 3] FIG. 2 illustrates an example of the software configuration of a management server 2. [Figure 4] FIG. 10 is a diagram illustrating the operation of the management server 2. DETAILED DESCRIPTION OF THE INVENTION
[0010] <System Overview> An information processing system according to one embodiment of the present invention will be described below. The information processing system of this embodiment attempts to match users who wish to build virtual buildings with architects for virtual buildings provided in the Metaverse space. Matching can be performed via an intermediary.
[0011] The Metaverse service combines buildings and avatars based on the Metaverse platform to create and provide the content that clients want their end users to experience. Of the three elements that make up the Metaverse service, the Metaverse platform and architecture account for the majority of the costs. These two elements are high costs, which can hinder the service from being priced lower and become a hurdle to adoption.
[0012] While typical metaverse architecture is created by game creators, who incur high unit costs, this embodiment provides a low-cost service by creating a unique system that allows architects to design and by building a network of architects.
[0013] 1 is a diagram showing an example of the overall configuration of an information processing system. The information processing system of this embodiment is configured to include a management server 2. The management server 2 is communicably connected to a user terminal 1, a metaverse server 3, an architect terminal 4, and an intermediary terminal 5 via a communication network. The communication network is, for example, the Internet, and is constructed using a public telephone line network, a mobile phone line network, a wireless communication path, Ethernet (registered trademark), or the like.
[0014] The user terminal 1, the architect terminal 4, and the intermediary terminal 5 are computers operated by the user, the architect, and the intermediary. The user terminal 1, the architect terminal 4, and the intermediary terminal 5 can be, for example, a smartphone, a tablet computer, a personal computer, etc.
[0015] The metaverse server 3 is a computer that provides metaverse services. By accessing the metaverse server 3, the user terminal 1 can experience a simulated experience in a metaverse space (virtual space). The metaverse server 3 may be a general-purpose computer such as a workstation or personal computer, or may be logically realized by cloud computing.
[0016] The management server 2 may be a general-purpose computer such as a workstation or a personal computer, or may be logically realized by cloud computing.
[0017] <Administration Server> FIG. 2 is a diagram illustrating an example of the hardware configuration of the management server 2. Note that the illustrated configuration is an example, and other configurations may also be used. The management server 2 includes a CPU 201, a memory 202, a storage device 203, a communication interface 204, an input device 205, and an output device 206. The storage device 203 stores various data and programs, and is, for example, a hard disk drive, a solid state drive, or a flash memory. The communication interface 204 is an interface for connecting to a communication network, and is, for example, an adapter for connecting to Ethernet (registered trademark), a modem for connecting to a public telephone network, a wireless communication device for wireless communication, or a USB (Universal Serial Bus) connector or an RS232C connector for serial communication. The input device 205 is used to input data, and is, for example, a keyboard, a mouse, a touch panel, a button, a microphone, or the like. The output device 206 is used to output data, and is, for example, a display, a printer, a speaker, or the like. Each functional unit of the management server 2 described below is realized by the CPU 201 reading a program stored in the storage device 203 into the memory 202 and executing it, and each storage unit of the management server 2 is realized as part of the storage area provided by the memory 202 and the storage device 203.
[0018] 3 is a diagram showing an example of the software configuration of the management server 2. The management server 2 includes an attribute storage unit 231, a request storage unit 232, a matching storage unit 233, a building information storage unit 234, a request reception unit 211, an architect selection unit 212, a requirements acquisition unit 213, a requirements transmission unit 214, a building data reception unit 215, and a 3D data creation unit 216.
[0019] <Storage section> The attribute storage unit 231 stores information related to the attributes of architects (hereinafter referred to as attribute information). The attribute information can include an attribute value for each attribute in association with information that identifies the architect (for example, an architect ID). The attribute value can be a numerical value, text data, image data, video data, etc. The attribute value may be, for example, a tag value that can be set arbitrarily.
[0020] The attributes of an architect may include, for example, a basic attribute, an expertise attribute, a track record attribute, a communication attribute, a budget attribute, and a schedule attribute.
[0021] The basic attributes may include, for example, name, affiliation, type of architect qualification (first-class architect, second-class architect, etc.), years of work experience, and the like.
[0022] Specialty attributes may include, for example, preferred architectural styles (Japanese, modern, minimalist, etc.), categories of major design achievements (residential, commercial, public facilities, etc.), types of special buildings that can be handled, whether environmentally friendly construction is available, and the level of expertise in earthquake-resistant and seismic isolation design.
[0023] Performance attributes may include, for example, performance in designing special buildings, performance in environmentally friendly buildings, awards received, number of design projects, number of completed projects, number of projects by budget range, number of projects by site area, completion schedule compliance rate, and customer satisfaction rating.
[0024] The communication attributes may include, for example, available languages, availability of remote support, desired frequency of meetings, and communication style (emphasis on face-to-face communication, emphasis on email, etc.).
[0025] Budget attributes may include, for example, standard design rates, hourly rates, etc.
[0026] The schedule attributes may include when the project can be accepted, the desired project size, the number of projects that can be carried out simultaneously, and so on.
[0027] The information registered in the attribute value storage unit 231 may be, for example, set by receiving a value set by the architect himself from the architect terminal 4, or by receiving a value evaluated by the intermediary from the intermediary terminal 5.
[0028] The request storage unit 232 stores information (hereinafter, "request information") regarding requests from users regarding virtual buildings to be placed in virtual space. The request information can include information to identify the user (e.g., user ID), the date and time the request was received, the request, and a status. Request formats can include, for example, text data, audio data, image data, video data, and three-dimensional data. The text data request can be free-text data. The request can be a selection of an option for a given item, or a free-text entry for a given item. The status can include a state in which the request has been registered, a state in which an architect who can fulfill the request has been selected, a state in which a request has been made to the architect, a state in which the architectural data has been delivered by the architect, and so on. When request information is registered, a status in which the request has been registered can be set.
[0029] The matching storage unit 233 stores information relating to matching between a user and an architect (hereinafter referred to as matching information). The matching information includes information for identifying the user and information for identifying the architect.
[0030] The building information storage unit 234 stores information (hereinafter referred to as building information) related to 3D data of a virtual building created by an architect in response to a user's request. The building information may include information identifying the user, the user's request, requirements for the architect created in response to the request, information identifying the architect, CAD data created by the architect, and 3D data created based on the CAD data.
[0031] <Functional section> The request receiving unit 211 receives requests from users regarding virtual buildings to be placed in a virtual space. The request receiving unit 211 can receive requests from the user terminal 1. The request receiving unit 211 can register request information including the received request, information identifying the user who sent the request, and the current date and time in the request storage unit 232.
[0032] The request receiving unit 211 can also receive requests from users in various formats. The request formats can include, for example, text data, audio data, image data, video data, and three-dimensional data. Examples of text data include descriptions in natural language, input into a standard format, and tagged structured data. Examples of audio data can include voice input via telephone, voice messages, and data converted into text by voice recognition. Examples of image data can include scanned data of handwritten sketches, photographs, and images created using computer graphics. Examples of video data can include videos of buildings from various angles, walk-through videos, and animations. Examples of three-dimensional data can include simple three-dimensional models, three-dimensional scan data of reference buildings, and space-specific data in virtual spaces. The request receiving unit 211 can receive requests in these formats alone or in combination.
[0033] The architect selection unit 212 can select an architect who can fulfill the request. The architect selection unit 212 can select an architect when the request reception unit 211 receives a request. The architect selection unit 212 can select an architect for request information stored in the request storage unit 232 that has been registered.
[0034] The architect selection unit 212 allows the intermediary to select an architect. The architect selection unit 212 can send a message including the request to the intermediary terminal 5 and receive information identifying the architect from the intermediary terminal 5. The intermediary terminal 5 can access the attribute storage unit 231 to view the attribute information, and the intermediary can select an architect that matches the request by referring to the attribute information.
[0035] The architect selection unit 212 may select an architect corresponding to attribute values that match the request. For example, the architect selection unit 212 can determine whether each attribute included in the attribute information is included in the request, and for the attributes included in the request, determine whether the attribute value matches the condition included in the request. The architect selection unit 212 can select architects according to the number of matching attribute values (a predetermined number in descending order of the number of matches).
[0036] The architect selection unit 212 can select an architect who can meet the requirements using various selection algorithms, such as rule-based selection, selection using statistical methods, selection using machine learning, and selection using artificial intelligence.
[0037] Rule-based selection may include selection based on predetermined conditions, selection by scoring, and selection based on priority. Specifically, a predetermined weight is assigned to each attribute included in the attribute information, and an architect can be selected based on the sum of the weighted evaluation values. For example, weights such as 0.3 for the degree of matching of architectural style, 0.2 for the degree of matching of budget range, 0.2 for the number of achievements, 0.2 for the evaluation value, and 0.1 for the degree of matching of schedule can be assigned, and the sum of the products of the degrees of matching and the weights for each attribute can be calculated as the evaluation value. In addition, the required conditions included in the request can be used as filtering conditions to select architects with high evaluation values from among those who meet the required conditions.
[0038] Selection using statistical methods may include selection based on past contract performance, selection based on customer ratings, and selection based on market analysis. For example, an architect can be selected using a clustering method. Specifically, architects can be clustered based on their attribute information, the cluster that best matches the requirements can be identified, and an architect belonging to the identified cluster can be selected. Examples of clustering methods that can be used include k-means, hierarchical clustering, and density-based clustering.
[0039] Selection by machine learning may include selection by supervised learning, selection by unsupervised learning, selection by reinforcement learning, etc. Selection by artificial intelligence may include selection by large-scale language models, selection by neural networks, selection by knowledge-based systems, etc. A machine learning model may learn, for example, from past contract performance data. The training data may include requests, attributes of the user who made the request, attribute information of the selected architect, and results such as whether or not the contract was concluded and evaluation values. Examples of machine learning models that can be used include random forests, gradient boosting, and neural networks. Recommendation algorithms such as collaborative filtering and content-based filtering may also be used.
[0040] The architect selector 212 can use these selection algorithms alone or in combination.
[0041] Furthermore, for example, when the requirements are free-text data, the architect selection unit 212 can determine whether the architect's attributes satisfy the user's requirements by providing the large-scale language model with a prompt for each architect, which includes attribute information corresponding to the architect, the requirements, and an instruction to determine whether the attribute values included in the attribute information satisfy the requirements. Note that, assuming that the text data includes multiple requirements, the prompt may include an instruction to what extent the architect's attributes satisfy the requirements. In this case, the architect selection unit 212 can select architects according to the degree to which the requirements are satisfied (a predetermined number in descending order of degree).
[0042] The architect selection unit 212 can create matching information including information for identifying the user and information for identifying the selected architect, and register the created matching information in the matching storage unit 233 .
[0043] The requirement acquisition unit 213 creates requirements for placing an order with an architect based on the user's request.
[0044] For example, the requirements acquisition unit 213 can send the requirements to the intermediary's intermediary terminal 4, have the intermediary convert the requirements into requirements to be presented to the architect, and receive the converted requirements from the intermediary terminal 4.
[0045] Furthermore, for example, the requirements sending unit 214 can generate requirements related to the requests by providing a prompt including the requests and an instruction to summarize the requests as requirements in a predetermined format to the large-scale language model. The requirements sending unit 214 can send the requirements created from the requests to the architect terminal 5.
[0046] The requirement sending unit 214 sends the requirements related to the request to the architect terminal 5 of the architect. The requirement sending unit 214 can send a message including the requirements to the architect by email, chat service, or the like.
[0047] Furthermore, the requirement sending unit 214 can create and register in the construction information storage unit 234 construction information including information for identifying the user, requests, requirements, and information for identifying the architect.
[0048] The building data receiving unit 215 receives CAD data of a building corresponding to the requirements from the architect terminal 5. The building data receiving unit 215 can write the CAD data into the corresponding building data. Note that the building data receiving unit 215 may also create building information including information identifying the user, requests, requirements, information identifying the architect, and CAD data, and register this information in the building information storage unit 234.
[0049] The architectural data receiving unit 215 can receive architectural data in various CAD formats. CAD formats can include, for example, 2D CAD formats, 3D CAD formats, BIM (Building Information Modeling) formats, intermediate formats, etc. 2D CAD formats can include DXF, DWG, SVG, etc. 3D CAD formats can include STEP, IGES, OBJ, FBX, etc. BIM formats can include IFC, RVT, PLN, etc. Intermediate formats can include proprietary formats, conversion formats, compressed formats, etc. The architectural data receiving unit 215 can receive these CAD formats alone or in combination. The architectural data receiving unit 215 can also include a function for converting the received CAD data into a predetermined format.
[0050] The 3D data creation unit 216 creates 3D data for placing a building in a virtual space based on CAD data. The 3D data creation unit 216 can convert CAD data into 3D data used in the metaverse space based on predetermined rules. The 3D data creation unit 216 can write the created 3D data into corresponding building information. Note that the 3D data creation unit 216 may create building information including information identifying the user, requests, requirements, information identifying the architect, CAD data, and 3D data, and register the information in the building information storage unit 234.
[0051] An example of a method for creating 3D data by the 3D data creation unit 216 will be described.
[0052] The 3D data creation unit 216 first analyzes the received CAD data to identify the structure of the building. Specifically, it identifies structural elements such as walls, floors, ceilings, columns, beams, and openings, and extracts attribute information such as the position, dimensions, and orientation of each structural element. It also extracts design information such as material, color, and texture.
[0053] The 3D data creation unit 216 then constructs a 3D model based on the extracted information. Specifically, the following processes can be performed: 1. Generate 3D geometry for each structural element, for example, generate walls as cuboids and columns as cylinders. 2. Treat joints and intersections between structural elements, for example, proper treatment of wall and floor joints. 3. Place 3D models of frames and fixtures for openings. 4. Map materials and textures. 5. Place the light source and calculate shadows and reflections.
[0054] The 3D data creation unit 216 converts the constructed 3D model into a format that can be used in the Metaverse space. The conversion process may include the following processes: 1. Optimizing the number of polygons: Adjust the number of polygons to an appropriate level taking into account drawing performance. 2. Texture optimization: Adjust texture size and format. 3. LOD (Level of Detail) generation: Generate models with different levels of detail depending on the distance from the viewpoint. 4. Generate collision data: Generate collision detection data for physics calculations. 5. Generation of animation data: Generate animation data for moving parts such as doors and windows that open and close.
[0055] The 3D data creation unit 216 adds various metadata to the converted 3D data, which is necessary for use in the Metaverse space. The metadata may include the following information: 1. Building identification information 2. Rights Information 3. Interaction Information 4.Preferences information 5. Update history information
[0056] The 3D data creation unit 216 can transmit 3D data to the user terminal 1. A user can transmit 3D data from the user terminal 1 to the metaverse server 3 and place a building based on the 3D data in the metaverse space. Note that the 3D data creation unit 216 may transmit the 3D data to the metaverse server 3. Furthermore, the functions provided by the 3D data creation unit 216 may be provided in advance in the architect terminal 4, and the architect terminal 4 may execute the process of converting CAD data into 3D data.
[0057] <Operation> FIG. 4 is a diagram illustrating the operation of the management server 2.
[0058] The management server 2 receives requests from the user (S301), selects an architect who can meet the user's requests (S302), creates requirements to be presented to the architect based on the user's requests (S303), sends the created requirements to the architect terminal 4 of the selected architect (S304), receives CAD data from the architect terminal 4 (S305), converts the CAD data into 3D data to be used in the metaverse space (S306), and sends the 3D data to the metaverse server 3, allowing the building designed by the architect to be placed in the metaverse space (S307). Note that, as described above, if the architect terminal 4 executes the process of converting CAD data into 3D data in advance, the management server 2 can also receive the converted 3D data from the architect terminal 4.
[0059] As described above, the information processing system of this embodiment can match architects with user requests. It can also create requirements for architects based on the requests and provide instructions. It can also convert CAD data from architects into 3D data for use in the Metaverse space.
[0060] Although the present embodiment has been described above, the above embodiment is intended to facilitate understanding of the present invention and is not intended to limit the present invention. The present invention may be modified or improved without departing from the spirit thereof, and equivalents thereof are also included in the present invention.
[0061] For example, the processing by each of the functional units of the management server 2 described above may be performed by any of the functional units. Also, a different functional unit that performs part of the processing by each of the functional units described above may be added. Also, the functional units of the management server 2 may be distributed across multiple computers.
[0062] Furthermore, the information stored in each storage unit of the management server 2 may be stored in any of the storage units. That is, the information stored in the above-mentioned multiple storage units may be stored in one storage unit, or part of the information stored in one of the above-mentioned storage units may be stored in another storage unit.
[0063] <Variation 1> Various modifications can be considered for the method of receiving a request by the request receiving unit 211. The modifications will be described below.
[0064] The request receiving unit 211 can receive requests input via voice. The request receiving unit 211 can convert the voice into text data using voice recognition technology and identify the request from the converted text data. A voice recognition model using deep learning can be used for the voice recognition. The request receiving unit 211 can also interact with the voice request. For example, if a user says, "I want to build a Japanese-style building," the request receiving unit 211 can ask questions such as, "Is there a specific style of Japanese-style architecture?" and "Do you have any particular preferences for the shape of the roof?", thereby interactively specifying the request. Furthermore, the request receiving unit 211 can analyze emotions and intentions from the voice and estimate the user's latent needs.
[0065] The request receiving unit 211 can receive input of spatial requests using AR (Augmented Reality) technology or VR (Virtual Reality) technology. For example, when using AR technology, a user can input a request to place a building in a real space by holding a smartphone or tablet device over that space. The user can use gesture operations on the screen to draw the rough outline of the building, specify its height, and specify its direction. Furthermore, when using VR technology, the user can intuitively specify the placement and size of the building in a virtual space. The user can intuitively grasp the position, orientation, and scale of the building while walking around in the virtual space and input this as a request.
[0066] The request receiving unit 211 can extract requests based on photographs and sketches of existing buildings. The request receiving unit 211 can identify architectural styles, structural features, design elements, and the like from photographs and sketches using image recognition technology. For example, the request receiving unit 211 can detect the roof shape, opening arrangement, exterior wall materials, and the like that are unique to Japanese-style architecture from photographs and interpret these as requests. In addition, the request receiving unit 211 can extract architectural features from handwritten sketches using line drawing recognition technology. Furthermore, the request receiving unit 211 can learn architectural elements that the user prefers by combining and analyzing multiple photographs and sketches, and interpret these as more detailed requests.
[0067] The request receiving unit 211 can receive input of requests in an interactive wizard format. Input in the wizard format allows requests to be specified in stages, from basic elements of a building to detailed elements. For example, options for basic elements such as the use, size, and style of the building are first presented, and then options for more detailed elements (room layout, interior style, types of facilities, etc.) are presented depending on the user's selection. By providing visual examples such as 3D models and rendering images at each stage, the user can more accurately communicate their requests. In addition, the request receiving unit 211 can present more appropriate options by analyzing the user's selection history and learning the user's preferences. Furthermore, it can also suggest related elements and alternatives based on the selection at each stage.
[0068] The request receiving unit 211 can receive requests by combining the above-mentioned methods. For example, while inputting in the wizard format, it is possible to upload reference photos, provide supplementary explanations by voice, or specify a space using AR / VR. Furthermore, it is possible to integrate and interpret requests received by each input method and process them as requests that more accurately reflect the user's intentions.
[0069] <Variation 2> Various modifications can be considered for the method of selecting an architect by the architect selection unit 212. The modifications will be described below.
[0070] The architect selection unit 212 can perform matching based on the architect's portfolio. The portfolio includes image data, 3D models, design drawings, concept descriptions, etc. of buildings that the architect has previously worked on. The architect selection unit 212 can extract features such as architectural style, design elements, and spatial composition from each portfolio using image recognition technology and natural language processing technology. The architect selection unit 212 can also calculate the similarity between the extracted features and the requirements and select an architect with a high similarity. Furthermore, the architect selection unit 212 can evaluate the architect's track record and reliability by taking into account evaluation information (client evaluation, expert evaluation, award history, etc.) of the buildings included in the portfolio. The architect selection unit 212 can also identify the architect's areas of expertise and distinctive design approaches based on the portfolio analysis results and determine their compatibility with the requirements.
[0071] The architect selection unit 212 can make selections based on the architect's real-time availability. The architect selection unit 212 can manage information such as each architect's project status, schedule, and workload in real time. For example, the architect selection unit 212 can grasp the latest availability by periodically receiving updates on the working status from the architect terminal 4 or by linking with a schedule management system. The architect selection unit 212 can select an architect with appropriate availability depending on the urgency of the request and the desired delivery date. Furthermore, the architect selection unit 212 can estimate the optimal number of man-hours for the request, taking into account the work efficiency and processing capacity of each architect, and select an architect with availability that can handle that number of man-hours. Furthermore, the architect selection unit 212 can predict future availability and select an appropriate architect for long-term projects.
[0072] The architect selection unit 212 can make an optimized selection taking into account the budget and schedule. The architect selection unit 212 can compare the budget constraints and delivery date constraints included in the request with each architect's design fee rate, work speed, estimated man-hours, etc., and identify an architect who satisfies the constraints. The architect selection unit 212 can also derive the optimal combination of architects taking both the budget and schedule into consideration using optimization algorithms such as linear programming and dynamic programming. Furthermore, the architect selection unit 212 can analyze each architect's budget compliance rate and schedule compliance rate from past project data and perform risk assessment. The architect selection unit 212 can preferentially select architects with a low risk of budget overruns and schedule delays.
[0073] The architect selection unit 212 can form a team of multiple architects. The architect selection unit 212 can determine the necessary expertise and number of architects depending on the scale and complexity of the request, and determine the optimal team composition. For example, a team can be formed by combining architects with different specialties, such as structural design, equipment design, and interior design of a building. The architect selection unit 212 can also determine the allocation of roles within the team, taking into account each architect's area of expertise and experience. Furthermore, the architect selection unit 212 can analyze the compatibility between architects and their past collaborative performance, and select a combination that is expected to produce efficient teamwork. The architect selection unit 212 can also predict team performance and optimize or adjust the team composition as necessary.
[0074] The architect selection unit 212 can select an architect by combining the above-mentioned methods. For example, after narrowing down the candidates through portfolio analysis, it can execute a step-by-step selection process, such as checking real-time availability, optimizing the budget and schedule, and forming a team as needed. It can also weight each selection method and make a final selection based on a comprehensive evaluation.
[0075] <Variation 3> Various modifications can be considered for the method of creating requirements by the requirement acquisition unit 213. The modifications will be described below.
[0076] The requirements acquisition unit 213 can automatically generate requirements using templates. The requirements acquisition unit 213 can store multiple templates according to the type, size, and use of a building. The templates include standard requirements necessary for building design, such as legal requirements such as the Building Standards Act, technical requirements related to structural design, and requirements related to architectural design. The requirements acquisition unit 213 can analyze the received request to identify the characteristics of the building and select a template that is most suitable for the identified characteristics. The requirements acquisition unit 213 can also set specific requirement values for each requirement item of the selected template based on the content of the request. Furthermore, the requirements acquisition unit 213 can add, delete, or change requirement items included in the template according to the characteristics of the building. The requirements acquisition unit 213 can also analyze the usage history of the template and improve the template or create a new template.
[0077] The requirements acquisition unit 213 can create requirements by referencing similar past projects. The requirements acquisition unit 213 can search for projects similar to the current request from past project data accumulated in the building information storage unit 234. Elements such as the type, size, use, design features, and budget of the building can be used to determine similarity. The requirements acquisition unit 213 can analyze the requirements of the searched similar projects and extract requirements applicable to the current request. The requirements acquisition unit 213 can also generate new requirements by combining requirements extracted from multiple similar projects. Furthermore, the requirements acquisition unit 213 can analyze the fulfillment status of requirements in similar projects and their consistency with actual buildings, and evaluate the effectiveness of the requirements. The requirements acquisition unit 213 can also adjust and optimize the requirements based on the evaluation results.
[0078] The requirements acquisition unit 213 can refine requirements through an interactive process. The requirements acquisition unit 213 can interactively exchange the generated initial requirements with the architect via the architect terminal 4. The architect can confirm the feasibility of each requirement item, propose specific implementation methods, present alternatives, and so on. The requirements acquisition unit 213 can modify the requirements based on feedback from the architect and make them more feasible. Furthermore, the requirements acquisition unit 213 can confirm the user's opinions via the user terminal 1 during the requirement refinement process and adjust the requirements to better meet the user's intentions. Furthermore, the requirements acquisition unit 213 can accumulate knowledge obtained during the dialogue process and utilize it in creating future requirements. The requirements acquisition unit 213 can also analyze the dialogue history to establish an efficient requirements refinement process.
[0079] The requirements acquisition unit 213 can automatically verify the created requirements. The requirements acquisition unit 213 can verify consistency between requirements, conformity with legal requirements, technical feasibility, etc. For example, the requirements acquisition unit 213 can verify conformity with legal requirements by comparing with a database of legal regulations such as the Building Standards Act. The requirements acquisition unit 213 can also verify the feasibility of the requirements by performing technical verification such as structural calculations and environmental simulations. Furthermore, the requirements acquisition unit 213 can verify consistency with budget constraints and schedule constraints to confirm the feasibility of the project. The requirements acquisition unit 213 can also identify problems with the requirements based on the verification results and automatically propose corrections. The requirements acquisition unit 213 can continuously improve the verification process and achieve more accurate verification.
[0080] The requirements acquisition unit 213 can create requirements by combining the above-mentioned methods. For example, it can execute a step-by-step process in which initial requirements are generated based on a template, the requirements are supplemented by referring to similar past cases, the requirements are refined through an interactive process, and finally automatic verification is performed. The requirements acquisition unit 213 can also select the optimal combination depending on the characteristics and circumstances of the case, taking into account the characteristics of each method.
[0081] <Disclosures> The present disclosure also includes the following configurations. [Item 1] a request receiving unit that receives requests from a user regarding a virtual building to be placed in a virtual space; an architect selection unit for selecting an architect who can meet the request; a requirements transmission unit that transmits the requirements related to the request to an architect terminal of the architect; a building data receiving unit that receives CAD data of the building corresponding to the requirements from the architect terminal; An information processing system comprising: [Item 2] Item 1, an information processing system according to item 1, an attribute storage unit that stores attribute values of the architect; the architect selection unit selects the architect corresponding to the attribute value that matches the request; An information processing system characterized by: [Item 3] Item 1, an information processing system according to item 1, a requirements acquisition unit that transmits the request to a mediator terminal of a mediator and receives from the mediator terminal the requirements to be presented to the architect in response to the request; An information processing system characterized by: [Item 4] Item 1, an information processing system according to item 1, a 3D data creation unit that creates 3D data for placing the building in the virtual space based on the CAD data; An information processing system characterized by: [Item 5] receiving from a user a request for a virtual building to be placed in a virtual space; selecting an architect who can accommodate the request; a step of transmitting the requirements related to the request to an architect terminal of the architect; receiving CAD data of the building corresponding to the requirements from the architect terminal; An information processing method characterized by being executed by a computer. [Item 6] receiving from a user a request for a virtual building to be placed in a virtual space; selecting an architect who can accommodate the request; a step of transmitting the requirements related to the request to an architect terminal of the architect; receiving CAD data of the building corresponding to the requirements from the architect terminal; A program that causes a computer to execute the following. [Explanation of symbols]
[0082] 1. User terminal 2 Management Server 3 Metaverse Server 4. Architect Terminal 5. Intermediary terminal
Claims
1. a request receiving unit that receives requests from a user regarding a virtual building to be placed in a virtual space; an architect selection unit for selecting an architect who can meet the request; a requirements transmission unit that transmits the requirements related to the request to an architect terminal of the architect; a building data receiving unit that receives CAD data of the building corresponding to the requirements from the architect terminal; Equipped with a requirement acquisition unit that transmits the request to a mediator terminal of a mediator and receives from the mediator terminal the requirements to be presented to the architect in response to the request; An information processing system characterized by:
2. 2. The information processing system according to claim 1, an attribute storage unit that stores attribute values of the architect; the architect selection unit selects the architect corresponding to the attribute value that matches the request; An information processing system characterized by:
3. 2. The information processing system according to claim 1, a 3D data creation unit that creates 3D data for placing the building in the virtual space based on the CAD data; An information processing system characterized by:
4. receiving from a user a request for a virtual building to be placed in a virtual space; selecting an architect who can accommodate the request; a step of transmitting the requirements related to the request to an architect terminal of the architect; receiving CAD data of the building corresponding to the requirements from the architect terminal; a step of transmitting the request to an intermediary terminal of an intermediary and receiving the requirements to be presented to the architect in response to the request from the intermediary terminal; An information processing method characterized by being executed by a computer.
5. receiving from a user a request for a virtual building to be placed in a virtual space; selecting an architect who can accommodate the request; a step of transmitting the requirements related to the request to an architect terminal of the architect; receiving CAD data of the building corresponding to the requirements from the architect terminal; a step of transmitting the request to an intermediary terminal of an intermediary and receiving the requirements to be presented to the architect in response to the request from the intermediary terminal; A program that causes a computer to execute the following.
Citation Information
Patent Citations
Idea correcting device, consulting mediating device, idea cultivating system, idea correcting method, consulting mediating method and recording medium
JP2002133073A
Order-receiving and execution system for building business
JP2002170014A
Expert service provision system, expert management server, computer program, storage medium, and method of operating expert management server
JP2003067593A
Construction system
JP2004246547A
Method and system for selling merchandise related to sheet metal facility
JP2005157820A