Construction Source Record and Project Reconciliation System with Life Cycle Chain of Custody Capability
A database reconciliation system stores construction project data, including project specification data for each of a plurality of projects and contractor data for each of a plurality of contractors. The system enables parties to make changes to the project specification data during the course of a project. The system also stores, and receives new, information about a plurality of deliveries of construction materials to respective construction sites. The system automatically associates each delivery of a delivered construction material to an associated contractor and to an associated project. The system may make inferences, based on past deliveries, to make the associations. If the system successfully verifies delivered construction materials comply with respective material specification requirements in the project specification data of the associated project, the system automatically stores delivery confirmation data for the delivered construction material and the associated contractor, thereby providing backing documentation for payments between project stakeholders.
This application is continuation of U.S. patent application Ser. No. 17/720,639, filed Apr. 14, 2022, titled “Construction Source Record and Project Reconciliation System with Life Cycle Chain of Custody Capability,” the disclosure of which is hereby incorporated by reference in its entirety.
TECHNICAL FIELDThe invention relates to construction project management systems, and more particularly to such systems capable of reconciling differences among data stored by various parties involved in a construction project, at least in part based on maintained chain of custody information.
BACKGROUNDLarge construction projects, such as highways, bridges, airports, and buildings, typically involve many parties, each with its own way of representing and storing data related to a project. For example, a state department of transportation (DOT) may use an electronic database to store project plans, identities of assigned employees, and a list of contractors working on each project. Each project may involve many contractors, such as pavers, steel erectors, and construction debris haulers. Each contractor on a given project may have its own paper or electronic database to keep track of hauls of construction materials to or from various construction sites. The contractors typically obtain construction materials, such as ready-mix concrete, aggregates, structural steel beams, hot-mix asphalt (“HMA”), timber, salt, etc., from suppliers, and sometimes contractors engage subcontractors to perform some tasks and/or to provide or haul some construction materials. Each of these suppliers and subcontractors may have its own paper or electronic database for keeping track of construction materials supplied or hauled to or from construction sites.
A project owner, such as a DOT, typically requires source documentation of construction materials delivered to construction sites. The source documentation must be created at a point of origin of the construction material, adequately describe type and quantity of construction material delivered, and meet other requirements. Source documentation requirements are particularly stringent for federally funded projects. Exemplary federal rules regarding source documentation may be found in in 23 CFR 635.123 (“Determination and documentation of pay quantities”) and 2 CFR 200 (“Uniform Administrative Requirements, Cost Principles, and Audit Requirements for Federal Awards”).
A contractor must fulfil these requirements before a project owner will pay the contractor for construction materials delivered to a construction site. The contractor is then responsible for paying his supplier and/or subcontractor. However, even if all the parties involved maintain electronic databases, these databases are independently developed and incompatible with each other. These incompatibilities require manual intervention to facilitate a meaningful exchange of information and payment for delivered construction materials.
For example, each haul of construction material from a supplier to a construction site is accompanied by a “haul ticket,” which lists the supplier, type and quantity of construction material being hauled, contractor who ordered the construction material, etc. However, not all suppliers use a consistent nomenclature. One supplier may refer to a given contractor with one name (ex. “Acme Construction Co., Inc.”), whereas another supplier may refer to the same contractor with a different name (ex. “Acme” or “ACME”), each of which may be different from the way a DOT database identifies the contractor. Furthermore, some suppliers may list a project name (ex., “Main Street Bridge”) or a project owner (ex. “Pennsylvania DOT”), instead of the contractor name. Similarly, different parties may refer to the same construction material using different names or designations.
Paper haul tickets containing such inconsistencies or errors can nonetheless be properly handled as a result of manual sorting of the haul tickets at construction sites by receiving inspectors who may place the haul tickets into respective boxes, each box being associated with a respective contractor. However, electronic haul tickets cannot so easily be sorted or corrected. Thus, simply digitizing haul tickets exasperates, rather than solves, the problem.
There is, therefore, a need for a system that can automatically reconcile differences among data stored by various parties involved in a construction project.
SUMMARY OF EMBODIMENTSBenefits and advantages of the present invention over existing systems will be readily apparent from the Detailed Description to follow. One skilled in the art will appreciate that the present teachings can be practiced with embodiments other than those summarized or disclosed below.
An embodiment of the present invention provides a database reconciliation system. The system includes a first electronic database, a first interface, a second electronic database, a server, a data reconciliation module, a comparator, and a second interface.
The first electronic database is configured to store construction project data. The construction project data includes project specification data for each of a plurality of projects, and contractor data for each of a plurality of contractors.
The first interface is configured to couple to a project owner electronic database. The first interface is configured to automatically fetch project specification data and contractor data from the project owner database and store fetched project specification data and fetched contractor data in the first database.
The second electronic database is configured to store information about a plurality of deliveries of construction materials to respective construction sites. For each delivery of a delivered construction material, the second database is configured to store: an identification of the delivered construction material; an identification of a source of the delivered construction material; and an identification of a delivery location of the delivered construction material.
The server is configured to automatically store information in the second database as respective construction materials are obtained from respective suppliers and delivered to respective delivery locations. The server is configured to automatically associate each delivery of a delivered construction material to an associated contractor.
The data reconciliation module is configured to use the information in the first and second databases to automatically associate each delivery of a delivered construction material to an associated project in the project specification data of the first database.
The comparator is configured, for each delivery of a delivered construction material, to use the information in the first and second databases to automatically verify the respective delivered construction material complies with material specification requirements in the project specification data of the associated project.
The second interface is configured, for each delivery of a delivered construction material for which the comparator verification succeeds, to automatically store delivery confirmation data for the delivered construction material and the associated contractor.
Optionally, the second interface is configured to couple to the project owner database and automatically store the delivery confirmation data in the project owner database.
Optionally, in any embodiment, the second interface is configured to automatically store the delivery confirmation data in the first database.
Optionally, in any embodiment, the second interface is configured to automatically store the delivery confirmation data in an external database.
Optionally, in any embodiment, the delivery confirmation data includes payment approval data.
Optionally, in any embodiment, the first interface is configured to automatically reformat the fetched project specification data and the fetched contractor data into a common format prior to storing the fetched project specification data and fetched contractor data in the first database.
Optionally, in any embodiment, the first interface is configured to automatically heuristically reformat the fetched project specification data and the fetched contractor data into a common format prior to storing the fetched project specification data and fetched contractor data in the first database.
Optionally, any embodiment includes a third interface. The third interface is configured to couple to an environmental impact database. The environmental impact database stores information about a plurality of construction materials. For each construction material, the environmental impact database stores: (a) an identification of the construction material and (b) an estimated environmental impact of the construction material. The third interface is configured to automatically associate (a) ones of the plurality of construction materials stored in the environmental impact database with (b1) ones of the plurality of projects stored in the first electronic database and/or (b2) ones of the plurality of deliveries of construction materials stored in the second electronic database.
Optionally, in any embodiment, the construction project data includes a computer-aided design model for each of the plurality of projects.
Optionally, in any embodiment, the construction project data includes a building information model for each of the plurality of projects
Optionally, in any embodiment, the server is configured, for each delivery of a delivered construction material, to automatically receive, from a system coupled to a vehicle scale, an identification of the delivered construction material and an identification of a source of the delivered construction material. In such an embodiment, the server is configured to store, as the information in the second database, the identification of the delivered construction material and the identification of the source of the delivered construction material.
Optionally, in any embodiment, the second database is configured to maintain chain-of-custody information for each delivery of construction material of the plurality of deliveries of construction materials. In such an embodiment, the server is configured to update the chain-of-custody information, as custody of construction material in each delivery of construction material changes.
Optionally, in any embodiment, the construction project data of the first electronic database further includes supplier data for each of a plurality of suppliers.
Optionally, in any embodiment, the construction project data of the first electronic database further includes supplier data for each of a plurality of approved suppliers.
Optionally, any embodiment includes a third interface. In such an embodiment, the third interface is configured to receive a change order and, in response to receiving the change order, revise a corresponding portion of the construction project data of the first database.
Optionally, any embodiment includes an electronic rule base. In such an embodiment, the data reconciliation module is configured to use the rule base to automatically associate each delivery of a delivered construction material to an associated project in the project specification data of the first database.
Optionally, any embodiment having an electronic rule base includes an inference engine configured to automatically generate rules for the rule base. In such an embodiment, the inference engine is configured to automatically infer an association between a delivery of a delivered construction material and a project in the project specification data of the first database. The inference may be based at least in part on: proximity of the source of the delivered construction material to a construction site where the delivered construction material is delivered; and/or a match between an identification of the delivered construction material and project specification data of one project of the plurality of projects in the first database; and/or a match of a name in project specification data of one project of the plurality of projects in the first database.
Optionally, any embodiment includes an electronic rule base. In such an embodiment, the data reconciliation module is configured to use the rule base to automatically associate each delivery of a delivered construction material to an associated contractor of the plurality of contractors in the first database.
Optionally, any embodiment having an electronic rule base includes an inference engine configured to automatically generate rules for the rule base. In such an embodiment, the inference engine is configured to automatically infer an association between a delivery of a delivered construction material and a contractor of the plurality of contractors in the first database, based at least in part on: proximity of the source of the delivered construction material to a construction site where the delivered construction material is delivered; and/or a match between an identification of the delivered construction material and project specification data of one project of the plurality of projects in the first database; and/or a match of a name in project specification data of one project of the plurality of projects in the first database.
Optionally, any embodiment includes an inference engine configured to automatically infer an association between a delivery of a delivered construction material and a project in the project specification data of the first database.
Optionally, in any embodiment having an inference engine, the inference engine is configured to automatically infer the association based at least in part on: proximity of the source of the delivered construction material to a construction site where the delivered construction material is delivered; and/or a match between an identification of the delivered construction material and project specification data of one project of the plurality of projects in the first database; and/or a match of a name in project specification data of one project of the plurality of projects in the first database.
Optionally, any embodiment includes an inference engine configured to automatically infer an association between a delivery of a delivered construction material and a contractor of the plurality of contractors in the first database.
Optionally, any embodiment having an inference engine, the inference engine is configured to automatically infer the association based at least in part on: proximity of the source of the delivered construction material to a construction site where the delivered construction material is delivered; and/or a match between an identification of the delivered construction material and project specification data of one project of the plurality of projects in the first database; and/or a match of a name in project specification data of one project of the plurality of projects in the first database.
Optionally, any embodiment includes a security module configured to control access by each contractor of the plurality of contractors to individual project specification data items stored in the first database.
Optionally, in any embodiment, the first database includes a blockchain.
Optionally, in any embodiment in which the first database includes a blockchain, the blockchain is configured to reward miners of the blockchain with a cryptocurrency.
Another embodiment of the present invention provides a database. The database is configured to store construction project data. The construction project data includes project specification data for each of a plurality of projects and contractor data for each of a plurality of contractors. The specification data includes project requirements specified by respective project owners.
The database is configured to control access by each contractor of the plurality of contractors to individual project specification data items stored in the database.
The database is configured to store data indicating commitments by ones of the plurality of contractors to meet ones of the project requirements.
The database is configured to store data indicating fulfillment by ones of the plurality of contractors of ones of the commitments. Each fulfillment includes a respective delivery of construction material to a respective construction site. For each delivery of a delivered construction material, the database is configured to store: an identification of the delivered construction material; an identification of a source of the delivered construction material; and an identification of a delivery location of the delivered construction material.
Optionally, in any such database, the project specification data includes building information model (BIM) data for a respective project.
Optionally, in any such database, the database is configured to store change information in response to inputs. Each such input indicates a change to a corresponding project requirement.
Optionally, in any such database, the database includes a blockchain.
Optionally, in any such database that includes a blockchain, the blockchain is configured to reward miners of the blockchain with a cryptocurrency.
The invention will be more fully understood by referring to the following Detailed Description of Specific Embodiments in conjunction with the Drawings, of which:
Although some participants in construction projects maintain all or most of their information in electronic databases, some participants, particularly suppliers and haulers of construction materials, rely at least in part on paper records. Thus, the construction industry needs an intuitive and streamlined system and method to accelerate creation and maintenance of digital connections between industry participants involved in one or more projects. Furthermore, the industry needs a system and method that automatically creates digital relationship backbones to allow construction industry participants to effectively digitize their operations, without undue burden and change management.
Available electronic systems primarily leave the burden of connecting industry participants working on a project to suppliers of construction materials. A supplier is generally the original source of construction material data. Thus, for a new construction project, the supplier typically initiates an electronic process by inviting other project participants to access the supplier's system. With permission granted by the supplier, the other participants can view information about construction materials supplied by the supplier to various projects. However, this workflow is inefficient, because it requires contractors and subcontractors to register in each supplier's system for every new project. A project typically involves many suppliers, each with its own system.
Because a contractor must fulfil requirements specified in a project owner's database before the project owner will pay the contractor for construction materials delivered to a construction site or construction activity associated with the construction materials, the contractor must also access the project owner's database. However, as noted, the databases maintained by suppliers, contractors, subcontractors, and project owners are typically incompatible. Embodiments of the present invention provide systems that automatically reconcile differences among data stored by various parties involved in a construction project. Other embodiments provide databases that facilitate such reconciliation.
Construction MaterialsConstruction, service, and maintenance materials, such as ready-mix concrete, aggregates, structural steel beams, hot-mix asphalt (“HMA”), timber, salt, etc., (collectively herein referred to as “construction materials”) are used in a variety of construction, service, and maintenance projects (collectively herein referred to as “construction projects”), such as roads, bridges, tunnels, and buildings. Typically, these construction materials are brought to job sites via trucks that load at supplier facilities and unload at the job sites. Frequently, inspectors inspect the construction materials as they arrive at the job sites, such as to ensure the construction materials meet specified quality, quantity, and/or timeliness standards. If a truck load of construction material is accepted by an inspector, custody of the load of construction material transfers from the supplier to an owner of the project, such as a municipality or government agency, such as a department of transportation (DOT), or to a general contractor building the project, typically on behalf of the owner.
Conventionally, a chain of custody of each load is maintained using paper records, often multi-part forms. When a truck is loaded, and typically weighed, a paper load ticket is issued by the supplier. The supplier keeps one copy of the load ticket. Another copy or two of the load ticket is given to a driver of the truck that hauls the load. When the truck arrives at the job site, one of those copies is given to an inspector, who may make notes on the copy, such as regarding quality of the delivered construction material.
Conventionally, the received paper records are used to manually correlate the load to the supplier and then ultimately to the contractor and/or one or more subcontractors who may have had contractual responsibility to supply the load to the project. Once the project owner connects the chain of custody to the contractor, the contractor may be paid for the delivery of, or construction activity associated with, that load. Optionally or alternatively, a chain of custody that ends with custody being transferred to a project owner can be used as backing for a payment schedule that had been agreed upon by the parties. For example, a paving contractor is paid to pave a surface, which includes having appropriate material(s) delivered to a construction site and applying those materials to the surface being paved. In some cases, multiple truckloads of construction material(s) are required for a single construction activity. However, for simplicity of explanation, each delivery referenced herein is assumed to be a single truckload.
The contractor must then attribute the flow of work for that load to one or more subcontractors and ultimately to the supplier of the material load, so that the contractor can pay each entity in the chain for that construction activity or that delivery of the load to the project. This is a complex, lengthy, and error prone process even when things run smoothly, but the difficulties may be greatly exacerbated when there is incorrect or incomplete information on the ticket with respect to, for example, the parties involved or if a change order changed the original contract requirements between the project owner and the contractor.
Some efforts have been made to facilitate calculating the environmental impact of a construction project. For example, an environmental product declaration (EPD) is a verified report designed to quantify the environmental lifecycle impact of an associated product in a standardized manner. EPDs are sometimes used within the construction materials industry in the United States and other jurisdictions to conform to a “cradle-to-gate” life cycle assessment methodology. These reports cover raw material supply (upstream processes) (phase A1), transportation to manufacturing site (phase A2), and core manufacturing processes of materials (phase A3), such as asphalt and concrete. An EPD does not, however, include the environmental lifecycle impact of an associated product during other times, such as construction (ex., use of the product to build a road or parking lot), use of the built project (ex., use of the road or parking lot), maintenance and rehabilitation of the built project, and end of life (ex., demolition and possible recycling of the road or parking lot material) (phases A4, A5, B1-B7, and C1-C4).
An EPD quantifies the environmental impact to produce a unit of a product, such as one short ton of asphalt. For example, an EPD for asphalt may list a number of megajoules (MJ) of renewable primary energy, excluding renewable primary energy resources, used as raw materials (PERE), a number of cubic meters of net fresh water used, and an amount of global warming air (kilograms (kg) of carbon dioxide equivalent) produced, in each of phases A1, A2 and A3. Most EPDs are specific to a specific product made at a specific plant. However, an EPD can also be generated based on an average across a type of product over multiple producers.
EPDs are increasingly being demanded by stakeholders within the construction ecosystem as currently they are the single most trusted option to quantify environmental impact of a project. Unfortunately, EPDs are only able to quantify a portion of a project's environmental impact, and they quite often rely on input values that are formed from national averages.
Systems and methods for capturing, analyzing, and communicating environmental lifecycle impact of construction materials used in a construction project are described in U.S. patent application Ser. No. 17/565,620 (“Construction Project Environmental Impact Decision Support System,” the “'620 application”), the entire contents of which are hereby incorporated by reference herein, for all purposes. As described in the '620 application, historical information about actual hauls of construction materials in previous projects may be used to improve standard estimates of environmental impacts of construction materials specified for an upcoming construction project to yield an improved estimate of environmental impact of the upcoming construction project.
Construction Project Database Reconciliation SystemAs noted, embodiments of the present invention provide systems that automatically reconcile differences among data stored by various parties involved in a construction project. Other embodiments provide databases that facilitate such automatic reconciliation.
The first database 203 may, for example, be or include a computer-aided design (CAD) model for each of the plurality of projects. Optionally or alternatively, the first database 203 may be or include building information model (BIM) data for each of the plurality of projects. The terms “building information model” and “building information modeling” have their ordinary meanings as used by practitioners in the art, for example as defined in ISO 19650-1:2018.
Each project's project specification data includes information about construction materials to be used in the project's construction, as well as information about where the construction materials are to be used. For example, the information about the construction materials specifies material type, quantity, quality, etc. For a road construction project, for example, the information about the construction materials may include information about gravel, crushed stone, and/or other materials to be used to prepare a base course, as well as information about pavement, such as such as hot-mix asphalt, concrete, or another suitable material, to be laid down on top of the base course.
The information about where the materials are to be used may include x, y, and z co-ordinates or their equivalents. Continuing the road construction project example, the location information may specify an order in which materials of the base course are to be laid down, as well as a number and respective thicknesses of each layer of base course and pavement.
The first database 203 is also configured to store contractor data for each of a plurality of contractors, such as which contractors have won bids on various aspects of various projects. The contractor data identifies individual contractors and which portions of each project the respective contractors have been contracted to perform. For example, “Acme Construction” may be the successful bidder to remove and replace the wearing course of existing asphalt roadway by first milling up the old pavement and then placing a layer of new hot mix asphalt pavement on the base course to economically extend the design life of the roadway. The contractor identity may be represented in any suitable form, such as text name, unique entity identifier (UEI), D-U-N-S number, universally unique identifier (UUID), globally unique identifier (GUID), or an arbitrary identifier. D-U-N-S is a registered trademark of Dun & Bradstreet, Inc.
The construction project data of the first electronic database 203 may also include supplier data for each of a plurality of suppliers. The construction project data of the first electronic database 203 may also include supplier data for each of a plurality of approved suppliers.
The first database 203 may also be configured to store data about employees or agents of project owners, for example inspectors who will inspect loads of construction materials delivered to construction sites. This data may include information associating each inspector with a respective project, construction site, type of material to be inspected, type of contractor to be inspected, and/or geographic location where the inspector is expected to operate. This data may also include information day and time schedules of the inspectors, particularly if a given inspector is expected to operate at different locations or different projects at different times.
A first interface 206 is configured to couple to a project owner electronic database 209 and automatically fetch project specification data and contractor data from the project owner database 209 and store fetched project specification data and fetched contractor data in the first database 203. The first interface 206 may automatically fetch the data about the employees or agents of the project owners from the project owner electronic database 209 and automatically store the fetched data in the first database 203. The project owner database 209 is typically, but not necessarily, separate from the first database 203. However, in some cases, the project owner database 209 and the first database 203 are co-located or occupy a common datastore.
The project owner database 209 is typically, but not necessarily, maintained by a department of transportation or other project owner, such as a building owner. The data in the project owner database 209 is not necessarily stored in the same format as the data in the first database 203. Typically, the data in the project owner database 209 is stored in a format different from the format of the data in the first database 203. For example, at least one department of transportation has attempted to mandate a data format to be used by all contractors. However, this effort has met with little success and much resistance from construction industry participants, because the participants wish to keep their data in their own respective formats.
If necessary, the first interface 206 is configured to automatically reformat the fetched project specification data and the fetched contractor data into a common format prior to storing the fetched, reformatted project specification data and fetched, reformatted contractor data in the first database 203. In some embodiments, the first interface 206 is configured to automatically heuristically reformat the fetched project specification data and the fetched contractor data into a common format prior to storing the fetched project specification data and fetched contractor data in the first database. Reformatting of fetched data is described in more detail herein.
A second electronic database 212 is configured to store information about a plurality of deliveries of construction materials to respective construction sites. For each delivery of a delivered construction material, the second database 212 is configured to store: an identification of the delivered construction material, an identification of a source of the delivered construction material, and an identification of a delivery location of the delivered construction material.
Systems and methods for constructing, populating, and maintaining the second database 212 are described in U.S. Pat. No. 11,210,635 (“Construction Material Digital Chain of Custody System,” the “'635 patent”) and U.S. patent application Ser. No. 17/513,745 (“Construction Material Digital Chain of Custody System,” the “'745 application”), the entire contents of each of which are hereby incorporated by reference herein, for all purposes. A drawing from the '635 patent is reproduced herein as
The database 102 described in the '635 patent and the '745 application may be used as the second database 212 described herein. Optionally or alternatively, the second database 212 described herein may be a copy or subset of the database 102 described in the '635 patent and the '745 application.
As noted in the '635 patent and the '745 application, the database 212 is configured to store electronic load tickets 106. Each load electronic load ticket 106 is a record in the database 102 and is associated with a respective haul of construction materials by a vehicle 108. Each electronic load ticket 106 includes respective initial load data related to the haul, including custody data. A server 104 maintains the electronic database 102. The server 104 updates custody data about each haul of construction materials by updating the respective electronic load tickets 106. For example, after a haul of construction material is accepted by an inspector, the server 104 may update the corresponding electronic load ticket 106 to reflect a change in custody of the construction material, such as from the supplier to the project owner.
Returning to
Furthermore, the second database 212 may be configured to maintain chain-of-custody information for each delivery of construction material of the plurality of deliveries of construction materials. The server 215 may be configured to update the chain-of-custody information, as custody of construction material in each delivery of construction material changes.
Automatic AssociationThe systems described in the '635 patent and the '745 application do not necessarily associate deliveries to contractors. However, the server 215 described herein is configured to automatically associate each delivery of a delivered construction material to an associated contractor, in particular, the contractor who is contractually responsible for the delivery of the construction material and who is entitled to be paid, if the delivery and/or associated construction activity is successfully completed. In general, each delivery of a delivered construction material has an associated load ticket. For simplicity of explanation, a delivery of a delivered construction material is sometimes referred to herein by its associated load ticket.
In some cases, load tickets sufficiently identify contractors, in which cases the server 215 can use the identifying information in the load tickets to associate the corresponding deliveries of the delivered construction materials to corresponding contractors and store corresponding association data in the second database 212. However, in other cases, load tickets lack direct contractor identifying information. In these cases, the server 215 automatically infers associations between the deliveries of the delivered construction materials and the contractors.
Associations between deliveries of delivered construction materials and contractors may be inferred in any suitable manner. For example, one or more pieces of evidence may be used to infer a candidate association. One candidate association may be selected from among a plurality of competing candidate associations, such as based on confidence values calculated for the respective candidate associations. In general, data available from a load ticket, optionally with data available in the first and/or second databases 203 and/or 212, may be used as evidence in support of, or against, a given candidate association.
Historical information about past deliveries may be used to infer a candidate association. For example, if a contractor identification listed on a load ticket does not match any contractor associated with a current project in the first or second database 203 or 212, but the contractor identification from the load ticket does match a contractor identification associated with a past project in the first or second database 203 or 212, and the first or second database 203 or 212 stores an alias for the contractor in relation to the past project, and the alias matches a contractor associated with a present project, the alias may be taken as a candidate contractor inference.
The alias may, for example, reflect a change in legal name of an entity, or a common misspelling of the name of the entity, or a nickname of the entity. The alias may include an alternative means of identifying the contractor, such as a contractor identification number, UEI, D-U-N-S number, or the like. The alias may have been previously manually entered into one of the databases 203 or 212, or the alias may have been previously automatically inferred and stored. Optionally or alternatively, the server 215 or an inference engine 224 (described in detail herein) may automatically search an external database, such as the U.S. Government System for Award Management (SAM.gov) or Dun & Bradstreet D-U-N-S number lookup, or consult an external search engine, such as Google, in an effort to match the contractor identifier in the load ticket to a contractor identified in the first or second database 203 and/or 212. Such an external system is indicated at 225.
Optionally or alternatively, a chain of lookups and/or inferences may be followed to reach a candidate or final association, or to gather evidence for or against an inference. For example, a load ticket for a particular material, such as concrete, may identify a particular project, without directly identifying a contractor. If, in the first and/or second database 203 and/or 212, the project data for the identified project lists only one contractor that is to deliver the particular material, the contractor associated with the load ticket, and therefore the delivered construction material, may be inferred to be the contractor identified in the project data.
If a contractor inference is drawn, and the load ticket contains an otherwise unusable contractor identifier, the unusable contractor identifier may be stored in the second database 212 as an alias for the contractor. Thus, as more construction materials and construction projects are handled, the system 200 can automatically develop a progressively better ability to draw inferences.
The system 200 also includes a data reconciliation module 227. The data reconciliation module 227 is configured to use the information in the first and second databases 203 and 212 to automatically associate each delivery of a delivered construction material to an associated project in the project specification data of the first database 203. As with associating a delivery of delivered construction material to a contractor, if a load ticket sufficiently identifies a project, the project identification information in the load ticket may be used to associate the delivery to the project. On the other hand, if the load ticket lacks direct project identifying information, the system automatically infers the project identification, in a manner similar to that described with reference to the server 215.
For example, if a load ticket includes a textual project name or numerical project identifier, but the first and second databases 203 and 212 do not store a project indexed by the included textual project name or numerical project identifier, the reconciliation module 227 may search the databases 203 and 212 for an alias project identifier that matches a current project and is associated with a textual project name or numerical project identifier in the load ticket. As with contractor aliases, project aliases may be previously manually entered and/or automatically added to the database 203 and/or 212 in response to inferences that were automatically drawn.
Known characteristics and/or limitations of construction materials may be used to automatically infer associations between deliveries of construction materials and construction projects. For example, some construction materials, such as concrete, must be delivered within certain timeframes or distances. The American Concrete Institute recommends concrete be discharged from a delivery truck within 1.5 hours of being batched, or 300 revolutions of the truck, whichever occurs first. Thus, concrete for a project generally cannot originate more than 1.5 travel hours, or the equivalent to 300 revolutions, from the project's construction site.
Given a time of delivery and local road and traffic conditions between the construction site where a given load of concrete is delivered and candidate concrete suppliers, the reconciliation module 227 automatically calculates a maximum distance the load of concrete could have traveled from a supplier. If only one supplier lies within the maximum distance, the reconciliation module 227 may infer the supplier supplied the concrete. If multiple suppliers lie within the maximum distance, the reconciliation module 227 can eliminate other candidate suppliers that lie beyond the maximum distance, from it inferences.
If multiple viable candidate suppliers remain, the reconciliation module 227 may use additional conditions to narrow the pool of candidate suppliers to a single choice or a best choice. For example, the supplier closest to the construction project site is more likely to have supplied the concrete than a more distant supplier.
In another example, if the reconciliation module 227 detects that concrete deliveries from a given supplier generally occur at approximately regular intervals, but a particular concrete delivery occurred at an odd interval, the reconciliation module 227 may use the odd interval delivery as evidence against inferring that the particular delivery originated with the given supplier. On the other hand, if a particular concrete delivery occurred according to the regular intervals, and no other concrete delivery from the given supplier occurred during the same interval, the reconciliation module 227 may use the regular interval delivery as evidence in favor of inferring that the particular delivery originated with the given supplier.
Furthermore, with sufficient sample points, the reconciliation module 227 may draw inferences that vary by location, project type, construction material type, contractor, local modus operandi, or other factors. For example, roads in and around Boston are generally narrower and more congested than roads in and around St. Louis and, therefore, in order to meet maximum travel times, concrete suppliers may need to be closer to respective construction sites in Boston than in St. Louis.
Even if a construction material, such as gravel, would not spoil after a predetermined amount of travel time, economic considerations, such as fuel and labor costs, may put practical limits on travel times or distances that the reconciliation module 227 may exploit. These limits may be manually entered and/or automatically inferred from past project data.
Of course, these limits may vary by geography. For example, although potential sources of crushed stone, sand, and gravel are distributed across most of the conterminous United States, they occur in very limited supply in some regions, such as coastal plain and Mississippi embayment, Colorado plateau, Wyoming basin, glaciated midwest, high plains, and the non-glaciated northern plains. Thus, travel times or distances from suppliers in these regions may be greater than in other areas of the United States. Again, these limits may be manually entered and/or automatically inferred from past project data.
A geographic location, to which a load of construction material is delivered, may be used to automatically infer a project for which the construction material is delivered. Geographical information manually entered, such as by an inspector at a construction site, or automatically collected, such as by a global positioning system (GPS) receiver, may be used to geolocate a delivery of construction material. The construction project data stored in the first database 203 includes the geographic location of the project, thereby enabling the reconciliation module 227 to compare locations of delivered construction materials and locations of projects to identify to which project a given load of construction material is delivered. As noted, once the project is inferred, the project identity may be used to infer other data, such as the supplier and/or contractor associated with the load.
Information in the first database 203 about which inspectors are expected to operate at various projects, locations, times, etc. may be used to infer information about deliveries of construction materials. For example, if a given inspector approves a given delivery of a construction material, and the inspector is expected to operate at a particular project, the reconciliation module 227 may infer the given delivery is of a particular construction material, or the given delivery is associated with the particular project, even if nothing else is known about the delivery. The time and/or date of the delivery, in conjunction with the inspector's schedule, may be used to resolve ambiguity, such as if the inspector is expected to operate at different projects at different times. The inferred project may be used to draw further inferences, such as identity of an associated contractor.
Other aspects of the inspector's role may be used to resolve ambiguities. For example, if the inspector is expected to inspect only concrete and structural steel, deliveries inspected by the inspector can be assumed to be either concrete or structural steel, and not asphalt. In general, an inference drawn based on information about an inspector who inspected a delivery of construction material should have a relatively high confidence value, for example in contrast with an inference drawn based on distance from a construction site to two or more possible gravel suppliers.
Descriptions and examples of inferences drawn by the server 215 also apply to the reconciliation module 227, and vice versa, mutatis mutandis.
Specification ComparatorOnce other information about a delivery of delivered construction material is ascertained, either directly from a load ticket or inferred, the project and contractor in the first database 203 are known. A comparator 230 then automatically verifies the delivered construction material complies with material specification requirements in the project specification data of the associated project. The comparator 230 is configured, for each delivery of a delivered construction material, to use the information in the first and second databases 203 and 212 to automatically verify the respective delivered construction material complies with material specification requirements in the project specification data of the associated project.
The information in the second database (construction material delivery database) 212 identifies the construction material that was delivered and the associated contractor. The comparator 230 can then fetch a corresponding item from the project data. For example, if the first database 203 includes BIM data, the comparator 230 can fetch a BIM item that corresponds to the delivered construction material, for example based on location where the construction material was delivered, time of the delivery, project identifier, and contractor associated with the delivery. The delivery location can be a 3-dimensional location. For example, if the delivered construction material is a component of a road, the height (z component of the location) correlates with a layer of the base course or pavement.
The comparator 230 can use this information to identify the BIM item or other item in the first database 203 that corresponds to the delivered construction material. The comparator 230 then compares requirements of the identified item to a description of the delivered construction material to ascertain whether the delivered construction material meets the requirements. For example, if the first database 203 item specifies pavement, and the delivered construction material is hot-mix asphalt or concrete, the comparator 230 may determine that the delivered construction material meets the requirement. On the other hand, if the first database 203 item specifies asphalt, and the delivered construction material is concrete, the comparator 230 may determine that the delivered construction material does not meet the requirement.
A second interface 233 is configured, for each delivery of a delivered construction material for which the comparator 230 verification succeeds, to automatically store delivery confirmation data for the delivered construction material and the associated contractor. The second interface 233 may be configured to couple to the project owner database 209. The second interface 233 may be configured to automatically store the delivery confirmation data in the project owner database 209, in the first database 203, and/or in an external database (not shown). The delivery confirmation data may include payment approval data. Thus, once the comparator 230 verifies that delivered constructions material meets the requirements of the project, the contractor can be paid.
As noted, the first interface 206 may be configured to automatically reformat the fetched project specification data and the fetched contractor data into a common format prior to storing the fetched project specification data and fetched contractor data in the first database 203. This reformatting may include storing manually entered and/or previously automatically inferred aliases. The first interface 206 may be configured to automatically reformat the fetched project specification data and/or the fetched contractor data into an openBIM format, such as a well-known vendor-neutral format, such as IFC, BCF, COBie, CityGML, or gbXML.
Optionally, the system 200 includes a third interface 234 configured to couple to an environmental impact database 235. The environmental impact database 235 stores information about a plurality of construction materials. For each construction material, the environmental impact database 235 stores: (a) an identification of the construction material and (b) an estimated environmental impact of the construction material. Implementation of such an environmental impact database 235 is described in the '620 application, where it is referred to as a “first database.”
The third interface 234 is configured to associate (a) ones of the plurality of construction materials stored in the environmental impact database 235 with (b1) ones of the plurality of projects stored in the first electronic database 203 and/or (b2) ones of the plurality of deliveries of construction materials stored in the second electronic database 212.
An environmental impact of a load of construction material may be used to automatically infer a supplier of the construction material, a project for which the construction material is delivered, and/or a contractor for whom the construction material is delivered. For example, a supplier may annotate a load ticket to identify the environmental impact of the construction material, or an inspector may identify the material and annotate the load ticket with the environmental impact of the construction material. The server 215, the reconciliation module 227, and/or the inference engine 224 may use the environmental impact of the load of construction material as evidence that the load of construction material is or is not associated with a particular project, supplier, and/or contractor, for example based on whether the first or second database 203 or 212 lists project, supplier, and/or contractor who or that is expected to have the noted environmental impact, or who or that is expected to receive construction material that has the noted environmental impact.
EPDs may be parts of, or linked to, source records for construction materials and can, therefore, be used to facilitate identifying when a load of construction material has been delivered in fulfillment of a contractual obligation. For example, an EPD logically links a producer and a plant to a type of construction material.
Furthermore, an EPD, or information from an EPD, may be a prerequisite before payment for a load of construction material is authorized. In other words, an EPD or information from an EPD may be a contractual requirement, before payment is authorized. Associating deliveries of loads of construction materials with respective EPDs documents satisfaction of such contractual requirements.
Optionally, the system 200 includes an electronic rule base 236. The data reconciliation module 227 may be configured to use the rule base 236 to automatically associate each delivery of a delivered construction material to an associated project in the project specification data of the first database 203. The rule base 236 may store rules, according to which inferences may be drawn. For example, concrete for a project cannot originate more than 1.5 travel hours, or the equivalent to 300 revolutions, from the project's construction site. Other examples of rules are described herein, for example with respect to the server 215 and with respect to the reconciliation module 227.
Optionally, the system 200 includes an inference engine 224. The inference engine 224 may be configured to automatically generate rules for the rule base 236. The inference engine 224 may be configured to automatically infer an association between a delivery of a delivered construction material and a project in the project specification data of the first database 203. The inference may be drawn based at least in part on proximity of the source of the delivered construction material to a construction site where the delivered construction material is delivered. For example, as described with respect to the reconciliation module 227, the closest supplier to a construction site is more likely to have delivered the construction material than a more distant supplier, particularly if the construction material must be used within a relatively short period of time after being loaded at the supplier site.
The inference may be drawn based at least in part on a match between an identification of the delivered construction material and project specification data of one project of the plurality of projects in the first database. For example, if a particular construction material is delivered, only construction projects that require that construction material at about the current time need be considered. For example, if two road construction projects are currently under way, and the base course of only one of these projects has been completed and pavement is now being laid there, then a delivery of gravel, sand, or crushed stone is likely associated with the other of the two projects.
The inference may be drawn based at least in part on a match of a name in project specification data of one project of the plurality of projects in the first database. For example, a load ticket may indicate a project name (ex., “Main Street Bridge”) or a project owner (ex., “Pennsylvania DOT”) rather than an official identifier of a project, as stored in the first database 203. Nevertheless, the first or second database 203 or 212 may store such a nickname or alias of the project.
The inference may be drawn based at least in part on a combination of these bases.
The data reconciliation module 227 may be configured to use the rule base 236 to automatically associate each delivery of a delivered construction material to an associated contractor of the plurality of contractors in the first database 203. The inference engine 224 may be configured to automatically infer an association between a delivery of a delivered construction material and a contractor of the plurality of contractors in the first database 203. For example, if a contractor is known to be associated with a given project due to other deliveries for that contractor to that project, as reflected by entries in the second database 212, then a delivery to the given project may be associated with the contractor, particularly if the delivered construction material matches a phase of the construction project that the contractor is responsible for and that is currently under way, as reflected in the first database 203.
The inference may be drawn based at least in part on proximity of the source of the delivered construction material to a construction site where the delivered construction material is delivered. The inference may be drawn based at least in part on a match between an identification of the delivered construction material and project specification data of one project of the plurality of projects in the first database. The inference may be drawn based at least in part on a match of a name in project specification data of one project of the plurality of projects in the first database. The inference may be drawn based at least in part on a combination of these bases.
The inference engine 224 may be configured to automatically infer an association between a delivery of a delivered construction material and a project in the project specification data of the first database 203. The inference engine 224 may be configured to automatically infer the association based at least in part on proximity of the source of the delivered construction material to a construction site where the delivered construction material is delivered. The inference engine 224 may be configured to automatically infer the association based at least in part on a match between an identification of the delivered construction material and project specification data of one project of the plurality of projects in the first database. The inference engine 224 may be configured to automatically infer the association based at least in part on a match of a name in project specification data of one project of the plurality of projects in the first database. The inference engine 224 may be configured to automatically infer the association based at least in part on a combination of these bases.
The inference engine 224 may be configured to automatically infer an association between a delivery of a delivered construction material and a contractor of the plurality of contractors in the first database 203. The inference engine 224 may be configured to automatically infer the association based at least in part on proximity of the source of the delivered construction material to a construction site where the delivered construction material is delivered. The inference engine 224 may be configured to automatically infer the association based at least in part on a match between an identification of the delivered construction material and project specification data of one project of the plurality of projects in the first database. The inference engine 224 may be configured to automatically infer the association based at least in part on a match of a name in project specification data of one project of the plurality of projects in the first database. The inference engine 224 may be configured to automatically infer the association based at least in part on a combination of these bases.
Descriptions and examples of inferences drawn by the inference engine 224 also apply to the server 215 and to the reconciliation module 227, and vice versa, mutatis mutandis.
Essentially, the project specification data stored in the first database 203 is equivalent to agreements in a contract between the project owner and respective contractors, in that the project specifications specify minimum requirements (material, quantity, quality, timeliness, etc.) of construction materials to be delivered by the contractors. If the first database 203 is or includes BIM data or similar set of information, items in the first database 203 precisely identify each construction material, or class of material, to be used and where and when it is to be used. Thus, these specifications are tantamount to contract provisions and express initial expectations of the parties. Indeed, some departments of transportation are moving toward using a BIM or similar structure in place of a contract.
As noted, the first and/or second database 203 and/or 212 may be manually seeded with data, such as contractor or project aliases, construction material travel time or distance limits, and the like. A third interface 239 may be used to enter such seed data. Thus, the third interface 239 may be used to populate or augment the first database 203 with project specifications which, as noted, are tantamount to contract provisions. Similarly, the third interface 239 may be used to enter project change orders, which are nearly inevitably needed in all but the smallest of projects. Thus, the third interface 239 may be configured to receive a change order and, in response to receiving the change order, revise a corresponding portion of the construction project data of the first database.
Optionally or alternatively, the first and/or second database 203 and/or 212 may initially be empty and automatically filled as projects progress and construction materials are delivered to construction project sites.
Optionally, a contractor may select suppliers and/or subcontractors before a project begins, and the contractor may pre-populate the first database 203 with information about the selected suppliers and/or subcontractors, including associations therebetween and between the project and the selected suppliers and/or subcontractors. Furthermore, a contractor may inject test load tickets into the system 200. Each test load ticket is similar to a load ticket, but the test load ticket does not represent an actual delivery of construction material. Nevertheless, the system 200 processes the test tickets and can make inferences and build rules, as described herein, however any delivery confirmation data stored by the second interface 233 is marked to indicate the confirmation is for a test delivery and, therefore, no actual payment is approved. These test load tickets may, therefore, be used to prime the first and/or second database 203 and/or 212 for actual load tickets for a project and/or test accuracy of inferences drawn by components of the system 200. As a result of these tests, if inadequate or erroneous behavior is detected, business logic in the inference engine 224, the server 215, and/or other components of the system 200 may be corrected or enhanced.
Since the first and/or second databases 203 and/or 212 may be legitimately accessed by many entities, but these entities typically have legitimate reason to access only respective subsets of the data in the databases 203 and/or 212, a security module 242 may be included to limit access by each entity to respective specific data in the databases 203 and/or 212. Some access may be limited to read-only, whereas other data may be accessible as read-write. For example, a contractor may be permitted to read, but not write, material specifications, whereas the contractor may be permitted to write data representative of deliveries the contractor has made. Thus, the security module 242 may be configured to control access by each contractor of the plurality of contractors to individual project specification data items stored in the first database.
Optionally, the first or second database 203 or 212 may include or be implemented as a public ledger (blockchain). A blockchain is a growing list of records, called blocks, that are linked together using cryptography. Each block contains a cryptographic hash of the previous block, a timestamp, and transaction data, generally represented as a Merkle tree. The timestamp proves that the transaction data existed when the block was published to get into its hash. As blocks each contain information about the block previous to it, they form a chain, with each additional block reinforcing the ones before it. Therefore, blockchains are resistant to modification of their data because once recorded, the data in any given block cannot be altered retroactively without altering all subsequent blocks.
A blockchain is typically managed by a peer-to-peer network for use as a publicly distributed ledger, where nodes collectively adhere to a protocol to communicate and validate new blocks. Although blockchain records are not unalterable, as forks are possible, blockchains may be considered secure by design and exemplify a distributed computing system with high Byzantine fault tolerance.
Typically, the safety, integrity and balance of such ledgers is maintained by a community of mutually distrustful parties. These parties use their computers to help validate and timestamp transactions, adding them to the ledger in accordance with a particular timestamping scheme. Transactions may be validated by holders of an associated cryptocurrency, sometimes grouped together in stake pools. All such parties and holders are collectively referred to as “miners.”
The construction industry is characterized by a high level of mistrust among its participants. A blockchain-implemented first or second database 203 or 212 enables such participants to enter their own respective data and trust that data entered by others cannot be surreptitiously altered. Furthermore, an associated cryptocurrency provides an incentive for miners to validate the transactions. Thus, the blockchain may be configured to reward miners of the blockchain with a cryptocurrency.
As noted, as more construction materials and construction projects are handled, the system 200 can automatically develop a progressively better ability to draw inferences, for example because the rule base 236 is automatically enlarged over time by the inference engine 224.
The disclosure and the various features and advantageous details thereof are explained more fully with reference to the non-limiting embodiments and examples that are described and/or illustrated in the accompanying drawings and detailed in the following description. It should be noted that the features illustrated in the drawings are not necessarily drawn to scale, and features of one embodiment may be employed with other embodiments as the skilled artisan would recognize, even if not explicitly stated herein. Descriptions of well-known components and processing techniques may be omitted, so as to not unnecessarily obscure the embodiments of the disclosure. The examples used herein are intended merely to facilitate an understanding of ways in which the disclosure may be practiced and to further enable those of skill in the art to practice the embodiments of the disclosure. Accordingly, the examples and embodiments herein should not be construed as limiting the scope of the disclosure. Moreover, it is noted that like reference numerals represent similar parts throughout the several views of the drawings.
While the invention is described through the above-described exemplary embodiments, modifications to, and variations of, the illustrated embodiments may be made without departing from the inventive concepts disclosed herein. Unless otherwise indicated in context, or would be understood by one of ordinary skill in the art, terms such as “about” mean within ±20%.
As used herein, including in the claims, the term “and/or,” used in connection with a list of items, means one or more of the items in the list, i.e., at least one of the items in the list, but not necessarily all the items in the list. As used herein, including in the claims, the term “or,” used in connection with a list of items, means one or more of the items in the list, i.e., at least one of the items in the list, but not necessarily all the items in the list. “Or” does not mean “exclusive or.”
As used herein, including in the claims, an element described as being configured to perform an operation “or” another operation is met by an element that is configured to perform only one of the two operations. That is, the element need not be configured to operate in one mode in which the element performs one of the operations, and in another mode in which the element performs the other operation. The element may, however, but need not, be configured to perform more than one of the operations.
Although aspects of embodiments may be described with reference to flowcharts and/or block diagrams, functions, operations, decisions, etc. of all or a portion of each block, or a combination of blocks, may be combined, separated into separate operations or performed in other orders. References to a “module,” “operation,” “step” and similar terms are for convenience and not intended to limit their implementation. All or a portion of each block, module, operation, step or combination thereof may be implemented as computer program instructions (such as software), hardware (such as combinatorial logic, Application Specific Integrated Circuits (ASICs), Field-Programmable Gate Arrays (FPGAs), processor or other hardware), firmware or combinations thereof.
For example, the server 215, inference engine 224, reconciliation module 227, first, second, and third interfaces 206, 233, and 239, the comparator 230, and the security module 242 may be implemented by a suitable processor executing instructions stored in a suitable memory.
Each processor may be a general-purpose processor, such as a central processing unit (CPU), a graphic processing unit (GPU), digital signal processor (DSP), a special purpose processor, etc., as appropriate, or combination thereof.
The memory may be random access memory (RAM), read-only memory (ROM), non-volatile memory (NVM), non-volatile random access memory (NVRAM), flash memory or any other memory, or combination thereof, suitable for storing control software or other instructions and data. Instructions defining the functions of the present invention may be delivered to a processor in many forms, including, but not limited to, information permanently stored on tangible non-transitory non-writable storage media (e.g., read-only memory devices within a computer, such as ROM, or devices readable by a computer I/O attachment, such as CD-ROM or DVD disks), information alterably stored on tangible non-transitory writable storage media (e.g., floppy disks, removable flash memory and hard drives) or information conveyed to a computer through a communication medium, including wired or wireless computer networks. Moreover, while embodiments may be described in connection with various illustrative data structures, database schemas and the like, systems may be embodied using a variety of data structures, schemas, etc.
Disclosed aspects, or portions thereof, may be combined in ways not listed herein and/or not explicitly claimed. In addition, embodiments disclosed herein may be suitably practiced, absent any element that is not specifically disclosed herein. Accordingly, the invention should not be viewed as being limited to the disclosed embodiments.
Claims
1. A database reconciliation system, the system comprising:
- a first electronic database configured to store construction project data, including: project specification data for each of a plurality of projects; and contractor data for each of a plurality of contractors;
- a first interface configured to couple to a project owner electronic database and automatically fetch project specification data and contractor data from the project owner database and store fetched project specification data and fetched contractor data in the first database;
- a second electronic database configured to store information about a plurality of deliveries of construction materials to respective construction sites wherein, for each delivery of a delivered construction material, the second database is configured to store: an identification of the delivered construction material; an identification of a source of the delivered construction material; and an identification of a delivery location of the delivered construction material;
- a server configured to automatically: store information in the second database as respective construction materials are obtained from respective suppliers and delivered to respective delivery locations; and associate each delivery of a delivered construction material to an associated contractor;
- a data reconciliation module configured to use the information in the first and second databases to automatically associate each delivery of a delivered construction material to an associated project in the project specification data of the first database;
- a comparator configured, for each delivery of a delivered construction material, to use the information in the first and second databases to automatically verify the respective delivered construction material complies with material specification requirements in the project specification data of the associated project; and
- a second interface configured, for each delivery of a delivered construction material for which the comparator verification succeeds, to automatically store delivery confirmation data for the delivered construction material and the associated contractor.
2. (canceled)
3. (canceled)
4. (canceled)
5. (canceled)
6. (canceled)
7. (canceled)
8. (canceled)
9. (canceled)
10. (canceled)
11. (canceled)
12. (canceled)
13. (canceled)
14. (canceled)
15. (canceled)
16. (canceled)
17. (canceled)
18. (canceled)
19. (canceled)
20. (canceled)
21. (canceled)
22. (canceled)
23. (canceled)
24. (canceled)
25. (canceled)
26. (canceled)
Type: Application
Filed: Sep 26, 2022
Publication Date: Oct 19, 2023
Inventors: Joseph Spinelli (Harvard, MA), Corey Paradis (Dover, NH), Varadarajan Parthasarathi (Austin, TX), Matthew Valle (Concord, NH), Prajyot Bankade (Stow, MA)
Application Number: 17/952,710
