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 .
Examiner Notes that the fundamentals of the rejections are based on the broadest reasonable interpretation of the claim language. Applicant is kindly invited to consider the reference as a whole. References are to be interpreted as by one of ordinary skill in the art rather than as by a novice. See MPEP 2141. Therefore, the relevant inquiry when interpreting a reference is not what the reference expressly discloses on its face but what the reference would teach or suggest to one of ordinary skill in the art.
Status of the Claims
This FINAL action is in response to Applicant's amendment of 29 July 2026. Claims 1-20 are pending and have been considered as follows.
Terminal Disclaimer
The terminal disclaimer filed on 29 July 2026 disclaiming the terminal portion of any patent granted on this application which would extend beyond the expiration date of U.S Patent 12,411,024 has been reviewed and is accepted. The terminal disclaimer has been recorded.
Response to Arguments
Applicant's amendments and arguments with respect to the rejection of claims 1-20 under 35 U.S.C. 171 as set forth in the office action of 04 May 2026 have been considered and are persuasive. Therefore, the rejection of claims 1-20 under 35 U.S.C. 171 as set forth in the office action of 04 May 2026 has been withdrawn.
Applicant's amendments and arguments with respect to the rejection of claims 1-20 under 35 USC 101 as set forth in the office action of 04 May 2026 have been considered and are NOT persuasive. Specifically, Applicant argues:
Claims 1-20 stand rejected under 35 U.S.C. § 101 as allegedly directed to a mental process without significantly more.
Applicants respectfully traverse the rejection.
Step 2A, Prong One - The Claims Do Not Recite a Mental Process
The rejection characterizes the calculating, creating, arranging, procedurally generating, and rendering operations at a high level as judgments that a person could perform mentally or with pen and paper. That characterization does not address the claims as written. Claim 1 recites a mock map data server to calculate combinations of cartographic feature attribute values, create corresponding geometric features, automatically arrange those features according to preconfigured rules, procedurally generate mock map data, store that data in a mock map database accessible through the mock map data server at a server URL, and cause a map client to use the provided server URL to receive and render the mock map data on a display device according to a map style taxonomy. Claims 11 and 16 recite corresponding apparatus and computer-readable-medium implementations.
These operations are not observations or judgments performable in the human mind. A person cannot mentally operate a server, encode and store procedurally generated mock map data in a map-client-compatible data structure, make the data accessible at a server URL, transmit the data to a map client, and cause the map client to render the data on a display device according to a map style taxonomy. Nor does the claim merely require a person to draw a map. The claimed process produces and serves machine-readable mock map data for consumption by a map client. The claimed server, database, URL-based access, map client, and display-device rendering are integral parts of the recited operation, not nominal field-of-use labels.
The Specification explains the scale and technical context of the process. Possible map- feature appearances can exceed 1,000 combinations, and the system calculates combinations, creates corresponding geometry, encodes the geometry as mock tile data, and serves the data to a compatible map client. See, e.g., Specification [0024], [0032]-[0033], [0055]. These are computer operations that, as a practical matter, cannot be performed in the human mind. Claim 1 therefore does not recite a mental process under Step 2A, Prong One. Claims 11 and 16, and their dependent claims, are eligible for the same reasons.
Step 2A, Prong Two - Any Alleged Exception Is Integrated into a Practical Application
Even assuming, arguendo, that one or more individual operations could be described at a high level as an abstract idea, the claims as a whole integrate those operations into a specific practical application. The claimed arrangement addresses a concrete problem in digital map-style development: real-world map data generally does not co-locate all desired cartographic feature and attribute combinations in a compact area, and manually building and maintaining taxonomy charts or custom test maps is labor intensive and error prone. See Specification [0024], [0029]-[0032].
The claimed solution is not simply "using a computer" to automate an existing mental task. The mock map data server automatically constructs geometric features for combinations of cartographic attributes, arranges them in a controlled pattern within a designated geographic area, procedurally generates map data from that pattern, exposes the resulting data through the mock map data server at a server URL, and permits an existing compatible map client to render the synthetic test data according to the map style taxonomy without programmatic changes to the map client. The ordered combination thereby creates a compact, repeatable, and interactive validation environment using the same rendering pipeline used for map data. See Specification [0032]- [0035], [0055], [0086]-[0087].
The Office Action treats receiving, storing, and providing as insignificant extra-solution activity and treats the map client as a generic computer. This separates the claims into isolated fragments. In the claimed combination, storage and URL-based service are the mechanism by which the procedurally generated map data becomes consumable by the map client. The result is a specific improvement in the technical workflow for validating and documenting map styles: many feature combinations, including combinations absent from real-world map data, can be
generated in a compact, map-compatible form and rendered interactively without manually editing production map data or creating a separate rendering application. This is a meaningful limit and practical application, not a drafting effort to monopolize a mental judgment.
At minimum, dependent claim 9 further ties the operation to an intersecting arrangement of geometric features representing different cartographic types or attribute values. That arrangement produces the intersections needed to evaluate how different styled features interact in the rendered image. See Specification [0032], [0035] and FIG. 2A. The limitation is a concrete data-generation and rendering configuration, not a mental process.
Step 2B - The Ordered Combination Supplies Significantly More
For similar reasons, the ordered combination supplies an inventive concept even if analysis proceeds to Step 2B. The rejection identifies individual computer functions as conventional but does not establish that the claimed combination (i.e., procedurally generating compact feature- combination geometry, storing it as mock map data accessible through a mock map data server at a server URL, and having a map client use that URL to render the mock data according to a map style taxonomy) was well-understood, routine, and conventional as an ordered combination. The applied prior art itself relies on multiple references to assemble portions of this architecture, which underscores that the claimed combination should not be reduced to generic data gathering and display.
For at least these reasons, independent claims 1, 11, and 16 are patent eligible under 35 U.S.C. § 101. Because claims 2-10, 12-15, and 17-20 depend respectively from claims 1, 11, and 16, they are also patent eligible under 35 U.S.C. § 101 for the same reasons as well as for the additional feature that they recite.
Accordingly, Applicants respectfully request reconsideration and withdrawal of the 35 U.S.C. § 101 rejection.
Examiners Response:
Examiner has carefully considered Applicant’s amendments and arguments and respectfully disagrees. Regarding the claimed invention, the claims as of right now merely have steps which acquire information that describes the desired features of a map and uses this information in mental processing steps that calculate, create, use, generate and render a map with the desired features. See MPEP 2106.04(a)(2), a claim to "collecting information, analyzing it, and displaying certain results of the collection and analysis," where the data analysis steps are recited at a high level of generality such that they could practically be performed in the human mind, Electric Power Group v. Alstom, S.A., 830 F.3d 1350, 1353-54, 119 USPQ2d 1739, 1741-42 (Fed. Cir. 2016). Examiner notes that a person could create a map with desired features and the use of the server is merely “apply it” as it uses a computer as a tool to perform the abstract idea (discussed in more detail below).
Furthermore, the addition of an electronic device (processor/server) that performs the recited mental steps cannot transform a patent-ineligible abstract idea into a patent-eligible invention, see MPEP 2106.04(a)(2), Nor do the courts distinguish between claims that recite mental processes performed by humans and claims that recite mental processes performed on a computer. As the Federal Circuit has explained, "[c]ourts have examined claims that required the use of a computer and still found that the underlying, patent-ineligible invention could be performed via pen and paper or in a person’s mind." Versata Dev. Group v. SAP Am., Inc., 793 F.3d 1306, 1335, 115 USPQ2d 1681, 1702 (Fed. Cir. 2015). See also Intellectual Ventures I LLC v. Symantec Corp., 838 F.3d 1307, 1318, 120 USPQ2d 1353, 1360 (Fed. Cir. 2016) (‘‘[W]ith the exception of generic computer-implemented steps, there is nothing in the claims themselves that foreclose them from being performed by a human, mentally or with pen and paper.’’); Mortgage Grader, Inc. v. First Choice Loan Servs. Inc., 811 F.3d 1314, 1324, 117 USPQ2d 1693, 1699 (Fed. Cir. 2016) (holding that computer-implemented method for "anonymous loan shopping" was an abstract idea because it could be "performed by humans without a computer"). Mental processes recited in claims that require computers are explained further below with respect to point C.…In contrast, claims do recite a mental process when they contain limitations that can practically be performed in the human mind, including for example, observations, evaluations, judgments, and opinions. Examples of claims that recite mental processes include: a claim to "collecting information, analyzing it, and displaying certain results of the collection and analysis," where the data analysis steps are recited at a high level of generality such that they could practically be performed in the human mind, Electric Power Group v. Alstom, S.A., 830 F.3d 1350, 1353-54, 119 USPQ2d 1739, 1741-42 (Fed. Cir. 2016).
Additionally, The claims do not make mention of the scale and technical context of the map creation process, it is the subject matter of the claims, not embodiments disclosed in the Specification, that we analyze. ChargePoint, Inc. v. SemaConnect, Inc., 920 F.3d 759, 769 (Fed. Cir. 2019) (“[A]ny reliance on the specification in the § 101 analysis must always yield to the claim language. . . . [T]he specification cannot be used to import details from the specification if those details are not claimed.”).
Moreover, the receiving, storing and providing are insignificant extra solution activity that merely gathers data, stores data or transmits data and do not integrate the judicial exception into a practical application, See MPEP 2106.05(g) As explained by the Supreme Court, the addition of insignificant extra-solution activity does not amount to an inventive concept, particularly when the activity is well-understood or conventional. Parker v. Flook, 437 U.S. 584, 588-89, 198 USPQ 193, 196 (1978). In Flook, the Court reasoned that "[t]he notion that post-solution activity, no matter how conventional or obvious in itself, can transform an unpatentable principle into a patentable process exalts form over substance. A competent draftsman could attach some form of post-solution activity to almost any mathematical formula". 437 U.S. at 590; 198 USPQ at 197; Id. (holding that step of adjusting an alarm limit variable to a figure computed according to a mathematical formula was "post-solution activity"). See also Mayo Collaborative Servs. v. Prometheus Labs. Inc., 566 U.S. 66, 79, 101 USPQ2d 1961, 1968 (2012) (additional element of measuring metabolites of a drug administered to a patient was insignificant extra-solution activity).
In addition, Dependent claim 9 in its current form merely describes what the pattern comprises and would not help in its current form to overcome the 101 rejection. The claim makes no mention of the arrangement being used for data-gathering and rendering purposes in its current form.
Finally, the argued improvement of a “specific improvement in the technical workflow for validating and documenting map styles: many feature combinations, including combinations absent from real-world map data, can be generated in a compact, map-compatible form and rendered interactively without manually editing production map data or creating a separate rendering application”, this improvement is never claimed in the current claims. In addition, Improving the abstract idea is not enough to integrate the abstract idea into a practical application, see Synopsys, Inc. v. Mentor Graphics Corp., 839 F.3d 1138, 1151, 120 USPQ2d 1473, 1483 (Fed. Cir. 2016) ("a *new* abstract idea is still an abstract idea") (emphasis in original)….even if the steps are groundbreaking, innovative, or brilliant, the improvement is to the abstract idea rather than to computers or technology. See Ass’n for Molecular Pathology v. Myriad Genetics, Inc., 569 U.S. 576, 591 (2013); accord SAP Am., 898 F.3d at 1163 (“No matter how much of an advance in the finance field the claims recite, the advance lies entirely in the realm of abstract ideas, with no plausibly alleged innovation in the non-abstract application realm. An advance of that nature is ineligible for patenting.”). As such, even in combination, these additional elements, under broadest reasonable interpretation, do not integrate the abstract idea into practical application because they do not impose any meaningful limitations on practicing the abstract idea.
Applicant’s amendments and/or arguments with respect to the rejection of claims 1-20 under 35 USC 103 as set forth in the office action of 04 May 2026 have been considered and are NOT persuasive. Specifically, Applicant argues:
Claims 1, 6, 7, 9, 11, and 16 stand rejected under 35 U.S.C. § 103 as being unpatentable over Brown in view of Parish in further view of Chen and in further view of Hansen. Claims 2-5, 12-15, and 17-20 stand rejected under 35 U.S.C. § 103 as being unpatentable over Brown in view of Parish, in further view of Chen, in further view of Hansen, and in further view of Thompson. Claim 8 stands rejected under 35 U.S.C. § 103 as being unpatentable over Brown in view of Parish, in further view of Chen, in further view of Hansen, and in further view of Skillen. Claim 10 stands rejected under 35 U.S.C. § 103 as being unpatentable over Brown in view of Parish, in further view of Chen, in further view of Hansen, and in further view of Chaintron.
Applicants respectfully traverse the rejections.
The Base Combination Does Not Teach or Suggest the Claimed Mock-Map Validation Architecture
The Office Action relies on Brown for receiving user input concerning map features, Parish for calculating combinations and creating geometry, Chen for arranging geometry and procedurally generating a map, and Hansen for storing and serving map data through a URL for client rendering. Even if each cited passage is accepted for what it expressly describes, the proposed aggregation does not teach or suggest the claimed architecture as a whole.
Brown simplifies or selects content from map data for presentation. Parish and Chen generate city or street networks intended to model realistic urban layouts. Those objectives differ from the claimed generation of synthetic test data that systematically enumerates cartographic feature-value combinations, creates corresponding geometric features, and equally spaces them in a compact designated area for map-style validation. The cited realistic-network generation does not disclose using preconfigured rules to construct a taxonomy-oriented test pattern in which the relevant combinations are deliberately exposed for rendering and comparison.
The distinction is substantive. The claimed pattern is not merely any procedurally generated street network. It is generated from combinations of feature attribute values, with respective geometric features created for those combinations and automatically arranged in an equally spaced pattern. The Specification describes grids, rows, strips, concentric patterns, and intersecting arrangements that deliberately concentrate combinations that may be geographically scattered or absent from real-world data. See Specification [0032], [0035], [0055]. A realistic road network generated under urban-design constraints does not teach this controlled, combination-driven test layout.
Hansen does not cure that deficiency. Hansen concerns serving optimized map tiles and using a request URL that specifies a tile and style. It does not disclose storing the specifically claimed procedurally generated mock map data in a mock map database accessible through a mock map data server at a provided server URL, in the context of the claimed combination-driven pattern, so that the map client uses that URL to receive and render the synthetic validation data. The conclusion that Hansen supplies generic URL-based map delivery does not provide the missing reason to transform Brown, Parish, and Chen into the claimed mock-map validation architecture.
The Proposed Combination Changes the References' Operating Principle and Lacks a Sufficient Rationale
The stated rationales - reducing map-creation time, making generated street maps modifiable, and reducing client data size or bandwidth - do not explain why a skilled artisan would replace realistic or optimized map content with a compact, synthetic enumeration of cartographic feature combinations arranged for style validation. The proposed modification is not a routine substitution serving the same purpose. It changes the objective from producing a realistic,
navigable, simplified, or optimized map to producing deliberately non-realistic test geometry that exposes feature combinations for visual compatibility review.
Nothing in the identified passages explains why the artisan would calculate the claimed combinations, create geometry respectively for those combinations, equally space the geometry within a designated area, and then serve the resulting mock map data through the recited mock- map server architecture. The rejection therefore uses Applicants' disclosure as a roadmap to select functions from references having materially different purposes. The asserted benefits of the individual references do not supply a rational underpinning for the claimed ordered combination or a reasonable expectation that the combination would achieve the claimed validation function.
Claim 9 Is Separately Patentable
Claim 9 further requires an intersecting arrangement in which geometric features representing different cartographic feature types or attribute values intersect one another. The rejection cites Chen's examples of roads and intersections. But an ordinary road intersection in a procedurally generated street network is not the claimed systematic intersecting arrangement of geometry representing different feature types or attribute values. The claimed arrangement is designed so that combinations of styled features can be viewed together and evaluated for visual compatibility. See Specification [0032], [0035] and FIG. 2A. Chen seeks to generate a plausible road network; it does not teach deliberately intersecting the enumerated feature-value representations to expose their styling interactions in a compact validation image. Claim 9 is therefore patentable for this additional reason.
The Examiner’s Response:
Examiner has carefully considered Applicant's arguments and respectfully disagrees. While applicant argues that “the claimed generation of synthetic test data that systematically enumerates cartographic feature-value combinations, creates corresponding geometric features, and equally spaces them in a compact designated area for map-style validation.” … “The Specification describes grids, rows, strips, concentric patterns, and intersecting arrangements that deliberately concentrate combinations that may be geographically scattered or absent from real-world data”, this is not claimed in the current claims, see MPEP 2145, Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993) (Claims to a superconducting magnet which generates a "uniform magnetic field" were not limited to the degree of magnetic field uniformity required for Nuclear Magnetic Resonance (NMR) imaging. Although the specification disclosed that the claimed magnet may be used in an NMR apparatus, the claims were not so limited.); Constant v. Advanced Micro-Devices, Inc., 848 F.2d 1560, 1571-72, 7 USPQ2d 1057, 1064-1065 (Fed. Cir.), cert. denied, 488 U.S. 892 (1988) (Various limitations on which appellant relied were not stated in the claims; the specification did not provide evidence indicating these limitations must be read into the claims to give meaning to the disputed terms.); Ex parte McCullough, 7 USPQ2d 1889, 1891 (Bd. Pat. App. & Inter. 1987) (Claimed electrode was rejected as obvious despite assertions that electrode functions differently than would be expected when used in nonaqueous battery since "although the demonstrated results may be germane to the patentability of a battery containing appellant’s electrode, they are not germane to the patentability of the invention claimed on appeal.").
In regard to, the prima facie case for the arguments, examiner notes MPEP 2145, An argument by the applicant is not evidence unless it is an admission, in which case, an examiner may use the admission in making a rejection. See MPEP § 2129 and § 2144.03 for a discussion of admissions as prior art. Arguments presented by applicant cannot take the place of evidence in the record. See In re De Blauwe, 736 F.2d 699, 705, 222 USPQ 191, 196 (Fed. Cir. 1984); In re Schulze, 346 F.2d 600, 602, 145 USPQ 716, 718 (CCPA 1965); In re Geisler, 116 F.3d 1465, 43 USPQ2d 1362 (Fed. Cir. 1997) ("An assertion of what seems to follow from common experience is just attorney argument and not the kind of factual evidence that is required to rebut a prima facie case of obviousness."). See MPEP § 716.01(c) for examples of applicant statements which are not evidence and which must be supported by an appropriate affidavit or declaration.
In addition, for the use multiple refences and obviousness, examiner notes MPEP 2145, One cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., Inc., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). Where a rejection of a claim is based on two or more references, a reply that is limited to what a subset of the applied references teaches or fails to teach, or that fails to address the combined teaching of the applied references may be considered to be an argument that attacks the reference(s) individually. Where an applicant’s reply establishes that each of the applied references fails to teach a limitation and addresses the combined teachings and/or suggestions of the applied prior art, the reply as a whole does not attack the references individually as the phrase is used in Keller and reliance on Keller would not be appropriate. This is because "[T]he test for obviousness is what the combined teachings of the references would have suggested to [a PHOSITA]." In re Mouttet, 686 F.3d 1322, 1333, 103 USPQ2d 1219, 1226 (Fed. Cir. 2012).
Under broadest reasonable interpretation, a generation and rendering of a map based on user inputs and tweaks can be taken as what is being taught by the combination of Brown, Parish, Chen and Hansen.
Finally, for dependent claim 9, applicant argues that “The claimed arrangement is designed so that combinations of styled features can be viewed together and evaluated for visual compatibility. See Specification [0032], [0035] and FIG. 2A. Chen seeks to generate a plausible road network; it does not teach deliberately intersecting the enumerated feature-value representations to expose their styling interactions in a compact validation image.”, however, this is not what the current claim states. Chen does teach the pattern comprises an intersecting arrangement in which geometric features representing different types of cartographic features, different attribute values, or a combination thereof intersect one another as seen in [Page 103.8, Section 8] “The inherent strengths of tensor fields include the possibility to model street patterns, which usually contain two preferred directions that are often mutually perpendicular. Furthermore, tensor field design allows the user to quickly generate an initial street layout which can be further modified at either the tensor field level or the graph level. This flexibility is unmatched by editing tools that only operate on the graph level, especially when creating the typical street patterns such as the regular East-West and North-South patterns.”
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
101 Analysis – Step 1
Claim 1 is directed to a method, claim 11 is directed to an apparatus and claim 16 is directed to one or more non-transitory computer-readable media. Therefore, claims 1, 11 and 16 are within at least one of the four statutory categories.
101 Analysis – Step 2A, Prong I
Regarding Prong I of the Step 2A analysis in the 2019 PEG, the claims are to be analyzed to determine whether they recite subject matter that falls within one of the follow groups of abstract ideas: a) mathematical concepts, b) certain methods of organizing human activity, and/or c) mental processes.
Independent claim 1 includes limitations that recite an abstract idea (emphasized below) and will be used as a representative claim for the remainder of the 101 rejection. The other analogous claims 11 and 16 are rejected for the same reasons as the representative claim 1 as discussed here. Claim 1 recites:
A computer-implemented method comprising:
receiving, by a mock map data server, an input specifying one or more types of cartographic features, wherein the input is received via a user interface presented on an input device;
calculating, by the mock map data server, one or more combinations of one or more feature attribute values of the one or more types of cartographic features, wherein the one or more attribute values indicate a size or a class of the one or more cartographic features;
creating, by the mock map data server, one or more geometric features respectively for one or more combinations;
using, by the mock map data server, one or more preconfigured rules to automatically arrange the one or more geometric features into a pattern that equally spaces the one or more geometric features within a designated geographic area;
procedurally generating, by the mock map data server, the mock map data based on the pattern;
storing, by the mock map data server, the mock map data in a mock map database accessible via the mock map data server at a server Uniform Resource Locator (URL),
wherein the map client uses the provided server URL to receive the mock map data and to render the mock map data in a map image on a display device based on a map style taxonomy.
The examiner submits that the foregoing bolded limitation(s) constitute a “mental process” because under its broadest reasonable interpretation, the claim covers performance of the limitation in the human mind. For example, “calculating…” all the various data in the context of this claim encompasses a person looking at data collected (received, detected, etc.) and forming a simple judgement (determination, analysis, comparison, etc.) either mentally or using a pen and paper, “creating…” involves a person taking data and making a simple judgment to create a result, “arrange…” involves a person taking data and making a simple judgement to place data in a desired order, “generating…” involves a person taking data from previous steps and making a simple judgement in order to create a result, and “render…” involves a person taking data and making a simple image from the collected data. Accordingly, the claim recites at least one abstract idea. The Examiner notes that under MPEP 2106.04(a)(2)(III), the courts consider a mental process (thinking) that "can be performed in the human mind, or by a human using a pen and paper" to be an abstract idea. CyberSource Corp. v. Retail Decisions, Inc., 654 F.3d 1366, 1372, 99 USPQ2d 1690, 1695 (Fed. Cir. 2011). As the Federal Circuit explained, "methods which can be performed mentally, or which are the equivalent of human mental work, are unpatentable abstract ideas the ‘basic tools of scientific and technological work’ that are open to all.’" 654 F.3d at 1371, 99 USPQ2d at 1694 (citing Gottschalk v. Benson, 409 U.S. 63, 175 USPQ 673 (1972)). See also Mayo Collaborative Servs. v. Prometheus Labs. Inc., 566 U.S. 66, 71, 101 USPQ2d 1961, 1965 ("‘[M]ental processes[] and abstract intellectual concepts are not patentable, as they are the basic tools of scientific and technological work’" (quoting Benson, 409 U.S. at 67, 175 USPQ at 675)); Parker v. Flook, 437 U.S. 584, 589, 198 USPQ 193, 197 (1978) (same).
101 Analysis – Step 2A, Prong II
Regarding Prong II of the Step 2A analysis in the 2019 PEG, the claims are to be analyzed to determine whether the claim, as a whole, integrates the abstract into a practical application. As noted in the 2019 PEG, it must be determined whether any additional elements in the claim beyond the abstract idea integrate the exception into a practical application in a manner that imposes a meaningful limit on the judicial exception. The courts have indicated that additional elements merely using a computer to implement an abstract idea, adding insignificant extra solution activity, or generally linking use of a judicial exception to a particular technological environment or field of use do not integrate a judicial exception into a “practical application.”
In the present case, the additional limitations beyond the above-noted abstract idea are as follows (where the underlined portions are the “additional limitations” while the bolded portions continue to represent the “abstract idea”):
A computer-implemented method comprising:
receiving, by a mock map data server, an input specifying one or more types of cartographic features, wherein the input is received via a user interface presented on an input device;
calculating, by the mock map data server, one or more combinations of one or more feature attribute values of the one or more types of cartographic features, wherein the one or more attribute values indicate a size or a class of the one or more cartographic features;
creating, by the mock map data server, one or more geometric features respectively for one or more combinations;
using, by the mock map data server, one or more preconfigured rules to automatically arrange the one or more geometric features into a pattern that equally spaces the one or more geometric features within a designated geographic area;
procedurally generating, by the mock map data server, the mock map data based on the pattern;
storing, by the mock map data server, the mock map data in a mock map database accessible via the mock map data server at a server Uniform Resource Locator (URL),
wherein the map client uses the provided server URL to receive the mock map data and to render the mock map data in a map image on a display device based on a map style taxonomy.
For the following reason(s), the examiner submits that the above identified additional limitations do not integrate the above-noted abstract idea into a practical application.
Regarding the additional limitations above, the examiner submits that these limitations are insignificant extra-solution activities that merely use a computer (processor) to perform the process. In particular, the receiving, storing and providing steps are recited at a high level of generality (i.e. as a general means of receiving information and providing information for use in the other steps), and amounts to mere data gathering, which is a form of insignificant extra-solution activity. Lastly, claims 1, 11 and 16 further recite “A computer-implemented method comprising “A computer-implemented method comprising…. by a mock map data server”, “An apparatus comprising: at least one processor; and at least one memory including computer program code for one or more programs, the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus to perform at least the following” and “A non-transitory computer readable storage medium carrying one or more sequences of one or more instructions which, when the one or more instructions are executed by one or more processors, cause an apparatus to perform” merely describes how to generally “apply” the otherwise mental judgements in a generic or general purpose vehicle control environment. See Alice Corp. Pty. Ltd. v. CLS Bank Int'l, 573 U.S. at 223 (“[T]he mere recitation of a generic computer cannot transform a patent-ineligible abstract idea into a patent-eligible invention.”). The device(s) and processor(s) are recited at a high level of generality and merely automates the steps.
Thus, taken alone, the additional elements do not integrate the abstract idea into a practical application. Further, looking at the additional limitation(s) as an ordered combination or as a whole, the limitation(s) add nothing that is not already present when looking at the elements taken individually. For instance, there is no indication that the additional elements, when considered as a whole, reflect an improvement in the functioning of a computer or an improvement to another technology or technical field, apply or use the above-noted judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition, implement/use the above-noted judicial exception with a particular machine or manufacture that is integral to the claim, effect a transformation or reduction of a particular article to a different state or thing, or apply or use the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment, such that the claim as a whole is not more than a drafting effort designed to monopolize the exception (MPEP § 2106.05). Accordingly, the additional limitation(s) do/does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea.
101 Analysis – Step 2B
Regarding Step 2B of the 2019 PEG, as discussed above with respect to integration of the abstract idea into a practical application, the additional element of using a processor to perform the procedural generation step amounts to nothing more than applying the exception using a generic computer component. Generally applying an exception using a generic computer component cannot provide an inventive concept. And as discussed above, the additional limitations discussed above are insignificant extra-solution activities.
The additional limitations of receiving, storing and providing information would fall under the notion of receiving or transmitting data over a network. MPEP 2106.05(d)(II), Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network); but see DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245, 1258, 113 USPQ2d 1097, 1106 (Fed. Cir. 2014) ("Unlike the claims in Ultramercial, the claims at issue here specify how interactions with the Internet are manipulated to yield a desired result‐‐a result that overrides the routine and conventional sequence of events ordinarily triggered by the click of a hyperlink." (emphasis added));. The additional limitation of “renders the mock map …,” is a well-understood, routine, and conventional activity because the Federal Circuit in Trading Techs. Int’l v. IBG LLC, 921 F.3d 1084, 1093 (Fed. Cir. 2019), and Intellectual Ventures I LLC v. Erie Indemnity Co., 850 F.3d 1315, 1331 (Fed. Cir. 2017), for example, indicated that the mere performance which in the instant application is creating a map is a well understood, routine, and conventional function. Hence, the claim is not patent eligible.
Dependent claims 2-10, 12-15 and 17-20 do not recite any further limitations that cause the claims to be patent eligible. The dependent claims merely define scenarios and terms. Rather, the limitations of dependent claims are directed toward additional aspects of the judicial exception and/or additional elements that do not integrate the judicial exception into a practical application. Therefore, dependent claims 2-10, 12-15 and 17-20 are not patent eligible.
Therefore, claims 1-20 are ineligible under 35 USC §101.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 6-7, 9, 11 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Brown (US 20200394753 A1) in further view of Parish (“Procedural Modeling of Cities”, 2001) in further view of Chen (“Interactive Procedural Street Modeling”, 2008) in further view of Hansen (US 20180181576 A1).
Regarding Claim 1, Brown teaches A computer-implemented method comprising (see at least [¶02 & 035-036]):
receiving, by a mock map data server, an input specifying one or more types of cartographic features, wherein the input is received via a user interface presented on an input device (Receiving, by a mapping server, a user input through an interface that specifies one or more type of map/cartographic feature to include or exclude in the simplified map tile. see at least [¶045-047 & 0113]);
Brown does not explicitly teach calculating, by the mock map data server, one or more combinations of one or more feature attribute values of the one or more types of cartographic features, wherein the one or more attribute values indicate a size or a class of the one or more cartographic features; creating, by the mock map data server, one or more geometric features respectively for one or more combinations.
However, Parish does teach calculating, by the mock map data server, one or more combinations of one or more feature attribute values of the one or more types of cartographic features, wherein the one or more attribute values indicate a size or a class of the one or more cartographic features (The system is able to determine constraints defining map features based on factors such as population and road types and create/calculate combinations to be used when procedurally generating a city map based on the constraints. see at least [Page 303, Section 3.1, Paragraph 3-4 & Page 304, Section 3.2.2, Paragraph 1-4]);
creating, by the mock map data server, one or more geometric features respectively for one or more combinations (Creating, one or more geometric features for the calculated combinations (which can be saved for later use). The geometric feature can be a map tile that uses the calculated combination to create a street network in a desired layout. see at least [Page 304, Section 3.2.2, Paragraph 1-4 & FIG 7]).
Parish would be in a similar field as it also deals in the area of map generation for a city. Therefore, it would have been obvious to those having ordinary skill in the art before the effective filing date of the instant application to modify Brown to use the technique of calculating, by the mock map data server, one or more combinations of one or more feature attribute values of the one or more types of cartographic features, wherein the one or more attribute values indicate a size or a class of the one or more cartographic features; creating, by the mock map data server, one or more geometric features respectively for one or more combinations as taught by Parish. Doing so would lead to decreased time for the creation of a dense city map (see at least [Page 307, Section 5, Paragraph 1-2]).
Brown and Parish do not explicitly teach using, by the mock map data server, one or more preconfigured rules to automatically arrange the one or more geometric features into a pattern that equally spaces the one or more geometric features within a designated geographic area; procedurally generating, by the mock map data server, the mock map data based on the pattern.
However, Chen does teach using, by the mock map data server, one or more preconfigured rules to automatically arrange the one or more geometric features into a pattern that equally spaces the one or more geometric features within a designated geographic area (Preconfigured rules and user inputs are used to automatically arrange geometric features, such as roads, into a pattern that equally space the geometric features into a designated geographic area. see at least [Page 103.3-103.5, Section 5.1, Paragraph 1-4, Fig 4, Fig 5 and Fig 8])
procedurally generating, by the mock map data server, the mock map data based on the pattern (Procedurally generating a mock map based on the patterns. see at least [Page 103.3-103.5, Section 5.1, Paragraph 1-4, Page 103.7-103.8, Section 7-8 & FIG 16-18]).
Chen would be in a similar field as it also deals in the area of procedural generation of maps. Therefore, it would have been obvious to those having ordinary skill in the art before the effective filing date of the instant application to modify Brown and Parish to use the technique of using, by the mock map data server, one or more preconfigured rules to automatically arrange the one or more geometric features into a pattern that equally spaces the one or more geometric features within a designated geographic area; procedurally generating, by the mock map data server, the mock map data based on the pattern as taught by Chen. Doing so would lead to improving the generation of street maps that are further modifiable (see at least [Page 103.8, Section 8, Paragraph 1-2]).
Brown, Parish and Chen do not explicitly teach storing, by the mock map data server, the mock map data in a mock map database accessible via the mock map data server at a server Uniform Resource Locator (URL), wherein the map client uses the provided server URL to receive the mock map data and to render the mock map data in a map image on a display device based on a map style taxonomy.
However, Hansen does teach storing, by the mock map data server, the mock map data in a mock map database accessible via the mock map data server at a server Uniform Resource Locator (URL) (The map data is stored in a database that is accessible to the mapping server via a URL. see at least [¶044, 048-051, 053-054, 073, 077 & 082-087]),
wherein the map client uses the provided server URL to receive the mock map data and to render the mock map data in a map image on a display device based on a map style taxonomy (The map client is able to receive the map data from the server URL and display the rendered map data using the desired map style. see at least [¶053-054, 077 & 083-087]).
Hansen would be in a similar field as it also deals in the area of map style and map client rendering. Therefore, it would have been obvious to those having ordinary skill in the art before the effective filing date of the instant application to modify Brown, Parish and Chen to use the technique of storing, by the mock map data server, the mock map data in a mock map database accessible via the mock map data server at a server Uniform Resource Locator (URL), wherein the map client uses the provided server URL to receive the mock map data and to render the mock map data in a map image on a display device based on a map style taxonomy as taught by Hansen. Doing so would lead to reductions in data size, use of network bandwidth, and use of CPU cycles at the client computing device when obtaining map data from a remote server (see at least [¶098]).
Regarding Claim 6, Brown, Parish, Chen and Hansen teach all of the limitations of claim 1 as shown above, furthermore, Parish teaches wherein the map image is rendered in three dimensions (The map image can be rendered in 3D. see at least [FIG 16 & 17]).
Parish would be in a similar field as it also deals in the area of map generation for a city. Therefore, it would have been obvious to those having ordinary skill in the art before the effective filing date of the instant application to modify Brown, Chen and Hansen to use the technique of having the map image is rendered in three dimensions as taught by Parish. Doing so would lead to improved creation of a dense city (see at least [Page 307, Section 5, Paragraph 1-2]).
Regarding Claim 7, Brown, Parish, Chen and Hansen teach all of the limitations of claim 6 as shown above, furthermore, Parish teaches wherein the three dimensions visually distinguish building heights, land use types, or a combination thereof in the mock map data (The 3D image can visually distinguish building with different heights and different types of lands. see at least [FIG 16 & 17]).
Parish would be in a similar field as it also deals in the area of map generation for a city. Therefore, it would have been obvious to those having ordinary skill in the art before the effective filing date of the instant application to modify Brown, Chen and Hansen to use the technique of having the three dimensions visually distinguish building heights, land use types, or a combination thereof in the mock map data as taught by Parish. Doing so would lead to improved creation of a dense city (see at least [Page 307, Section 5, Paragraph 1-2]).
Regarding Claim 9, Brown, Parish, Chen and Hansen teach all of the limitations of claim 1 as shown above, furthermore, Chen teaches wherein the pattern comprises an intersecting arrangement in which geometric features representing different types of cartographic features, different attribute values, or a combination thereof intersect one another (Preconfigured rules and user inputs are used to automatically arrange geometric features, such as roads, into a pattern that includes intersecting different road types, roads of different sizes, and line widths. see at least [Page 103.3-103.5, Section 5.1, Paragraph 1-4, Page 103.8, Section 8, Fig 4, Fig 5 and Fig 8])
Chen would be in a similar field as it also deals in the area of procedural generation of maps. Therefore, it would have been obvious to those having ordinary skill in the art before the effective filing date of the instant application to modify Brown, Parish and Hansen to use the technique of having the arrangement includes pattern comprises an intersecting arrangement in which geometric features representing different types of cartographic features, different attribute values, or a combination thereof intersect one another as taught by Chen. Doing so would lead to improving the generation of street maps that are further modifiable (see at least [Page 103.8, Section 8, Paragraph 1-2]).
Regarding Claim 11, Brown teaches An apparatus comprising: at least one processor; and at least one memory including computer program code for one or more programs, the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus to perform at least the following, (see at least [¶025 & Fig 1]):
receiving, by a mock map data server, an input specifying one or more types of cartographic features, wherein the input is received via a user interface presented on an input device (Receiving, by a mapping server, a user input through an interface that specifies one or more type of map/cartographic feature to include or exclude in the simplified map tile. see at least [¶045-047 & 0113]);
Brown does not explicitly teach calculating, by the mock map data server, one or more combinations of one or more feature attribute values of the one or more types of cartographic features, wherein the one or more attribute values indicate a size or a class of the one or more cartographic features; creating, by the mock map data server, one or more geometric features respectively for one or more combinations.
However, Parish does teach calculating, by the mock map data server, one or more combinations of one or more feature attribute values of the one or more types of cartographic features, wherein the one or more attribute values indicate a size or a class of the one or more cartographic features (The system is able to determine constraints defining map features based on factors such as population and road types and create/calculate combinations to be used when procedurally generating a city map based on the constraints. see at least [Page 303, Section 3.1, Paragraph 3-4 & Page 304, Section 3.2.2, Paragraph 1-4]);
creating, by the mock map data server, one or more geometric features respectively for one or more combinations (Creating, one or more geometric features for the calculated combinations (which can be saved for later use). The geometric feature can be a map tile that uses the calculated combination to create a street network in a desired layout. see at least [Page 304, Section 3.2.2, Paragraph 1-4 & FIG 7]).
Parish would be in a similar field as it also deals in the area of map generation for a city. Therefore, it would have been obvious to those having ordinary skill in the art before the effective filing date of the instant application to modify Brown to use the technique of calculating, by the mock map data server, one or more combinations of one or more feature attribute values of the one or more types of cartographic features, wherein the one or more attribute values indicate a size or a class of the one or more cartographic features; creating, by the mock map data server, one or more geometric features respectively for one or more combinations as taught by Parish. Doing so would lead to decreased time for the creation of a dense city map (see at least [Page 307, Section 5, Paragraph 1-2]).
Brown and Parish do not explicitly teach using, by the mock map data server, one or more preconfigured rules to automatically arrange the one or more geometric features into a pattern that equally spaces the one or more geometric features within a designated geographic area; procedurally generating, by the mock map data server, the mock map data based on the pattern.
However, Chen does teach using, by the mock map data server, one or more preconfigured rules to automatically arrange the one or more geometric features into a pattern that equally spaces the one or more geometric features within a designated geographic area (Preconfigured rules and user inputs are used to automatically arrange geometric features, such as roads, into a pattern that equally space the geometric features into a designated geographic area. see at least [Page 103.3-103.5, Section 5.1, Paragraph 1-4, Fig 4, Fig 5 and Fig 8])
procedurally generating, by the mock map data server, the mock map data based on the pattern (Procedurally generating a mock map based on the patterns. see at least [Page 103.3-103.5, Section 5.1, Paragraph 1-4, Page 103.7-103.8, Section 7-8 & FIG 16-18]).
Chen would be in a similar field as it also deals in the area of procedural generation of maps. Therefore, it would have been obvious to those having ordinary skill in the art before the effective filing date of the instant application to modify Brown and Parish to use the technique of using, by the mock map data server, one or more preconfigured rules to automatically arrange the one or more geometric features into a pattern that equally spaces the one or more geometric features within a designated geographic area; procedurally generating, by the mock map data server, the mock map data based on the pattern as taught by Chen. Doing so would lead to improving the generation of street maps that are further modifiable (see at least [Page 103.8, Section 8, Paragraph 1-2]).
Brown, Parish and Chen do not explicitly teach storing, by the mock map data server, the mock map data in a mock map database accessible via the mock map data server at a server Uniform Resource Locator (URL), wherein the map client uses the provided server URL to receive the mock map data and to render the mock map data in a map image on a display device based on a map style taxonomy.
However, Hansen does teach storing, by the mock map data server, the mock map data in a mock map database accessible via the mock map data server at a server Uniform Resource Locator (URL) (The map data is stored in a database that is accessible to the mapping server via a URL. see at least [¶044, 048-051, 053-054, 073, 077 & 082-087]),
wherein the map client uses the provided server URL to receive the mock map data and to render the mock map data in a map image on a display device based on a map style taxonomy (The map client is able to receive the map data from the server URL and display the rendered map data using the desired map style. see at least [¶053-054, 077 & 083-087]).
Hansen would be in a similar field as it also deals in the area of map style and map client rendering. Therefore, it would have been obvious to those having ordinary skill in the art before the effective filing date of the instant application to modify Brown, Parish and Chen to use the technique of storing, by the mock map data server, the mock map data in a mock map database accessible via the mock map data server at a server Uniform Resource Locator (URL), wherein the map client uses the provided server URL to receive the mock map data and to render the mock map data in a map image on a display device based on a map style taxonomy as taught by Hansen. Doing so would lead to reductions in data size, use of network bandwidth, and use of CPU cycles at the client computing device when obtaining map data from a remote server (see at least [¶098]).
Regarding Claim 16, Brown teaches A non-transitory computer readable storage medium carrying one or more sequences of one or more instructions which, when the one or more instructions are executed by one or more processors, cause an apparatus to perform: (see at least [¶02, 017, 044 & Fig 2]):
receiving, by a mock map data server, an input specifying one or more types of cartographic features, wherein the input is received via a user interface presented on an input device (Receiving, by a mapping server, a user input through an interface that specifies one or more type of map/cartographic feature to include or exclude in the simplified map tile. see at least [¶045-047 & 0113]);
Brown does not explicitly teach calculating, by the mock map data server, one or more combinations of one or more feature attribute values of the one or more types of cartographic features, wherein the one or more attribute values indicate a size or a class of the one or more cartographic features; creating, by the mock map data server, one or more geometric features respectively for one or more combinations.
However, Parish does teach calculating, by the mock map data server, one or more combinations of one or more feature attribute values of the one or more types of cartographic features, wherein the one or more attribute values indicate a size or a class of the one or more cartographic features (The system is able to determine constraints defining map features based on factors such as population and road types and create/calculate combinations to be used when procedurally generating a city map based on the constraints. see at least [Page 303, Section 3.1, Paragraph 3-4 & Page 304, Section 3.2.2, Paragraph 1-4]);
creating, by the mock map data server, one or more geometric features respectively for one or more combinations (Creating, one or more geometric features for the calculated combinations (which can be saved for later use). The geometric feature can be a map tile that uses the calculated combination to create a street network in a desired layout. see at least [Page 304, Section 3.2.2, Paragraph 1-4 & FIG 7]).
Parish would be in a similar field as it also deals in the area of map generation for a city. Therefore, it would have been obvious to those having ordinary skill in the art before the effective filing date of the instant application to modify Brown to use the technique of calculating, by the mock map data server, one or more combinations of one or more feature attribute values of the one or more types of cartographic features, wherein the one or more attribute values indicate a size or a class of the one or more cartographic features; creating, by the mock map data server, one or more geometric features respectively for one or more combinations as taught by Parish. Doing so would lead to decreased time for the creation of a dense city map (see at least [Page 307, Section 5, Paragraph 1-2]).
Brown and Parish do not explicitly teach using, by the mock map data server, one or more preconfigured rules to automatically arrange the one or more geometric features into a pattern that equally spaces the one or more geometric features within a designated geographic area; procedurally generating, by the mock map data server, the mock map data based on the pattern.
However, Chen does teach using, by the mock map data server, one or more preconfigured rules to automatically arrange the one or more geometric features into a pattern that equally spaces the one or more geometric features within a designated geographic area (Preconfigured rules and user inputs are used to automatically arrange geometric features, such as roads, into a pattern that equally space the geometric features into a designated geographic area. see at least [Page 103.3-103.5, Section 5.1, Paragraph 1-4, Fig 4, Fig 5 and Fig 8])
procedurally generating, by the mock map data server, the mock map data based on the pattern (Procedurally generating a mock map based on the patterns. see at least [Page 103.3-103.5, Section 5.1, Paragraph 1-4, Page 103.7-103.8, Section 7-8 & FIG 16-18]).
Chen would be in a similar field as it also deals in the area of procedural generation of maps. Therefore, it would have been obvious to those having ordinary skill in the art before the effective filing date of the instant application to modify Brown and Parish to use the technique of using, by the mock map data server, one or more preconfigured rules to automatically arrange the one or more geometric features into a pattern that equally spaces the one or more geometric features within a designated geographic area; procedurally generating, by the mock map data server, the mock map data based on the pattern as taught by Chen. Doing so would lead to improving the generation of street maps that are further modifiable (see at least [Page 103.8, Section 8, Paragraph 1-2]).
Brown, Parish and Chen do not explicitly teach storing, by the mock map data server, the mock map data in a mock map database accessible via the mock map data server at a server Uniform Resource Locator (URL), wherein the map client uses the provided server URL to receive the mock map data and to render the mock map data in a map image on a display device based on a map style taxonomy.
However, Hansen does teach storing, by the mock map data server, the mock map data in a mock map database accessible via the mock map data server at a server Uniform Resource Locator (URL) (The map data is stored in a database that is accessible to the mapping server via a URL. see at least [¶044, 048-051, 053-054, 073, 077 & 082-087]),
wherein the map client uses the provided server URL to receive the mock map data and to render the mock map data in a map image on a display device based on a map style taxonomy (The map client is able to receive the map data from the server URL and display the rendered map data using the desired map style. see at least [¶053-054, 077 & 083-087]).
Hansen would be in a similar field as it also deals in the area of map style and map client rendering. Therefore, it would have been obvious to those having ordinary skill in the art before the effective filing date of the instant application to modify Brown, Parish and Chen to use the technique of storing, by the mock map data server, the mock map data in a mock map database accessible via the mock map data server at a server Uniform Resource Locator (URL), wherein the map client uses the provided server URL to receive the mock map data and to render the mock map data in a map image on a display device based on a map style taxonomy as taught by Hansen. Doing so would lead to reductions in data size, use of network bandwidth, and use of CPU cycles at the client computing device when obtaining map data from a remote server (see at least [¶098]).
Claims 2-5, 12-15 and 17-20 are rejected under 35 U.S.C. 103 as being unpatentable over Brown (US 20200394753 A1) in further view of Parish (“Procedural Modeling of Cities”, 2001) in further view of Chen (“Interactive Procedural Street Modeling”, 2008) in view of Hansen (US 20180181576 A1) in further view of Thompson (US 20190128679 A1).
Regarding Claims 2, 12 and 17, Brown, Parish, Chen and Hansen teach all of the limitations of claims 1, 11 and 16 as shown above, Brown, Parish, Chen and Hansen do not explicitly teach wherein the map client provides for interactivity with the mock map data.
However, Thompson does teach wherein the map client provides for interactivity with the mock map data (The map client provides the user with interactivity of the displayed map data. see at least [¶050]).
Thompson would be in a similar field as it also deals in the area of viewing map data from vector tiles. Therefore, it would have been obvious to those having ordinary skill in the art before the effective filing date of the instant application to modify Brown, Parish, Chen and Hansen to use the technique of having the map client provides for interactivity with the mock map data as taught by Thompson. Doing so would lead to improved viewing of displayed map data while a user interacts with a map (see at least [¶05]).
Regarding Claims 3, 13 and 18, Brown, Parish, Chen, Hansen and Thompson teach all of the limitations of claims 2, 12 and 17 as shown above, furthermore, Thompson teaches wherein the interactivity includes changing map zoom levels of the mock map data in the map image (The map client provides the user with interactivity of the displayed map data, such as adjusting the map zoom level. see at least [¶050]).
Thompson would be in a similar field as it also deals in the area of viewing map data from vector tiles. Therefore, it would have been obvious to those having ordinary skill in the art before the effective filing date of the instant application to modify Brown, Parish, Chen and Hansen to use the technique of having the interactivity includes changing map zoom levels of the mock map data in the map image as taught by Thompson. Doing so would lead to improved viewing of displayed map data while a user interacts with a map (see at least [¶05]).
Regarding Claims 4, 14 and 19, Brown, Parish, Chen, Hansen and Thompson teach all of the limitations of claims 2, 12 and 17 as shown above, furthermore, Thompson teaches wherein the interactivity includes panning the mock map data in the map image (The map client provides the user with interactivity of the displayed map data, such as panning the map. see at least [¶050]).
Thompson would be in a similar field as it also deals in the area of viewing map data from vector tiles. Therefore, it would have been obvious to those having ordinary skill in the art before the effective filing date of the instant application to modify Brown, Parish, Chen and Hansen to use the technique of having the interactivity includes panning the mock map data in the map image as taught by Thompson. Doing so would lead to improved viewing of displayed map data while a user interacts with a map (see at least [¶05]).
Regarding Claims 5, 15 and 20, Brown, Parish, Chen and Hansen teach all of the limitations of claims 1, 11 and 16 as shown above, Brown, Parish, Chen and Hansen do not explicitly teach wherein the designated geographic area is based on a location specified in the user interface (The map client provides the user the ability to specify a geographic area based on the specified location. see at least [¶050]).
Thompson would be in a similar field as it also deals in the area of viewing map data from vector tiles. Therefore, it would have been obvious to those having ordinary skill in the art before the effective filing date of the instant application to modify Brown, Parish, Chen and Hansen to use the technique of having the designated geographic area is based on a location specified in the user interface as taught by Thompson. Doing so would lead to improved viewing of displayed map data while a user interacts with a map (see at least [¶05]).
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Brown (US 20200394753 A1) in further view of Parish (“Procedural Modeling of Cities”, 2001) in further view of Chen (“Interactive Procedural Street Modeling”, 2008) in view of Hansen (US 20180181576 A1) in further view of Skillen (US 20060285152 A1).
Regarding Claim 8, Brown, Parish, Chen and Hansen teach all of the limitations of claim 1 as shown above, Brown, Parish, Chen and Hansen do not explicitly teach wherein the map client exports the map image to a selected file format.
However, Skillen does teach wherein the map client exports the map image to a selected file format (The map client can export map images to a selected file format (such as PDF).see at least [¶06, 011, 031 & 053]).
Skillen would be in a similar field as it also deals in the area of exporting map data. Therefore, it would have been obvious to those having ordinary skill in the art before the effective filing date of the instant application to modify Brown, Parish, Chen and Hansen to use the technique of having the map client exports the map image to a selected file format as taught by Skillen. Doing so would lead to improved exporting of relevant map data to users in a different format (see at least [¶031]).
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Brown (US 20200394753 A1) in further view of Parish (“Procedural Modeling of Cities”, 2001) in further view of Chen (“Interactive Procedural Street Modeling”, 2008) in view of Hansen (US 20180181576 A1) in further view of Chaintron (US 20190370361 A1).
Regarding Claim 10, Brown, Parish, Chen and Hansen teach all of the limitations of claim 1 as shown above, Brown, Parish, Chen and Hansen do not explicitly teach wherein the rendering of the map image is used for performance testing of the map client.
However, Chaintron does teach wherein the rendering of the map image is used for performance testing of the map client (Rendering of the map image is used to testing the performance of the map client. see at least [¶041-045]).
Chaintron would be in a similar field as it also deals in the area of testing client rendering capabilities. Therefore, it would have been obvious to those having ordinary skill in the art before the effective filing date of the instant application to modify Brown, Parish, Chen and Hansen to use the technique of having the rendering of the map image is used for performance testing of the map client as taught by Chaintron. Doing so would lead to determining the actual capabilities of a client’s map module (see at least [¶043]).
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner
should be directed to MOISES GASCA ALVA JR whose telephone number is (571)272-3752. The examiner
can normally be reached Monday-Friday 6:30 - 4: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,
Faris Almatrahi can be reached on (313) 446-4821. 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.
/MOISES GASCA ALVA/Examiner, Art Unit 3667
/FARIS S ALMATRAHI/Supervisory Patent Examiner, Art Unit 3667
