DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Objections
Claim 16 objected to because of the following informalities:
Claim 16 recites: “The system as recited in claim 15”. However, Claim 15 claims a server, and so there is no antecedent basis for “system” in claim 16. Claims 15 and/or 16 should be amended to both recite either “server” or “system”.
Appropriate correction is required.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 8, 10, 11, 15, and 18 are rejected under 35 U.S.C 103 as being unpatentable over Dubov (US 20210191364 A1) in view of Modelur (NPL: Interactive 3D Zoning™; hereinafter “Modelur (3D Zoning)”).
Regarding claim 1:
Dubov teaches:
A method of presenting structured digitized zoning data, by a server (Dubov: The machine may operate in the capacity of a server [0123]) including a processor and a memory (Dubov: A computer system may include a processor, a memory, and a non-transitory computer-readable medium [0022]), via an application programming interface (API) (Dubov: the data store may be accessed via an application program interface (API) for instance where the system 100 may access data via a cloud-based system or service [0028]) to a client computer for displaying representations of geospatial data generated by generative architecture model software 114 on a graphical user interface (GUI) (Dubov: an application engine 132 that can […] generate user interface data describing property boundaries, property footprints, building envelopes, property building layouts and building modules. [0023]; Dubov: FIGS. 5-13 depict example user's interfaces in accordance with example embodiments. [0010]) on the client computer (Dubov: The system 100 can generate interactive user interfaces 134 (e.g., web pages to be rendered by a user device) [0023]), the method comprising:
receiving, by the server and via the API (Dubov: The data store 110 may be a local or remote database that includes zoning data related to the property identifier. Moreover, the data store may be accessed via an application program interface (API) for instance where the system 100 may access data via a cloud-based system or service, or an Internet-based data store [0028]), a zoning restrictions request from the client computer generated by a user interacting with the GUI displayed on the client computer by the generative architecture model software 114, the zoning restrictions request including a selected geographic area (Dubov: The system 100 may receive a user selection of one or more of the property parcels via the user interface 134 [0027]; see Note 1C);
accessing, by the processor, a zoning data record, from a zoning record database in the memory, associated with the selected geographic area (Dubov: One of the operations is performed by receiving, via a user interface, a selection of a property, and accessing zoning information based on the property [0004]), the zoning data record associating a zone in which the selected geographic area is located with zoning restriction attributes limiting real estate development within the zone (Dubov: In response to the selection, the system 100 obtains zoning data from a data store 110 related to the user's selected property parcel 220. [0027]), the zoning data record further associating the zoning restriction attributes with (Dubov: Exemplary zoning data may include, but is not limited to the following: [0029]) zoning use class information for the zone (Dubov: Current Use—is an allowed type of use for the tract, such as commercial, administrative, residential or industrial. [0032]) and zoning restriction parameters for the zoning restriction attributes (Dubov: Maximum Building Height—is the maximum height for a building structure on the tract and is typically designated in feet or meters. [0048]); and
extracting from the zoning data record, by the processor, as a function of the zoning restriction request, the zoning restriction attributes associated with the zone and the zoning restriction parameters for the zoning restriction attributes (Dubov: the system 100 may receive user input defining parameters for the overall dimension of an assembled building such as width and length, total square feet, etc. [0097]) by
retrieving, from the zoning data record, the zoning restriction attributes associated with the zone in the zoning data record and each zoning restriction parameter for the default and/or conditional zoning use class associated with the zoning restriction attributes in the zoning data record (Dubov: For example, if the overall building footprint must fit within a 30-foot by 30-foot square area, then the system 100 would preclude and not present to the user those building modules that exceed 30 ft in its length or width. [0097]);
packaging, by the processor (Dubov: The system 100 may generate an electronic package of one or more electronical files for transmission to one or more 3D printers for printing of the structures [0090]), the extracted zoning restriction attributes and zoning restriction parameters into a data object (Dubov: Each building module has a pre-defined specification and requirements which may be included in the generated permitting document package, including building module connection types, required foundation type, utility requirements, and connections between building modules. [0080]) in a predefined data exchange format associated with the API (Dubov: the system 100 may create files in a format used for 3D printing (e.g., .obj files (very common format for 3D printing), .STL files (STereoLithography) … [0090]; see Note 1B); and
transmitting, by the processor, the data object, as an API response (see Note 1A), to the generative architecture model software to generate a visual representation of the extracted zoning restriction parameters on the GUI on the client computer (Dubov: displaying, via a user interface, a graphical representation of two or more building modules, Abstract).
Note 1A: When the system is implemented via an API as described by Dubov, it would be obvious to one of ordinary skill in the art to transmit data utilizing an API response.
Note 1B: Dubov teaches that the data store accessed by the API “include, but are not limited to, zoning data 110 which includes zoning data related to a property identifier, property shape data 112 which includes property shape data related to a property identifier, and structure building layout data 114 which includes structure data related to building layouts and/or building modules”. [0024] and that shape data refers to “vector or raster data, geo-spatial coordinates, or other data that may be used to render a graphical shape” [0052]. File formats such as .obj (from [0090] above) are well known in the art not just for 3D printing, but 3D rendering as well. Therefore, the Examiner understands the .obj file format to be associated with the API taught by Dubov.
Note 1C: One of ordinary skill in the art would understand that “parcel” as used by Dubov refers to a geographic area representing a specific piece of land that is legally defined and recognized as a single, distinct unit.
Dubov fails to explicitly teach:
A method of presenting structured digitized zoning data, by a server including a processor and a memory, via an application programming interface (API) to a client computer for displaying three-dimensional (3D) representations of geospatial data generated by generative architecture model software 114 on a graphical user interface (GUI) on the client computer.
extracting from the zoning data record, by the processor, as a function of the zoning restriction request and as a function of a default and/or a conditional zoning use class, the zoning restriction attributes associated with the zone and the zoning restriction parameters for the zoning restriction attributes by
Modelur (3D Zoning) teaches:
A method of presenting structured digitized zoning data, by a server including a processor and a memory, via an application programming interface (API) to a client computer for displaying three-dimensional (3D) representations of geospatial data (see Note 1D) generated by generative architecture model software 114 on a graphical user interface (GUI) on the client computer.
extracting from the zoning data record, by the processor, as a function of the zoning restriction request and as a function of a default and/or a conditional zoning use class (Modelur (3D Zoning): when we move the building from one area to another, those buildings adapt to the local rules of the parcels instantly instead of requiring [the] user to always adapt it themselves, 3:32-3:45; see Note 1E), the zoning restriction attributes associated with the zone and the zoning restriction parameters for the zoning restriction attributes by
retrieving, from the zoning data record, the zoning restriction attributes associated with the zone (Modelur (3D Zoning): Selected City Block Parameters, 3:32-3:45) in the zoning data record and each zoning restriction parameter for the default and/or conditional zoning use class (Modelur (3D Zoning): Default Land Use, 3:32-3:45) associated with the zoning restriction attributes in the zoning data record (Modelur (3D Zoning): City Block Limits, 3:32-3:45, see Note 1D);
Note 1D: Modelur (3D Zoning) showcases from 3:18 to 5:05 software that can generate and modify three-dimensional (3D) representations of geospatial data and display them within a graphical user interface. See also the screenshots for Note 1E below.
Note 1E: From 3:32 to 3:45, Modelur (3D Zoning) teaches that: “… when we move the building from one area to another, those buildings adapt to the local rules of the parcels instantly instead of requiring [the] user to always adapt it themselves.”
Looking closely at the right side of the GUI while the presenter is speaking, one can see that the “Selected City Block Parameters” update when the user moves the building between parcels with a different “Default Land Use”, and that the other parameters, such as “Max. Permitted Building Height” update automatically. In other words, based on the request (dragging the building between parcels) and the default use class (the Default Land Use of the parcel), the maximum building height (among other parameters) may be adjusted.
Paragraph [0022] of the specification of the present application poses a problem in the prior art related to the limitations above. Namely, it states that “… if, for a zoning restriction attribute (e.g., maximum building height), there are multiple use classes (e.g., single family dwelling, two family dwelling, multi-family dwelling) each with a different zoning restriction parameters (e.g., 35 feet for single family dwelling, 45 feet for two family dwelling, 50 feet for multi-family dwelling), the data records auto-generated by the zoning database providers simply include all of the values for every use class or include the value STF, which means “see text field.” Human input is thus required to determine which zoning restriction applies to the allotment or project area, and zoning database systems cannot integrate their auto-generated outputs into generative architecture model software.” [0022]. The Examiner understands the teachings of Modelur (3D Zoning) to relate to the problem posed in the specification and therefore, teach the corresponding limitations in claim 1.
Additionally, when combined with the teachings of Dubov, it would be obvious to one of ordinary skill in the art to obtain the block or building parameters from a zoning data record.
PNG
media_image1.png
417
697
media_image1.png
Greyscale
PNG
media_image2.png
414
697
media_image2.png
Greyscale
PNG
media_image3.png
777
1286
media_image3.png
Greyscale
From 3:32 to 3:45, Modelur (3D Zoning) showcases dragging the building between different parcels. The building automatically adjusts the maximum height parameter (shown in text on the right) and the model is adjusted to reflect the change.
Before the effective filing date, it would be obvious for one of ordinary skill in the art to combine the teachings of Dubov with Modelur (3D Zoning). Extracting from the zoning data record, by the processor, as a function of the zoning restriction request and as a function of a default and/or a conditional zoning use class, would benefit the Dubov teachings by automating building modifications so the user does not have to spend time making modifications manually: “those buildings adapt to the local rules of the parcels instantly instead of requiring [the] user to always adapt it themselves,” (3:32-3:45, Modelur (3D Zoning))
Regarding claim 8:
The method as recited in claim 1 (as shown above)
wherein the receiving of the zoning restrictions request from the client computer includes receiving geospatial boundary coordinates for the selected geographic area (Dubov: The property identifier may be […] a geo-spatial location such as a GPS or GNSS coordinate [0026]; see Note 8A).
Note 8A: Dubov teaches that: “the system 100 obtains property parcel information based on a received property identifier 210 via the user interface 134.” When “the data store may be accessed via an application program interface (API)” [0028], it would be obvious to one of ordinary skill in the art to receive geospatial boundary coordinates for the selected geographic area.
Regarding claim 10:
Dubov in view of Modelur (3D Zoning) teaches:
The method as recited in claim 8 (as shown above), wherein the accessing of the zoning data record associated with the selected geographic area includes:
identifying, by the processor, the zone, from amongst a plurality of zones in the memory (see Note 10A), having a boundary defined by geospatial boundary coordinates in which the received boundary geospatial coordinates for the selected geographic area are located (see Note 10B); and
accessing the zoning data record associated with the zone in the memory (see Note 10C).
Note 10A: In Note 6A it was discussed that Modelur (3D Zoning) teaches selection of different zones in the GUI. Modelur (3D Zoning) shows that any zone from the mulitple zones on screen are selectable, and therefore, Modelur (3D Zoning) teaches “identifying, by the processor, the zone, from amongst a plurality of zones in the memory”.
Note 10B: Dubov teaches that a boundary may be defined by shape data: “Based on the retrieved zoning data and shape data 110, 112, via the building envelope determination module 106, the system 100 generates a graphical representation of the property boundary 304” [0053]. Dubov also teaches that the shape data may be geospatial coordinates: “the system 300 retrieves from one or more data stores, shape data 112 (e.g., vector or raster data, geo-spatial coordinates, or other data that may be used to render a graphical shape) related to the property identifier.” [0052]. Therefore, the Examiner understands Dubov to teach “a boundary defined by geospatial boundary coordinates in which the received boundary geospatial coordinates for the selected geographic area are located”.
Note 10C: In Note 6A it was discussed that when a specific “zone” is selected by the user, the corresponding parameters for the zone appear in the GUI. When combined with the teachings of Dubov, which teaches accessing zoning data via an API, it would be obvious to one of ordinary skill in the art to “accessing the zoning data record associated with the zone in the memory”.
Regarding claim 11:
Dubov in view of Modelur (3D Zoning) teaches:
The method as recited in claim 1 (as shown above) wherein the extracting of the zoning restriction parameters includes to identifying, from amongst a plurality of zoning restriction parameters corresponding to the zoning restriction attributes, the zoning restriction parameters applicable to the zoning use class associated with the selected geographic area for the zoning restriction attributes (see Note 11A).
Note 11A: In Note 6A, it was shown that when a zone is selected by the user, the “City Block Parameters” related to that block are displayed within the GUI. Among the parameters showcased in the images associated with Note 6A are “Maximum Permitted FAR”, “Max. Permitted Building Height”, “Max. Permitted Site Coverage”, and so on. These parameters are updated based on the selected city blocks, which differ in Default Land Use, or “zoning use class”, as shown in Note 6A. Therefore, the Examiner understands Modelur (3D Zoning) to teach “identifying, from amongst a plurality of zoning restriction parameters corresponding to the zoning restriction attributes, the zoning restriction parameters applicable to the zoning use class associated with the selected geographic area for the zoning restriction attributes”.
Regarding claim 15:
Claim 15 is substantially similar to claim 1, and is therefore rejected for similar reasons. Claim 15 contains the following notable differences:
Claim 15 claims a “server comprising: at least one processor; and a memory coupled to the at least one processor, the memory including software instructions executable by the at least one processor” instead of a method. Dubov teaches a server: “The machine may be […] a server, a network router, a switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine.” [0124].
Regarding claim 18:
Dubov in view of Modelur (3D Zoning) teaches:
A non-transitory computer-readable media storing computer-executable instructions that, when executed on a processor, cause the processor to perform the method (Dubov: The data storage device 918 may include a machine-readable storage medium 924 (also known as a computer-readable medium) on which is stored one or more sets of instructions or software 926 embodying any one or more of the methodologies or functions described herein. [0128]) as recited in claim 1 (as shown above).
Claims 2, 3, and 16 are rejected under 35 U.S.C 103 as being unpatentable over Dubov (US 20210191364 A1) in view of Modelur (3D Zoning) (NPL: Interactive 3D Zoning™) and Williams (US 20210271370 A1).
Regarding claim 2:
Dubov in view of Modelur (3D Zoning) teaches:
The method as recited in claim 1 (as shown above) further comprising:
Dubov in view of Modelur (3D Zoning) fails to explicitly teach:
receiving, by the server and via the API, a 3D model request from the client computer generated by the user interacting with the GUI displayed on the client computer by the generative architecture model software, the 3D model request including a request for a 3D model of a building envelope delimited by the zoning restriction parameters for the selected geographic area; and
processing the received 3D model request, by the processor, and transmitting the requested 3D model of the building envelope to the generative architecture model software to generate a 3D geospatial data layer of the building envelope on the GUI displayed on the client computer on a 3D geospatial representation of the selected geographic area.
Dubov in view of Modelur and Williams teaches:
receiving, by the server and via the API, a 3D model request from the client computer (Williams: the act of obtaining the 3D model comprises retrieving, by a processing unit, the 3D model through a request made to an application programming interface (API) [0062]) generated by the user interacting with the GUI displayed on the client computer by the generative architecture model software (see Note 2A), the 3D model request including a request for a 3D model of a building envelope delimited by the zoning restriction parameters for the selected geographic area; and
processing the received 3D model request, by the processor (Williams: the processing unit is configured to retrieve the 3D model through a request made to an application programming interface (API). [0037]), and transmitting the requested 3D model of the building envelope to the generative architecture model software to generate a 3D geospatial data layer of the building envelope on the GUI displayed on the client computer on a 3D geospatial representation of the selected geographic area (Modelur: 3:32 to 3:45; see Note 2B and Note 1E above).
Note 2A: Modelur (3D Zoning), as showcased in Note 1E above, selects a parcel by dragging a building to a specific parcel, which updates the parameters of said building and updates the model of the building to match the zoning restrictions: “the system will adapt the building according to the zoning ordinance of the city or of the specific city blocks” (3:51-4:01). Dubov has taught an API that can handle requests for zoning data: “The system 100 may receive a user selection of one or more of the property parcels via the user interface 134. In response to the selection, the system 100 obtains zoning data from a data store 110 related to the user's selected property parcel 220,” [0027] and that “the data store may be accessed via an application program interface (API)” [0028].
Note 2B: Because Modelur (3D Zoning) teaches updating a 3D model based on the zoning data from the API, it would be obvious to one of ordinary skill in the art to modify the API of Dubov to also support obtaining a 3D model based on the zoning data.
Williams teaches that: “the act of obtaining the 3D model comprises retrieving, by a processing unit, the 3D model through a request made to an application programming interface (API)”. Therefore, when the model in the UI is updated as taught by Modelur (3D Zoning), the Examiner understands Modelur (3D Zoning) to teach “generat[ing] a 3D geospatial data layer of the building envelope on the GUI displayed on the client computer”. Furthermore, the building model is placed on a selected parcel (indicated by the sidebar on the right, specifically the “Selected City Block” (Modelur (3D Zoning), 3:52)), and so the generated “3D geospatial data layer” would be placed “on a 3D geospatial representation of the selected geographic area”.
Williams teaches general user input device “configured to generate a signal in response to a user input for selecting the 2D element displayed by the screen; wherein the processing unit is configured to obtain a 3-dimensional (3D) model associated with the 2D element in response to the generated signal” (Abstract). The Examiner submits that the method described by Williams is combinable with Dubov in view of Modelur (3D Zoning) because the disclosure of Williams is not limited to XR applications but generally applicable to any user input device.
Before the effective filing date, it would be obvious for one of ordinary skill in the art to combine the teachings of Williams with Dubov in view of Modelur (3D Zoning). Receiving and processing, by the server and via the API, a 3D model request, would benefit the Dubov in view of Modelur (3D Zoning) teachings by enabling remote generation and processing, allowing the user input device to be more lightweight: “In some embodiments, all data is stored and all computation is performed in the local processing and data module 130, allowing fully autonomous use from any remote modules.” (Williams, [0100])
Regarding claim 3:
Dubov in view of Modelur (3D Zoning) and Williams teaches:
The method as recited in claim 2 (as shown above) wherein the zoning restriction parameters delimiting the building envelope are for zoning restriction attributes defining a height of the building envelope (Dubov: Maximum Building Height—is the maximum height for a building structure on the tract and is typically designated in feet or meters. This minimum distance is typically indicated as a numeric value in feet. [0048]), a width of the building envelope, a depth of the building envelope (Dubov: The system 100 may set a minimum predetermined width or length for a suitable building envelope. [0066]) and an area of the building envelope (Dubov: Maximum Floor Area—is the maximum square feet for a building structure. This maximum floor area is typically indicated as a numeric value in square feet. [0041]).
Regarding claim 16:
Claim 16 is substantially similar to claim 2, and is therefore rejected for similar reasons. Claim 16 contains the following notable differences:
Claim 16 claims a “system as recited in claim 15, wherein the memory including software instructions executable by the at least one processor” instead of a method. Dubov teaches a system: “The example computer system 900 includes a processing device 902, a main memory 904” [0125].
Claim 4 is rejected under 35 U.S.C 103 as being unpatentable over Dubov (US 20210191364 A1) in view of Modelur (3D Zoning) (NPL: Interactive 3D Zoning™) and Williams (US 20210271370 A1), Budlong (US 20210342962 A1, from Applicant’s IDS), Schueren (NPL: 3D MODELING IN LAND DEVELOPMENT PLANNING: A TOOL TO VISUALIZE CHANGE), Modelur (NPL: Modelur User Guide; hereinafter “Modelur (Manual)”), and Kim (NPL: PARAMETERIZE URBAN DESIGN CODES WITH BIM AND OBJECT-ORIENTED PROGRAMMING).
Dubov in view of Modelur (3D Zoning) and Williams teaches:
The method as recited in claim 3 (as shown above),
Dubov in view of Modelur (3D Zoning) and Williams fails to teach:
wherein the zoning restriction attributes defining a depth of the building envelope include zoning restriction attributes selected from a group consisting of a setback from a front lot line and a setback from a rear lot line,
the zoning restriction attributes defining a width of the building envelope include zoning restriction attributes selected from a group consisting of a side setback from a side lot line, and a minimum lot width,
the zoning restriction attributes defining a height of the building envelope include zoning restriction attributes selected from a group consisting of a maximum building height, and a maximum floor area ratio,
the zoning restriction attributes defining an area of the building envelope include zoning restriction attributes selected from a group consisting of a minimum lot size, a maximum lot coverage, a maximum impervious coverage, a minimum landscaped space and a minimum open space.
Dubov in view of Modelur (3D Zoning) and Williams teaches some of the zoning restriction parameters (as seen below), but does not teach that the attributes may be used to define other zoning restriction attributes.
Budlong teaches that: “101 is the retrieval of use opportunity for a parcel and its neighboring parcels 102 shows the application's ability to calculate a maximum building structure using zoning control attributes; this example shows size in square feet. 103 shows the application's ability to calculate a maximum building structure using zoning control attributes; this examples shows height in stories.” [0233-0235]. See also Fig. 40D of Budlong.
Budlong teaches that based on other structured data, property data, and logic, properties such as “Max Building Size” and “Max Height” may be calculated. Accordingly, the Examiner submits that it would be obvious to one of ordinary skill in the art to utilize the zoning parameters obtained from a database to calculate zoning data attributes of the building.
Before the effective filing date, it would be obvious to one of ordinary skill in the art to combine the teachings of Budlong with Dubov in view of Modelur (3D Zoning) and Williams. Defining a zoning attribute of the building envelope include zoning restriction attributes selected from a group, as in Budlong, would enhance the teaching of Dubov in view of Modelur (3D Zoning) and Williams because calculation of attributes of the building from other attributes enables the system to generate a standard set of parameters for all buildings, even if some building data is missing for a given location: “This invention targets transforming disparate data sources needed to express a property's land use utility and standardizes the multiple records into a standardized land use utility with an element for time that allows tracking and measuring changes in standardized land use utility at the parcel level for one or more locations” (Budlong, Abstract).
Dubov in view of Modelur (3D Zoning), Williams, and Budlong teaches:
wherein the zoning restriction attributes defining a depth of the building envelope include zoning restriction attributes selected from a group consisting of a setback from a front lot line (Dubov: Minimum Front Setback—is the minimum distance between the edge of the front of the property line of the tract and where a structure may be added [0043]) and a setback from a rear lot line (Dubov: Minimum Rear Setback—is the minimum distance between the edge of the rear of the property line of the tract and where a structure may be added. This minimum distance is typically indicated as a numeric value in feet. [0044]),
the zoning restriction attributes defining a width of the building envelope include zoning restriction attributes selected from a group consisting of a side setback from a side lot line (Dubov: Minimum Side Setback—is the minimum distance between the edge of a side of the property line of the tract and where a structure may be added. [0045]), and a minimum lot width (Budlong: creating a zoning score […] with the outcome derived by comparing a zoning code requirement to the applicable characteristic of the property to be considered, with such characteristics comprising, […] minimum lot width [0853 (e)]),
the zoning restriction attributes defining a height of the building envelope include zoning restriction attributes selected from a group consisting of a maximum building height (Dubov: Maximum Building Height—is the maximum height for a building structure on the tract and is typically designated in feet or meters. [0048]), and a maximum floor area ratio (Modelur: Maximum Permitted FAR, 4:14),
the zoning restriction attributes defining an area of the building envelope include zoning restriction attributes selected from a group consisting of a minimum lot size (Budlong: Regarding “Size”, this invention allows users to look up information either by floor area ratio (FAR), minimum lot size, [0536]),
Dubov in view of Modelur (3D Zoning) Williams, and Budlong fails to teach:
the zoning restriction attributes defining an area of the building envelope include zoning restriction attributes selected from a group consisting of a minimum lot size, a maximum lot coverage, a maximum impervious coverage, a minimum landscaped space and a minimum open space.
Schueren teaches:
the zoning restriction attributes defining an area of the building envelope (Schueren: Table 1. Area and bulk requirements CS district. Pg. 5, Table 1) include zoning restriction attributes selected from a group consisting of a minimum lot size (Schueren: Minimum Lot Area, Pg. 5, Table 1), a maximum lot coverage (Schueren: Maximum Building Coverage, Pg. 5, Table 1), a maximum impervious coverage (Schueren: Maximum Impervious Coverage, Pg. 5, Table 1),
Before the effective filing date, it would be obvious to combine the teachings of Schueren with Dubov in view of Modelur (3D Zoning), Williams, and Budlong. Defining zoning restriction attributes of an area of the building envelope to include zoning restriction attributes selected from a group consisting of a minimum lot size, a maximum lot coverage, and a maximum impervious coverage would improve the Dubov in view of Modelur (3D Zoning), Williams, and Budlong teachings by enabling the system to take advantage of building data that may help construct a standard building dataset: “This collaboration requires the integration of various types of data, software, and multiple systems. […] Utilizing the new support given by modern computing and communications technology is an important aspect of this new level of geospatial analysis.” (Schueren: Pg. 3, par. 3).
Dubov in view of Modelur (3D Zoning) Williams, Budlong, and Schueren still fails to teach:
the zoning restriction attributes defining an area of the building envelope include a minimum landscaped space and a minimum open space.
Modelur (Manual) teaches:
the zoning restriction attributes defining an area of the building envelope include a minimum landscaped space (Modelur (Manual): Required GA per Primary Unit, Pg. 50, Green Areas Calculation)
Before the effective filing date, it would be obvious to combine the teachings of Modelur (Manual) with Dubov in view of Modelur (3D Zoning), Williams, Budlong, and Schueren because Modelur (3D Zoning) and Modelur (Manual) teach features of the same software.
Dubov in view of Modelur (3D Zoning) Williams, Budlong, Schueren, and Modelur (Manual) still fails to teach:
the zoning restriction attributes defining an area of the building envelope include a minimum open space.
Kim teaches:
the zoning restriction attributes defining an area of the building envelope include a minimum open space. (Kim: The parcel component holds topology information and regulatory information that can outline open spaces, development capacity, building dispositions, and building envelopes. For instance, the minimum ratio of open space to the property, Pg. 5, Section 3.2: Create Parametric Code Models)
Before the effective filing date, it would be obvious to combine the teachings of Kim with Dubov in view of Modelur (3D Zoning), Williams, Budlong, Schueren, and Modelur (Manual). Defining zoning restriction attributes of an area of the building envelope to include zoning restriction attributes selected from a group consisting of a minimum open space would improve the Modelur (3D Zoning), Williams, Budlong, Schueren, and Modelur (Manual) teachings by enabling the system to match parcels or city blocks with data described in regulatory documents: “For instance, the minimum ratio of open space to the property area and maximum area of building footprints are described in most code provisions; therefore, the parcel area determines an open space area as well as footprint area of buildings and parking structures.” (Kim, Pg. 8, Section 3.4: Develop Analytical Applications).
Claims 5 and 6 are rejected under 35 U.S.C 103 as being unpatentable over Dubov (US 20210191364 A1) in view of Modelur (NPL: Interactive 3D Zoning™, hereinafter “Modelur (3D Zoning)”), Williams (US 20210271370 A1) and Modelur (NPL: Modelur Parameters Hierarchy; hereinafter “Modelur (Hierarchy)”).
Regarding claim 5:
Dubov in view of Modelur (3D Zoning) and Williams teaches:
The method as recited in claim 2 (as shown above)
Modelur (Hierarchy) teaches:
wherein the receiving of the 3D model request includes receiving, by the server, as part of the 3D model request, the relevant zoning restriction parameters delimiting the building envelope, as transmitted to the generative architecture model software in the data object, or as further modified by the user of the client computer via the GUI (see Note 5A).
Note 5A: Modelur (Hierarchy) teaches: “…so when I move the building from one area to another you can see that it adapts. This is because right now the building doesn’t have any parameter set, so everything that defines it is pulled from the city block. Now if I go here and say this building actually, I want it to be nine stories high no matter where we move it, I can do that. Now it only adapts the land uses.” (2:10-2:37).
Modelur teaches that each building may have parameters relating to the envelope. Similarly to Modelur (3D Zoning), Modelur showcases that a building may automatically adjust its height based on the city block, which, in Note 1D above, was understood to be analogous to “retrieving, from the zoning data record, the zoning restriction attributes associated with the zone”. However, Modelur (Hierarchy) showcases that by modifying a zoning restriction parameter via the GUI, namely, the maximum building height, the building model may retain its height despite changes in the parcel it is placed on. Therefore, the Examiner understands Modelur (Hierarchy) to teach “the relevant zoning restriction parameters delimiting the building envelope, as further modified by the user of the client computer via the GUI”. Furthermore, as discussed above in Note 1F, when combined with the teachings of Dubov, it would be obvious to receive the parcel data, by the server, as part of the 3D model request.
PNG
media_image4.png
412
715
media_image4.png
Greyscale
PNG
media_image5.png
415
714
media_image5.png
Greyscale
Before modifying the building parameter, the building model updates both color and size as those parameters are determined by the parcel the building resides on. (Modelur (Hierarchy) 2:14-2:18)
PNG
media_image6.png
392
681
media_image6.png
Greyscale
PNG
media_image7.png
397
685
media_image7.png
Greyscale
After modifying the building parameter, the building model updates only the color and does not change size. (Modelur (Hierarchy) 2:30-2:35)
Before the effective filing date, it would be obvious to combine the teachings of Dubov in view of Modelur (3D Zoning) and Williams with Modelur (Hierarchy) because Modelur (3D Zoning) and Modelur (Hierarchy) teach features of the same software.
Regarding claim 6:
Dubov in view of Modelur (3D Zoning), Williams, and Modelur (Hierarchy) teaches:
The method as recited in claim 5 (as shown above) wherein the receiving of the received 3D model request includes receiving, by the server, as part of the 3D model request, the selected geographic area (see Note 6A).
Note 6A: In Note 1E, it was shown that the Modelur (3D Zoning) showcases dragging the building between different parcels, which was understood by the examiner to be analogous to selecting a parcel for updating the model of the building. The Examiner submits that it would be obvious to send the parcel or “city block” alongside the other data sent with the API request described in Note 1E.
Furthermore, Modelur (3D Zoning) also teaches that “Selected City Block Parameters” within the interface may be updated based on the user selection, as shown below:
PNG
media_image8.png
411
702
media_image8.png
Greyscale
Modelur (3D Zoning) at 4:14 showcases that when the light blue zone is selected, the Selected City Block Parameters will update to show the statistics of that area. In this case, the selected area’s “Default Land Use” is “Kindergarten” and it has a “Max. Permitted Building Height” of 5m.
PNG
media_image9.png
377
925
media_image9.png
Greyscale
Modelur (3D Zoning) at 4:09 showcases that when the light yellow zone is selected, the Selected City Block Parameters will update to show the statistics of that area. In this case, the selected area’s “Default Land Use” is “Residential” and it has a “Max. Permitted Building Height” of 20m.
Claim 7 is rejected under 35 U.S.C 103 as being unpatentable over Dubov (US 20210191364 A1) in view of Modelur (3D Zoning) (NPL: Interactive 3D Zoning™), Williams (US 20210271370 A1) Modelur (NPL: Modelur Parameters Hierarchy; hereinafter “Modelur (Hierarchy)”) and Copley (WO 2021148882 A1).
Regarding claim 7:
Dubov in view of Modelur (3D Zoning), Williams, and Modelur (Hierarchy) teaches:
The method as recited in claim 6 (as shown above) wherein the selected geographic area is in the form of geospatial boundary coordinates (Dubov: The property identifier may be […] a geo-spatial location such as a GPS or GNSS coordinate [0026]; see Note 8A),
Dubov in view of Modelur (3D Zoning), Williams, and Modelur (Hierarchy) fails to teach:
wherein the selected geographic area is in the form of geospatial boundary coordinates and a geospatial origin coordinate,
the processing of the received 3D model request including transforming the geospatial boundary coordinates to local coordinates (Copley: 4: // This is used to transform points from global coordinates to an approximately 5: accurate local coordinate system for the parcel based on the parcel centroid, Pg. 13-14, Table 2, ln 4-5).
Copley teaches:
wherein the selected geographic area is in the form of geospatial boundary coordinates and a geospatial origin coordinate (Copley: the parcel centroid, PG. 13-14, Table, 2, ln. 5),
the processing of the received 3D model request including transforming the geospatial boundary coordinates to local coordinates (Copley: 4: // This is used to transform points from global coordinates to an approximately 5: accurate local coordinate system for the parcel based on the parcel centroid, Pg. 13-14, Table 2, ln. 4-5).
Before the effective filing date, it would be obvious to combine the teachings of Copley with Dubov in view of Modelur (3D Zoning), Williams, and Modelur (Hierarchy). Combining the teachings of Copley would enhance the Dubov in view of Modelur (3D Zoning), Williams, and Modelur (Hierarchy) teachings because it would enable a user to “see and act upon potential land uses that are not reflected in conventional valuations” (Copley, Abstract).
Claim 9 is rejected under 35 U.S.C 103 as being unpatentable over Dubov (US 20210191364 A1) in view of Modelur (NPL: Interactive 3D Zoning™; hereinafter “Modelur (3D Zoning)”) and Modelur (NPL: Modelur User Guide, hereinafter “Modelur (Manual)”).
Regarding claim 9:
Dubov in view of Modelur (3D Zoning) teaches:
The method as recited in claim 8 (as shown above),
Dubov in view of Modelur (3D Zoning) fails to explicitly teach:
wherein the geospatial coordinates are generated by the user drawing a polygon on a 3D geospatial representation of a geographic region displayed by the generative architecture model software on the GUI or by selecting a real estate parcel displayed on the 3D geospatial representation of a geographic region.
Modelur (Manual) teaches:
wherein the geospatial coordinates are generated by the user drawing a polygon on a 3D geospatial representation of a geographic region displayed by the generative architecture model software on the GUI or by selecting a real estate parcel displayed on the 3D geospatial representation of a geographic region (Modelur (Manual): More commonly, you will want to create your own floor plan and create Building based on its shape. To do this, simply draw a horizontal face (Modelur will select it automatically if it is being created) using standard SketchUp’s procedure, or select existing face, and click on Create Building button (Figure 3.07), Pg. 13, par. 1).
Before the effective filing date, it would be obvious to combine the teachings of Modelur (Manual) with Dubov in view of Modelur (3D Zoning), because Modelur (3D Zoning) and Modelur (Manual) teach features of the same software.
As illustrated by an example zoning data record format 602 in Fig. 6, each zoning data record in zoning record database 108 can be in a nested format in which each zoning restriction attribute is a parent element 602a and all of the zoning use classes and the zoning restriction parameters applicable to the zoning use class associated with the selected geographic area for the zoning restriction attributes are stored as child elements 602b of the respective zoning restriction attribute. During the extracting by the processor 103, the decision tree can filter through each zoning restriction attribute and find the child elements 602b associated with the selected conditional zoning use class. All of the zoning restriction attributes associated with the zone of the selected geographic area and the corresponding zoning restriction parameters associates with the selected conditional zoning use class can be packaged into a data object in an example predefined data exchange format 604 in Fig. 6.
Claim 14 is rejected under 35 U.S.C 103 as being unpatentable over Dubov (US 20210191364 A1) in view of Modelur (NPL: Interactive 3D Zoning™; hereinafter “Modelur (3D Zoning)”), Modelur (NPL: Modelur User Guide; hereinafter “Modelur (Manual)”), and Modelur (NPL: Modelur Parameters Hierarchy; hereinafter “Modelur (Hierarchy)”).
Regarding claim 14:
Dubov in view of Modelur (3D Zoning) teaches:
The method as recited in claim 1 (as shown above),
Dubov in view of Modelur (3D Zoning) fails to explicitly teach:
wherein the extracting from the zoning data record, by the processor, is performed as a function of the default zoning use class, the method further comprising:
sending, by the server and via the API, conditional zoning use class associated with the selected geographic area for display on the GUI of the client computer;
receiving, by the server and via the API, a selection of the one of the conditional zoning use class by the user of the client computer via the GUI;
extracting from the zoning data record, by the processor, as a function of the zoning restriction request and as a function of the selected conditional zoning use class, the zoning restriction attributes associated with the zone and conditional zoning restriction parameters for the zoning restriction attributes by retrieving, from the zoning data record, the zoning restriction attributes associated with the zone in the zoning data record and each conditional zoning restriction parameter for the conditional zoning use class associated with the zoning restriction attributes in the zoning data record;
packaging, by the processor, the conditional extracted zoning restriction parameters into a further data object in the predefined data exchange format associated with the API; and
transmitting, by the processor, the further data object, as an API response, to the generative architecture model software to generate a visual representation of the conditional extracted zoning restriction parameters on the GUI on the client computer.
Modelur (Manual) in view of Modelur (Hierarchy) teaches:
wherein the extracting from the zoning data record, by the processor, is performed as a function of the default zoning use class (see Note 14A), the method further comprising:
sending, by the server and via the API, conditional zoning use class associated with the selected geographic area for display on the GUI of the client computer (Modelur: Using default Land Use dropdown menu you can set the default Land Use for City Blocks and Buildings. Land Uses are used to calculate Building's units (eg. apartments, residents, offices, etc), parking requirements, green area requirements, etc. Pg. 34, Default Land Use; see Note 14B);
receiving, by the server and via the API, a selection of the one of the conditional zoning use class by the user of the client computer via the GUI (Modelur (Manual); If we want to change, eg. Land Use of the Building, go ahead - check itand change its value, Pg. 15, Overloaded Parameters; see Note 14B);
Note 14A: Modelur (Manual) teaches that: “Parameters work hierarchically in Modelur. This means that the object (eg. Building) first looks if its parameter in question (eg. Number of Storeys) is defined. If yes, it uses it. If not, it uses the Parameter from its parent object, which is either a Complex Building (if the Building is part of Complex Building) or City Block. If the Building finds the parameter value in its parent object, it uses it. If not, it looks further up all the way to the Whole Plot, which is a top-most object in Modelur and holds all Parameters needed to define a Building (Figure 3.08).” (Pg. 3, Step 3 – Changing the Parameters). In other words, parameters such as the “Default Land Use” taught in Modelur (3D Zoning) are defined “by default” at the Whole Plot level. However, the Default Land Use can vary “conditionally” at each City Block or Building.
Therefore, when the city block has an inherited Land Use (see Fig. 3.08 on Pg. 14 of Modelur (Manual)), the extracting from the zoning data record, by the processor, would be performed as a function of the default zoning use class.
Note 14B: Modelur (Hierarchy) showcases that the Default Land Use may be changed by the user with the GUI. Specifically, at 1:35 to 1:40, the presenter changes the Default Land Use of a city block from “Residential” to “Service”. When the zoning data store is accessed by an API as taught in Dubov, it would be obvious for one of ordinary skill in the art to send, by the server and via the API, conditional zoning use class associated with the selected geographic area for display on the GUI of the client computer, because the user can add or remove the Land Uses used by the software: “Under Land Use tab (Figure 4.61) you can add, edit or remove Land Uses used by Modelur.” (Pg. 45, Land Use). Accordingly, one of ordinary skill in the art would be motivated to store the Land Uses separately and would find it obvious to use the API for this purpose.
It would also be obvious to one of ordinary skill in the art to then receive, by the server and via the API, a selection of the one of the conditional zoning use class by the user of the client computer via the GUI, as the user can select a Land Use from a dropdown menu to change the Land Use of a city block, as shown in Modelur (Hierarchy) and cited from Modelur (Manual) above.
Before the effective filing date, it would be obvious to combine the teachings of Modelur (Manual) with Dubov in view of Modelur (3D Zoning) because Modelur (Manual) and Modelur (3D Zoning) teach features of the same software.
Similarly, before the effective filing date, it would be obvious to combine the teachings of Modelur (Hierarchy) with Dubov in view of Modelur (3D Zoning) and Modelur (Manual) because Modelur (Hierarchy), Modelur (Manual), and Modelur (3D Zoning) all teach features of the same software. Furthermore, Modelur (Hierarchy) explicitly incorporates the Modelur (Manual) reference including Figure 3.08 discussed above, at 1:10 to 1:30.
Dubov in view of Modelur (3D Zoning), Modelur (Manual), and Modelur (Hierarchy) teaches:
extracting from the zoning data record, by the processor, as a function of (Modelur (3D Zoning): when we move the building from one area to another, those buildings adapt to the local rules of the parcels instantly instead of requiring [the] user to always adapt it themselves, 3:32-3:45; see Note 1E), the zoning restriction attributes associated with the zone and the zoning restriction parameters for the zoning restriction attributes (Dubov: the system 100 may receive user input defining parameters for the overall dimension of an assembled building such as width and length, total square feet, etc. [0097]; Dubov: For example, if the overall building footprint must fit within a 30-foot by 30-foot square area, then the system 100 would preclude and not present to the user those building modules that exceed 30 ft in its length or width. [0097]) by
retrieving, from the zoning data record, the zoning restriction attributes associated with the zone (Modelur (3D Zoning): Selected City Block Parameters, 3:32-3:45) in the zoning data record and each conditional zoning restriction parameter for the conditional zoning use class (Modelur (3D Zoning): Default Land Use, 3:32-3:45) associated with the zoning restriction attributes in the zoning data record (Modelur (3D Zoning): City Block Limits, 3:32-3:45, see Note 1D);
packaging, by the processor (Dubov: The system 100 may generate an electronic package of one or more electronical files for transmission to one or more 3D printers for printing of the structures [0090]), the conditional extracted zoning restriction parameters into a data object (Dubov: Each building module has a pre-defined specification and requirements which may be included in the generated permitting document package, including building module connection types, required foundation type, utility requirements, and connections between building modules. [0080]) in a predefined data exchange format associated with the API (Dubov: the system 100 may create files in a format used for 3D printing (e.g., .obj files (very common format for 3D printing), .STL files (STereoLithography) … [0090]; see Note 1B); and
transmitting, by the processor, the further data object, as an API response (see Note 1A), to the generative architecture model software to generate a visual representation of the conditional extracted zoning restriction parameters on the GUI on the client computer (Dubov: displaying, via a user interface, a graphical representation of two or more building modules, Abstract).
Williams (US 20210271370 A1) teaches “the act of obtaining the 3D model comprises retrieving, by a processing unit, the 3D model through a request made to an application programming interface (API)” [0062].
Claim 17 is rejected under 35 U.S.C 103 as being unpatentable over Modelur (NPL: Modelur User Guide; hereinafter “Modelur (Manual)”) in view of Dubov (US 20210191364 A1).
Regarding claim 17:
A method of presenting structured digitized zoning data, the method comprising:
receiving, via the application programming interface, a request from the generative architecture model software including a selected geographic location (Modelur (Manual): Create button is used to create City Block, the same way as by clicking on the yellow Create City Block icon in Modelur Toolbar. If no Face or Edge Loop is selected, Modelur will switch to Line Tool and wait until you draw a new Face. Once you draw a Face (closed planar Edge loop), Modelur will convert it to City Block, Pg. 39, Buttons: Create);
processing the request, via a computer processor, by:
mapping to the location information to a data record including zoning restriction attributes (Modelur: Under General Site Limits you can set the default constraints set by zoning ordinance so that Modelur can warn you if they are exceeded, Pg. 34, General Site Limits) and a zoning use class associated with the selected geographic location (Modelur (Manual): Using Default Land Use dropdown menu you can set the Land Use that will be applied by default to each Building(s) in the City Block, Pg. 40, Default Land Use); and
identifying, from amongst a plurality of zoning restriction parameters, a zoning restriction parameter applicable to the zoning use class associated with the area information for each of the zoning restriction attributes (Modelur (Manual): Land Uses are used to calculate Building's units (eg. apartments, residents, offices, etc), parking requirements, green area requirements, etc.” (Pg. 40, Default Land Use), Pg. 40, Default Land Use; see Note 17A); and
generating a 3D design model (Modelur: Create button is used to create simple Building, the same way as by clicking on the yellow Create Building icon in Modelur Toolbar, Pg. 52, Buttons – Create) based on the zoning restriction parameters to be displayed via a graphical user interface (Modelur (Manual): Default Building Parameters inside the Whole Plot tab are the topmost Building parameters in Modelur's hierarchy. This means that if the parameter in question is not defined by the Building itself (or any object it's hierarchy, eg. City Block), Modelur will apply the values defined here to the Building, Pg. 36, Default Building Parameters; see Note 17B).
Note 17A: Modelur teaches that the Land Use can be set for each city block, and that the land use or “zoning use class” may be utilized to determine (or in other words, the land use is associated with) requirements for the buildings placed within the city block.
Note 17B: On Pg. 36 cited above, Modelur teaches that based on superseding objects, such as the City Block, the building may be modified. Furthermore, in Fig. 4.41 of Modelur (Manual), it is shown that the building parameters may be displayed in the GUI.
Modelur (Manual) fails to explicitly teach:
A method of presenting structured digitized zoning data via an application programming interface to generative architecture model software, the method comprising:
Dubov teaches:
A method of presenting structured digitized zoning data (Dubov: the system 100 retrieves zoning data from a data store 110 [0026]) via an application programming interface (Dubov: the data store may be accessed via an application program interface (API) for instance [0028]) to generative architecture model software (Dubov: the system 100 generates a graphical representation of the property boundary 304 (e.g., a polygonal boundary perimeter), pre-existing footprints of the property 306 (e.g., a polygonal footprint perimeter), and one or more building envelopes 308 (e.g., a polygonal building envelope perimeter) [0053]), the method comprising:
Before the effective filing date, it would be obvious for one of ordinary skill in the art to combine the teachings of Dubov with Modelur (Manual). Utilizing an API would benefit the Modelur teachings by enabling operation through any conventional web browser, allowing the user input device to be more lightweight: “The system 100 can generate interactive user interfaces 134 (e.g., web pages to be rendered by a user device) for presentation on a user device 130. A user of the user device 130 can provide information (e.g., user input) associated with a particular property via the user interface 134” (Dubov, (0023]).
Allowable Subject Matter
Claims 12 and 13 objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
The following is a statement of reasons for the indication of allowable subject matter:
Regarding claim 12:
Dubov in view of Modelur (3D Zoning) teaches:
The method as recited in claim 11 (as shown above)
Dubov in view of Modelur (3D Zoning) fails to teach:
wherein the zoning data record is in a nested format in which each zoning restriction attribute is a parent element and all of the zoning use classes and the zoning restriction parameters applicable to the zoning use class associated with the selected geographic area for the zoning restriction attributes are stored as child elements of the respective zoning restriction attribute.
Dubov teaches that: “the system 100 may create files in a format used for 3D printing (e.g., […], .3MF files (an XML-based format used by Microsoft),” [0090]. XML is known in the art to be a nested format. However, Dubov does not teach or suggest a configuration where each zoning restriction attribute is a parent element and all of the zoning use classes and the zoning restriction parameters applicable to the zoning use class associated with the selected geographic area for the zoning restriction attributes are stored as child elements of the respective zoning restriction attribute.
Modelur (Hierarchy) and Modelur (Manual) discuss a nested hierarchy of parameters, but does not teach that the zoning restriction attributes are parent elements.
An online post by user CherylLau teaches: “If you have an attribute in the parent class, you can "pass" it to the child class (this actually happens by default unless you tell it not to). Sorry, "passing" is not the right word here. If an attribute x is defined in the parent class (attr x = 10), and the child class also has an attribute x (attr x = 20), then the parent's value will overwrite the child's value unless you tell it not to overwrite it, and the value will be 10.” (See NPL titled “Hierarchy, linking different cga files”, pg. 3-4)
The post then refers to the ESRI R&D reference. While CherylLau describes parent and child attributes, there is no indication that “zoning restriction parameters applicable to the zoning use class associated with the selected geographic area for the zoning restriction attributes are stored as child elements” as claimed.
None of the other prior art searched or on the record, alone or in combination, teaches the limitations of claim 12.
Claim 13 is dependent on claim 12 and is therefore allowable for the same reasons cited above.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to VINCENT ALEXANDER PROVIDENCE whose telephone number is (571)270-5765. The examiner can normally be reached Monday-Thursday 8:30-5:00.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, King Poon can be reached at (571)270-0728. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/VINCENT ALEXANDER PROVIDENCE/Examiner, Art Unit 2617 /KING Y POON/Supervisory Patent Examiner, Art Unit 2617