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 .
Status of Claims
This action is in reply to the amendments filed on 03/30/2026 for Application No. 18/273,038.
Claims 1 – 6, 8 – 19 and 22 are currently pending and have been examined. Claims 1, 3, 15, 17 and 22 have been amended.
This action is made NON-FINAL.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 03/30/2026 has been entered.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 1 – 6, 8 – 19 and 22 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 1 states: “determining a canvas height and a canvas width according to the height, the width, the container height and the container width”, however it is indefinite to what “the height” and “the width” are referring to. Claim 1 also states: “to determine a height and a width of the target area”, however due to how many parameters have height and width (i.e. canvas height, canvas width, container height, container width), it is indefinite to fully interpret what the “height” and “width” are referring to unless they are specified. Therefore, the claim will be interpreted as determining a canvas height and canvas width according to the container height and container width.
Claim 2 states: “wherein determining the canvas height and the canvas width comprises:
determining that the canvas width is equal to the container width in response to determining that the width is greater than the height, and determining the canvas height according to a product of the canvas width and a ratio of the height to the width;
and/or determining that the canvas height is equal to the container height in response to determining that the height is greater than the width, and determining the canvas width according to a product of the canvas height and a ratio of the width to the height”, however it is indefinite to what the various unidentified “width” and “height” correspond to. In claim 1, which claim 2 is dependent upon, states: “to determine a height and a width of the target area”, however it is indefinite if the width and height also correspond to the target area. For this reason the claim will be interpreted as being able to determine the canvas width (or height) is equal to the container width (or height) and having the functionality of determining the canvas height (or width).
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are:
“geometry utility function library for” in claims 15 and 22.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
This application includes one or more claim limitations that use the word “means” or “step” but are nonetheless not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph because the claim limitation(s) recite(s) sufficient structure, materials, or acts to entirely perform the recited function. Such claim limitation(s) is/are:
“container for” in claims 15 and 22.
“target area for” in claims 15 and 22.
Because this/these claim limitation(s) is/are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are not being interpreted to cover only the corresponding structure, material, or acts described in the specification as performing the claimed function, and equivalents thereof.
If applicant intends to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to remove the structure, materials, or acts that performs the claimed function; or (2) present a sufficient showing that the claim limitation(s) does/do not recite sufficient structure, materials, or acts to perform the claimed function.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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 – 5 , 8 – 19 and 22 are rejected under 35 U.S.C. 103 as being unpatentable over Arikan et al. (US 9489754 B2), further in view of Cornell et al. (US 20130093750 A1).
Regarding claim 1, Arikan teaches a map generation method, performed by a browser of a terminal and comprising: (Arikan: Abstract: “Some embodiments provide a method for a mapping service. The method receives a set of road segments for a map region. For each road segment in the set, the method generates a geometry that includes a set of vertices that define a boundary for the road segment. The geometries are included as part of a map tile for the map region. The map tiles are for downloading to user devices that render map presentations using the geometries. For several of the vertices, the method stores data with the vertices that specifies for the device at least one aspect of rendering the road for the map presentation.”: Col. 7, lines 16 – 30 : “The navigation application of some embodiments is part of an integrated mapping application that includes several useful modalities, including location browsing, map searching, route identifying and route navigating operations. This integrated application (referred to below as the mapping application, the navigation application or the integrated application) in some embodiments is defined to be executed by a device that has a touch-sensitive screen that displays the output of the application. In some embodiments, this device has a multi-touch interface for allowing a user to provide touch and gestural inputs through the screen to interact with the application. Examples of such devices are smartphones (e.g., iPhone® sold by Apple Inc., phones operating the Android® operating system, phones operating the Windows 8® operating system, etc.).”)
loading a function of displaying and/or drawing maps in a server, and (Arikan: Col. 14, lines 23 – 32: “In order to display both immersive and non-immersive 3D map presentations, some embodiments have to generate a variety of tiles for client devices to render to generate roads, building, and surrounding scenery. In some embodiments, examples of such tiles include road and building tiles used for non-immersive 3D presentations, and navigation and building tiles used for immersive 3D presentations. Before generating these tiles, a set of servers has to generate the description of the road, building, and other geometries that are placed in each of the tiles.”)
calling an application programming interface (API) of the server, (Arikan: Col. 2, lines 1 – 16: “Before generating these tiles, a set of servers has to generate the description of the road, building, and other geometries that are placed in each of the tiles. This task involves multiple sub-tasks such as (1) receiving map data from a variety of vendors, (2) processing such data to produce one dimensional (1D) roads, (3) smoothing the 1D road graphs, (4) defining data to specify intersections, (5) generating 2D road geometries and land cover, (6) smoothing the 2D road geometries, (7) generating data (e.g., estimated height data) regarding buildings, (8) using such data to define building geometries, (9) constructing road geometries details (such as islands, lane markings, and distances and land cover between road geometries), and (10) identifying geometry edge node characteristics and propagating such characteristics.”,
Supplemental Note: the server data is able to provide data of geometry data of the map features to the device with the application)
wherein the API provides a geometry utility function library for calculating spatial information corresponding to the function; (Arikan: Col. 11, lines 6 – 32: “The navigation application of some embodiments is capable of displaying navigation maps from multiple perspectives. The application can show maps in three dimensions (3D) or in two dimensions (2D). The 3D maps are generated simulations of a virtual scene as seen by a virtual camera. FIG. 3 presents a simplified example to illustrate the concept of a virtual camera 312. When rendering a 3D navigation map, a virtual camera is a conceptualization of the position in the 3D map scene from which the device renders a 3D view of the scene. FIG. 3 illustrates a location in a 3D navigation map scene 310 that includes four objects, which are two buildings and two intersecting roads. To illustrate the virtual camera concept, this figure illustrates three scenarios, each of which corresponds to a different virtual camera location (i.e., a different rendering position) and a different resulting view that is displayed on the device. The first stage 301 shows the virtual camera 312 at a first position pointing downwards at an angle (e.g., a 30° angle) towards the 3D scene 310. By rendering the 3D scene from the position and angle shown in stage 301 the application generates the 3D map view 318. From this position, the camera is pointing at a location that is a moving position in front of the device. The virtual camera 312 is kept behind the current location of the device. “Behind the current location” in this case means backward along the navigation application's defined path in the opposite direction from the current direction that the device is moving in.”,
Supplemental Note: the application which can show maps in 3D or 2D are interpreted as the geometry utility function library)
receiving an identifier input by a user and determining a target area corresponding to the identifier; (Arikan: Col. 7, lines 66 – Col. 8, line 27: “In some embodiments, a user can initiate a search by tapping in the search field 165. This directs the application to present an animation that (1) presents an on-screen keyboard and (2) opens a search table full of invaluable completions. This table has some important subtleties. When the search field is tapped and before the terms are edited, or when the search field is empty, the table contains a list of “recents,” which in some embodiments are recent searches and route directions that the user has requested. This makes it very easy to quickly bring up recently accessed results. After any edit in the search field, the table is filled with search completions both from local sources (e.g., bookmarks, contacts, recent searches, recent route directions, etc.) and remote servers. The incorporation of the user's contact card into the search interface adds additional flexibility to the design. When showing recents, a route from the current location to the user's home is always offered in some embodiments, while it is offered in the contexts that are deemed to be “appropriate” in other embodiments. Also, when the search term matches at least part of an address label (e.g. ‘Wo’ or ‘ork’ for ‘Work’), the application presents the user's labeled address as a completion in the search table in some embodiments. Together these behaviors make the search UI a very powerful way to get results onto a map from a variety of sources. In addition to allowing a user to initiate a search, the presence of the text field in the primary map view in some embodiments also allows users to see the query corresponding to search results on the map and to remove those search results by clearing the query.”,
Supplemental Note: the identifier is interpreted as the area the user wants to search)
processing, through the geometry utility function library, geographic information of the target area, (Arikan: Col. 11, lines 45 – 57: “The second stage 302 shows the virtual camera 312 at a different position, pointing downwards towards the scene 310 at a larger second angle (e.g., a 45° angle). The application renders the scene 310 from this angle, resulting in the 3D navigation map view 328. The buildings and the roads are smaller than their illustration in the first navigation map view 318. Once again the virtual camera 312 is above and behind the location indicator 326 in the scene 310. This again results in the location indicator appearing in the lower part of the 3D map view 328. The location and orientation of the camera also results again in the majority of the screen displaying things ahead of the car, which is what someone navigating needs to know.”,
Supplemental Note: geographic information of the building and roads surrounding are used to show a 3D navigation view)
… coordinates of one or more feature points in the target area; (Arikan: Col. 18, lines 21 – 27: “As shown, the geometry information includes centerline path data (e.g., an ordered string of coordinates that define the center of the road), start and end junction information, parameters to indicate the width and offset with respect to the centerline, and functionality enabling evaluation of the sides of the road at any point along the road segment.”,
Supplemental Note: the geometry information includes a string of coordinates representing the center of the road).
In sum, Arikan teaches a map generation method, performed by a browser of a terminal and comprising: loading a function of displaying and/or drawing maps in a server, and calling an application programming interface (API) of the server, wherein the API provides a geometry utility function library for calculating spatial information corresponding to the function; receiving an identifier input by a user and determining a target area corresponding to the identifier; processing, through the geometry utility function library, geographic information of the target area, coordinates of one or more feature points in the target area. Arikan however does not fully teach to determine a height and a width of the target area and determining a container height and a container width of a container for display; determining a canvas height and a canvas width according to the height, the width, the container height and the container width; determining a ratio of distance to pixels in the canvas according to the width of the target area and the canvas width, or according to the height of the target area and the canvas height; determining pixel coordinates of the feature points in the canvas according to the ratio and the coordinates; and generating a map of the target area in the canvas according to the pixel coordinates, and displaying the map of the target area for the user to view.
Cornell teaches to determine a height and a width of the target area and (Cornell: Paragraph 0078: “Generally, map data tiles of each zoom level may be scaled such that when they are rendered at a magnification that corresponds with their zoom level, they are rendered with the same display screen pixel size and area… Accordingly, the number of map data tiles shown may be limited primarily by the physical size of the display screen (e.g., a display screen of 640.times.480 may only have as many as 320 map data tiles across and 240 map data tiles high) or by a viewing window designating only a portion of the entire display screen.”,
Supplemental Note: the map data tiles are equivalent to the target area. The amount of map tiles shown depends on the viewing window, if the viewing window is the same size as the display screen, the map data tiles able to fit within the display window are shown)
… determining a container height and a container width of a container for display;
determining a canvas height and a canvas width according to the height, the width, the container height and the container width; (Cornell: Paragraph 0031: “The display device 34 for any particular client device 16-22 may be any type of electronic display device such as a liquid crystal display (LCD), a light emitting diode (LED) display, a plasma display, a cathode ray tube (CRT) display, or any other type of known or suitable electronic display.”: Paragraph 0048: “The top-down view of FIG. 5A is provided on a viewing screen that may be defined by a physical size of a display device, for example a physical size of a display screen, or by a display application executed on the display device where only a portion of the physical size of the display screen is used to display the map surface”; Paragraph 0078: “Accordingly, the number of map data tiles shown may be limited primarily by the physical size of the display screen (e.g., a display screen of 640.times.480 may only have as many as 320 map data tiles across and 240 map data tiles high) or by a viewing window designating only a portion of the entire display screen.”; Paragraph 0090: “A display screen pixel height may refer to the height of a display screen pixel which may be represented by length 1544 (see FIG. 15C)”; ,
Supplemental Note: The physical size of the display is interpreted as the container height. The whole of the display or parts of the display can be used is used to display the map surface thus, the display size is also equivalent to the canvas height)
determining a ratio of distance to pixels in the canvas according to the width of the target area and the canvas width, or according to the height of the target area and the canvas height; (Cornell: Paragraph 0049: “an area of the map surface viewable on the display screen may depend on a magnification of the viewing screen. The magnification of the viewing window may describe a scale upon which the map surface is being rendered. Maps are generally drawn to a scale, expressed as a ratio such as 1:1,000, meaning that 1 of any unit of measurement on the viewing window corresponds exactly or approximately to 1,000 actual units. For example, in a case in which a viewing window is measured in inches, the distance scale may translate an inch of the viewing window to a length of 1,000 miles (or kilometers).”; Paragraph 0090: “an algorithm may be used to set viewing bands based on a vertical position on a display screen. The algorithm may use a function that outputs a ratio of map plane pixel depth to display screen (viewing plane) pixel height based on a depth dimension of the map plane… A map pixel depth may refer to a distance dimension 1543 of the unit of area of the map plane (see FIG. 15C). A display screen pixel height may refer to the height of a display screen pixel which may be represented by length 1544 (see FIG. 15C).”,
Supplemental Note: the amount of map data to show depth (map plane pixel depth) depends on the viewing plan pixel height within the display)
determining pixel coordinates of the feature points in the canvas according to the ratio and the coordinates; and generating a map of the target area in the canvas according to the pixel coordinates, and displaying the map of the target area for the user to view (Cornell: Paragraph 0092: “Solving the equation for Ys results in a function G that relates the vertical position on the screen at a particular zoom level and tilt angle to a particular ratio of map pixel depth to screen pixel height: Ys=G(Z,dYm/dYs,T)”; Paragraph 0035: “Each map data tile contains necessary map data to construct a portion of the map display, including data identifying various map objects or map features such as roads, buildings, and geographic boundaries, such as water lines, county lines, city boundaries, state lines, mountains, parks, etc.”: Paragraph 0066: “In some embodiments, a middle band (i.e., not a foreground band and not background band) may have a higher zoom level data than a prior or subsequent band. This may be the case in situations where a feature that is in the middle of a map surface is to be highlighted. In this case, the band determination may be based on a set of map features. This determination may in turn be based on feature priority, type or position of the map features.”,
Supplemental Note: the map on the screen is able to show map features of roads and buildings. The positions of these features are already gathered within the map data, thus using the vertical position, zoom level and tilt angle corresponding to the ratio of the map pixel depth and screen pixel, the pixel coordinates of these features are determined. Please see Figure A below as it shows the map features within the display).
PNG
media_image1.png
692
795
media_image1.png
Greyscale
Figure A: Cornell: Fig. 6B
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have been modified the invention disclosed by Arikan with the teachings of Cornell with a reasonable expectation of success. Arikan and Cornell both teach the ability of determining the location of a user, acquire feature points of various roads and buildings to then create a 3D representation of a target area. Cornell further describes it’s process of determining how much of the target area to show within the display and how the various 3D perspectives tilt the map data with roadway features and buildings accurately displayed per their location data on the map tiles. One of ordinary skill in the art would find this function of Cornell as combining prior art elements according to known methods to yield predictable results. For example, both Arikan and Cornell acquire map tiles and feature data with the ability of displaying it accordingly on a user’s device with a virtual camera able to provide 3D perspectives. The function of Cornell adjusting the amount of the target area to show within a user’s device at a pixel by pixel basis within its device’s display depending on the zoom level and perspective tilt is already a known method by the map system Arikan, otherwise it would not have been able to show accurate 3D models of the various roadways and buildings (Arikan: Figure C). The ability to show these features with the map data within the display (also the claimed canvas if the application is in full screen) of the user’s device is the predictable result both Arikan and Cornell teach.
Regarding claim 2, Arikan, as modified, does not teach wherein determining the canvas height and the canvas width comprises: determining that the canvas width is equal to the container width in response to determining that the width is greater than the height, and determining the canvas height according to a product of the canvas width and a ratio of the height to the width; and/or determining that the canvas height is equal to the container height in response to determining that the height is greater than the width, and determining the canvas width according to a product of the canvas height and a ratio of the width to the height.
Cornell teaches wherein determining the canvas height and the canvas width comprises:
determining that the canvas width is equal to the container width in response to determining that the width is greater than the height, and determining the canvas height according to a product of the canvas width and a ratio of the height to the width;
and/or determining that the canvas height is equal to the container height in response to determining that the height is greater than the width, and determining the canvas width according to a product of the canvas height and a ratio of the width to the height (Cornell: Paragraph 0031: “The display device 34 for any particular client device 16-22 may be any type of electronic display device such as a liquid crystal display (LCD), a light emitting diode (LED) display, a plasma display, a cathode ray tube (CRT) display, or any other type of known or suitable electronic display.”: Paragraph 0048: “The top-down view of FIG. 5A is provided on a viewing screen that may be defined by a physical size of a display device, for example a physical size of a display screen, or by a display application executed on the display device where only a portion of the physical size of the display screen is used to display the map surface”; Paragraph 0078: “Accordingly, the number of map data tiles shown may be limited primarily by the physical size of the display screen (e.g., a display screen of 640.times.480 may only have as many as 320 map data tiles across and 240 map data tiles high) or by a viewing window designating only a portion of the entire display screen.”; Paragraph 0090: “A display screen pixel height may refer to the height of a display screen pixel which may be represented by length 1544 (see FIG. 15C)”; ,
Supplemental Note: The physical size of the display is interpreted as the container height. The whole of the display or parts of the display can be used to display the map surface thus, the display size is also equivalent to the canvas height).
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have been modified the invention disclosed by Arikan with the teachings of Cornell with a reasonable expectation of success. Please refer to the rejection of claim 1 as both claim the same function of determining the canvas height and width as taught by Arikan in view of Cornell and therefore rejected under the same pretenses.
Regarding claim 3, Arikan, as modified, does not teach wherein determining the ratio of the distance to the pixels in the canvas comprises: determining a ratio of the canvas width to the width of the target area, or a ratio of the canvas height to the height of the target area as the ratio.
Cornell teaches wherein determining the ratio of the distance to the pixels in the canvas comprises:
determining a ratio of the canvas width to the width of the target area, or a ratio of the canvas height to the height of the target area as the ratio (Cornell: Paragraph 0049: “an area of the map surface viewable on the display screen may depend on a magnification of the viewing screen. The magnification of the viewing window may describe a scale upon which the map surface is being rendered. Maps are generally drawn to a scale, expressed as a ratio such as 1:1,000, meaning that 1 of any unit of measurement on the viewing window corresponds exactly or approximately to 1,000 actual units. For example, in a case in which a viewing window is measured in inches, the distance scale may translate an inch of the viewing window to a length of 1,000 miles (or kilometers).”; Paragraph 0090: “an algorithm may be used to set viewing bands based on a vertical position on a display screen. The algorithm may use a function that outputs a ratio of map plane pixel depth to display screen (viewing plane) pixel height based on a depth dimension of the map plane… A map pixel depth may refer to a distance dimension 1543 of the unit of area of the map plane (see FIG. 15C). A display screen pixel height may refer to the height of a display screen pixel which may be represented by length 1544 (see FIG. 15C).”,
Supplemental Note: the amount of map data to show depth (map plane pixel depth) depends on the viewing plan pixel height within the display).
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have been modified the invention disclosed by Arikan with the teachings of Cornell with a reasonable expectation of success. Please refer to the rejection of claim 1 as both claim the same function of determining the ratio of the canvas height to the height of the target area as taught by Arikan in view of Cornell and therefore rejected under the same pretenses.
Regarding claim 4, Arikan, as modified, teaches wherein the feature points comprise: vertices of outline of the target area, vertices of a circumscribed quadrangle of outline of the target area, vertices of a covering outline in the target area or any combination thereof (Arikan: Col. 14, lines 20 – 64: “In order to display both immersive and non-immersive 3D map presentations, some embodiments have to generate a variety of tiles for client devices to render to generate roads, building, and surrounding scenery. In some embodiments, examples of such tiles include road and building tiles used for non-immersive 3D presentations, and navigation and building tiles used for immersive 3D presentations. Before generating these tiles, a set of servers has to generate the description of the road, building, and other geometries that are placed in each of the tiles. This task involves multiple sub-tasks such as (1) receiving map data from a variety of vendors, (2) processing such data to produce one dimensional (1D) roads, (3) smoothing the 1D road graphs, (4) defining data to specify intersections, (5) generating 2D road geometries and land cover, (6) smoothing the 2D road geometries, (7) generating data (e.g., estimated height data) regarding buildings, (8) using such data to define building geometries, (9) constructing road geometries details (such as islands, lane markings, and distances and land cover between road geometries), and (10) identifying geometry edge node characteristics and propagating such characteristics. The mapping service of some embodiments generates downloadable map tile data through offline processing of map data (e.g., data received from map vendors). In some embodiments, this offline processing takes map object location input (e.g., latitude/longitude data for roads, administrative boundaries, natural boundaries, etc.) and generates aggregated roads and relationships between the aggregated roads. From the aggregated roads and their relationships, the mapping service processing generates road geometries. The mapping service also generates geometries for land cover (e.g., parks, oceans, states, etc.) using the map object location input. Some embodiments use scalable distributed processing to create downloadable map tiles from the geometric vector data. One of ordinary skill in the art will recognize that the “offline” processing described in this application may be performed by mapping service computing devices that are in fact connected to the network through which the mapping application requests tile data, but is used to represent that the processing is not performed in response to user requests for tiles.”,
Supplemental Note: the tiles are generated for a target area. Map tiles are known by one with knowledge in the art to represent a portion of a larger map set by geometric shapes).
Regarding claim 5, Arikan, as modified, teaches wherein the feature points comprise the vertices of outline of the target area and the vertices of the circumscribed quadrangle of outline of the target area, and wherein determining the coordinates of the feature points in the target area comprises:
determining a basic vertex as an origin among the vertices of the circumscribed quadrangle; (Arikan: Col. 9, lines 14 – 21: “The fourth stage 117 shows that the direction entry page 180 includes starting and ending fields for providing starting and ending locations for a route, and a table that lists recent routes that the application has provided to the user. Other controls on this page are controls for starting a route, for reversing the order of the start and end locations, for canceling the direction request, and for picking walking, auto, or public transit routes.”; Col. 9, lines 35 – 57: “The fourth stage illustrates the user selecting one of the recent directions that was auto-populated in the table 182. The fifth stage 119 then shows three routes on a 2D map view between the specified start and end locations specified through the page 180. It also shows the selection of the second route and some information about this route in a bar at the top of the layout. This bar is shown to include start and end buttons. The start button is shown to be selected in the fifth stage. As shown by the sixth stage, the selection of the start button directs the application to enter a turn-by-turn navigation mode. In this example, the application has entered a 2D turn-by-turn navigation mode. In other embodiments, the application will enter by default into a 3D turn-by-turn navigation mode. In this mode, the application displays a realistic sign 184 that identifies the distance from the current location of the device to the next maneuver in the navigated route and some other pertinent information. The application also displays a top bar that includes some information about the navigation as well as End and Overview buttons, for respectively ending the navigation and obtaining an overview of the remaining portion of the navigated route or the entire portion of the navigated route in other embodiments.”,
Supplemental Note: in this example, the circumscribed quadrangle pertains to the route with the user selecting their starting and ending points. The vertex that is defined as the origin along the path is interpreted as the starting location)
calculating first distances in a width direction and second distances in a height direction from other feature points excluding the base vertex to the base vertex; and
determining coordinates of the other feature points according to the first distances and the second distances (Arikan: Col. 18, lines 14 – 48: “FIG. 8 illustrates the data structure 800 of some embodiments for a road segment as well as the data structure 815 for a junction. As shown, the road segment includes a segment ID (i.e., a unique identification), one or more names, geometry information, and attribute information. The geometry information (which is different than the road geometries created for defining vector data) defines the path and other geometric information about a road segment. As shown, the geometry information includes centerline path data (e.g., an ordered string of coordinates that define the center of the road), start and end junction information, parameters to indicate the width and offset with respect to the centerline, and functionality enabling evaluation of the sides of the road at any point along the road segment. In some embodiments, this is a function on the road segment class that utilizes the centerline, offset, and width information to calculate the location of the sides of the road. While this diagram shows the road drawing data including start and end junctions, some embodiments do not define one as the start and one as the end, but rather simply indicate two junction IDs as endpoints (or a single junction ID if the road segment dead-ends). The attribute information describes metadata about the road segment, such as the road type (or functional road class, which defines the level of importance of a road, from freeway down to pseudo path), the number of lanes, the speed limit, the relative elevation of the road (which may contain references to one or more other road segments and/or junctions, indicating that the present road segment runs below or above the referenced object), the height of the road (relevant for identifying elevation), the form of way (which defines a path as a dual carriageway, single carriageway, walkway, stairs, connector road, slip road, etc.), restrictions (e.g., toll restrictions, vehicle type restrictions, indications that a road is private, etc.).”,
Supplemental Note: the road segment consists of a string of coordinates indicating its location and parameters for width and offset distances to analyze the sides of the roads).
Regarding claim 8, Arikan, as modified, teaches generating a polygon corresponding to the pixel coordinates in the canvas (Arikan: Col. 11, lines 22 – 42: “The first stage 301 shows the virtual camera 312 at a first position pointing downwards at an angle (e.g., a 30° angle) towards the 3D scene 310. By rendering the 3D scene from the position and angle shown in stage 301 the application generates the 3D map view 318. From this position, the camera is pointing at a location that is a moving position in front of the device. The virtual camera 312 is kept behind the current location of the device. “Behind the current location” in this case means backward along the navigation application's defined path in the opposite direction from the current direction that the device is moving in. The navigation map view 318 looks as though it was shot by a camera from above and behind the device's location indicator 316. The location and angle of the virtual camera places the location indicator 316 near the bottom of the navigation map view 318. This also results in the majority of the screen being filled with the streets and buildings ahead of the present location of the device. In contrast, in some embodiments, the location indicator 316 is in the center of the screen, with half of the screen representing things ahead of the device and the other half representing things behind the device.”,
Supplemental Note: the pixels of the screen generate a 3d representation of the environment where the current direction is in the center of the screen while also generating objects in particular locations of the screen)
In sum, Arikan teaches generating a polygon corresponding to the pixel coordinates in the canvas. Arikan however does not teach wherein generating the map comprises: saving the pixel coordinates as an array.
Cornell teaches wherein generating the map comprises: saving the pixel coordinates as an array; and… processing the array (Cornell: Paragraph 0092: “Solving the equation for Ys results in a function G that relates the vertical position on the screen at a particular zoom level and tilt angle to a particular ratio of map pixel depth to screen pixel height: Ys=G(Z,dYm/dYs,T)”; Paragraph 0035: “Each map data tile contains necessary map data to construct a portion of the map display, including data identifying various map objects or map features such as roads, buildings, and geographic boundaries, such as water lines, county lines, city boundaries, state lines, mountains, parks, etc.”: Paragraph 0066: “In some embodiments, a middle band (i.e., not a foreground band and not background band) may have a higher zoom level data than a prior or subsequent band. This may be the case in situations where a feature that is in the middle of a map surface is to be highlighted. In this case, the band determination may be based on a set of map features. This determination may in turn be based on feature priority, type or position of the map features.”; Paragraph 0077: “A pixel 1011 may represent the smallest addressable element of a display device, where the address of a pixel generally corresponds to its coordinates on a screen of the display device. As discussed, map data may be organized as map data tiles, where each map data tile corresponds to an area of a map surface. FIG. 11 illustrates an implementation where each map data tile 1110 may be rendered using four pixels arranged as a 2.times.2 pixel square of the display device”,
Supplemental Note: the map on the screen is able to show map features of roads and buildings. The positions of these features are already gathered within the map data, thus using the vertical position, zoom level and tilt angle corresponding to the ratio of the map pixel depth and screen pixel, the pixel coordinates of these features are determined. Please see Figure A as it shows the map features within the display. Figure B below shows the various map tiles which correspond to saving pixel coordinates in an array, thus the position of the map features have their own corresponding pixels within this array)
PNG
media_image2.png
1194
777
media_image2.png
Greyscale
Figure B: Cornell: Fig. 11
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have been modified the invention disclosed by Arikan with the teachings of Cornell with a reasonable expectation of success. As stated in claim 1, Arikan and Cornell both teach the ability of determining the location of a user, acquire feature points of various roads and buildings to then create a 3D representation of a target area. Cornell further describes it’s process of determining how much of the target area to show within the display and how the various 3D perspectives tilt the map data with roadway features and buildings accurately displayed per their location data on the map tiles. The roadway and building feature locations are within the map tiles, thus are saved within the array of the map tiles. As further stated in claim 1, one of ordinary skill in the art would find this function of Cornell as combining prior art elements according to known methods to yield predictable results. For example, both Arikan and Cornell acquire map tiles and feature data with the ability of displaying it accordingly on a user’s device with a virtual camera able to provide 3D perspectives. The function of Cornell adjusting the amount of the target area to show within a user’s device at a pixel by pixel basis within its device’s display depending on the zoom level and perspective tilt is already a known method by the map system Arikan, otherwise it would not have been able to show accurate 3D models the various roadways and buildings (Arikan: Figure C). The ability to show these features with the map data within the display (also the claimed canvas if the application is in full screen) of the user’s device is the predictable result both Arikan and Cornell teach.
Regarding claim 9, Arikan, as modified, teaches further comprising: initializing an object in the canvas, wherein the object comprises the map and/or an element in the map;
binding an event for the object, wherein the event comprises an operation and an effect corresponding to the operation (Arikan: Col. 16, line 43 – Col. 17, line 23: “The building geometry generator 617 of some embodiments generates building geometries using the building data 633. In some embodiments, as mentioned, the building data 633 includes ground elevation and surface elevation data, in addition to locations of the buildings. To generate building geometry, some embodiments calculate the building height for various points within the location of the building. The building geometry generator 617 retrieves the ground elevation and subtracts this from the surface elevation data to calculate the building height. In other embodiments, the building geometry generator 617 (or another module) uses 3D satellite data to calculate the height data. To calculate a height for the building as a whole, the building geometry generator 617 calculates an overall height as the mean of the various calculated heights at different points, plus a bias factor constant multiplied by the standard deviation of the point heights. The bias factor, in some embodiments, is a constant determined from ground truth (e.g., data determined at the location) and experiments. Some embodiments also determine whether the building is flat or non-flat (e.g., with a pointy roof). When the standard deviation of the point heights is above a threshold (which may also be based on ground truth and experiments), the building geometry generator 617 designates the roof as non-flat. When the standard deviation of the point heights is below the threshold, the building geometry generator 617 designates the roof as flat. When generating the geometry vertices, some embodiments create pointy roofs (e.g., triangular prisms or pyramids) for non-flat buildings. The road, land cover, and building geometries are sent to the tile generator 620. In some embodiments, the tile generator 620 creates several tiles for a map region, at different levels of detail (i.e., zoom levels). Some embodiments define the tile location boundaries for the different zoom levels (e.g., with a tile at a first zoom level containing four tiles at the next zoom level), then use distributed processing techniques to assign the different geometries (both roads and land cover) to the various tiles. After assigning the geometries to tiles (each geometry may be assigned to one or more tiles at each zoom level), the tile generator 620 uses additional distributed processing to generate and compress the tiles. In some embodiments, map tiles contain vector data describing the polygons to generate for rendering the data as a 2D or 3D map. To reduce the amount of vector data (and thereby reduce the size of the files for easier transmission), some embodiments use a transient rasterization process that reduces the vector data to raster information, then re-vectorizes the data with fewer vertices.”,
Supplemental Note: the building generator is able to locate and generate buildings, binding them to a location on the map and to dynamically change per the zoom levels).
Regarding claim 10, Arikan, as modified, teaches further comprising: binding height information for the object (Arikan: Col. 16, lines 43 – 61: “The building geometry generator 617 of some embodiments generates building geometries using the building data 633. In some embodiments, as mentioned, the building data 633 includes ground elevation and surface elevation data, in addition to locations of the buildings. To generate building geometry, some embodiments calculate the building height for various points within the location of the building. The building geometry generator 617 retrieves the ground elevation and subtracts this from the surface elevation data to calculate the building height. In other embodiments, the building geometry generator 617 (or another module) uses 3D satellite data to calculate the height data. To calculate a height for the building as a whole, the building geometry generator 617 calculates an overall height as the mean of the various calculated heights at different points, plus a bias factor constant multiplied by the standard deviation of the point heights. The bias factor, in some embodiments, is a constant determined from ground truth (e.g., data determined at the location) and experiments.”).
Regarding claim 11, Arikan, as modified, teaches further comprising: determining a first zoom ratio according to the container width and the canvas width in response to determining the canvas width being greater than the container width, and zooming in the canvas according to the first zoom ratio;
determining a second zoom ratio according to the container height and the canvas height in response to determining the canvas height being greater than the container height, and zooming in the canvas according to the second zoom ratio (Arikan: Col. 17, lines 5 – 23: “The road, land cover, and building geometries are sent to the tile generator 620. In some embodiments, the tile generator 620 creates several tiles for a map region, at different levels of detail (i.e., zoom levels). Some embodiments define the tile location boundaries for the different zoom levels (e.g., with a tile at a first zoom level containing four tiles at the next zoom level), then use distributed processing techniques to assign the different geometries (both roads and land cover) to the various tiles. After assigning the geometries to tiles (each geometry may be assigned to one or more tiles at each zoom level), the tile generator 620 uses additional distributed processing to generate and compress the tiles. In some embodiments, map tiles contain vector data describing the polygons to generate for rendering the data as a 2D or 3D map. To reduce the amount of vector data (and thereby reduce the size of the files for easier transmission), some embodiments use a transient rasterization process that reduces the vector data to raster information, then re-vectorizes the data with fewer vertices.”; Col. 12, line 62 – Col. 13, line 25: “In stage 402, the user makes a gesture by placing two finger tips 420 near each other on the screen of the device, on the screen view 424 and moving the fingertips apart while they are on the screen. Moving the fingertips 420 apart has the effect of making the map (both the part between the fingers and the rest of the map) larger. In order to make the things in the map appear larger, the application causes the virtual camera 412 to zoom in. In some embodiments, the line 450 along which the mapping application moves the virtual camera 412 is a line formed by the front of the virtual camera 412 and the virtual camera 412's point of focus. The mapping application of some embodiments moves the virtual camera 412 along a line formed by the front of the virtual camera 412 and a location in the 3D map 410 based on the user's input to zoom into (or out of) the view of the 3D map 410. After zooming in for stage 402, the user decides to zoom out for stage 403. In this stage the user has placed two fingers 430 on the screen and brought them closer together. Bringing the fingers closer together has the effect of shrinking the map (both the part between the fingers and the rest of the map). The zoom-out adjustment is accomplished by moving the virtual camera 412 farther away from the 3D map 410 along the line 455. In some embodiments, the line 455 along which the mapping application moves the virtual camera 412 is a line formed by the front of the virtual camera 412 and the virtual camera 412's point of focus. The mapping application of some embodiments moves the virtual camera 412 along a line formed by the front of the virtual camera 412 and a location in the 3D map 410 based on the user's input to zoom into (or out of) the view of the 3D map 410.”,
Supplemental Note: as shown in Figure C, the user can dictate the amount being shown in the canvas based on the zooming in and out operations. This can be to fit items not currently within the width or height of the canvas)
PNG
media_image3.png
1312
916
media_image3.png
Greyscale
Figure C: Arikan: Fig. 4
Regarding claim 12, Arikan, as modified, teaches wherein zooming in the canvas according to the first zoom ratio comprises:
zooming in the canvas according to the first zoom ratio and a first preset zoom ratio; and/or zooming in the canvas according to the second zoom ratio comprises:
zooming in the canvas according to the second zoom ratio and a second preset zoom ratio (Arikan: Col. 17, lines 5 – 23: “The road, land cover, and building geometries are sent to the tile generator 620. In some embodiments, the tile generator 620 creates several tiles for a map region, at different levels of detail (i.e., zoom levels). Some embodiments define the tile location boundaries for the different zoom levels (e.g., with a tile at a first zoom level containing four tiles at the next zoom level), then use distributed processing techniques to assign the different geometries (both roads and land cover) to the various tiles. After assigning the geometries to tiles (each geometry may be assigned to one or more tiles at each zoom level), the tile generator 620 uses additional distributed processing to generate and compress the tiles. In some embodiments, map tiles contain vector data describing the polygons to generate for rendering the data as a 2D or 3D map. To reduce the amount of vector data (and thereby reduce the size of the files for easier transmission), some embodiments use a transient rasterization process that reduces the vector data to raster information, then re-vectorizes the data with fewer vertices.”; Col. 12, line 62 – Col. 13, line 25: “In stage 402, the user makes a gesture by placing two finger tips 420 near each other on the screen of the device, on the screen view 424 and moving the fingertips apart while they are on the screen. Moving the fingertips 420 apart has the effect of making the map (both the part between the fingers and the rest of the map) larger. In order to make the things in the map appear larger, the application causes the virtual camera 412 to zoom in. In some embodiments, the line 450 along which the mapping application moves the virtual camera 412 is a line formed by the front of the virtual camera 412 and the virtual camera 412's point of focus. The mapping application of some embodiments moves the virtual camera 412 along a line formed by the front of the virtual camera 412 and a location in the 3D map 410 based on the user's input to zoom into (or out of) the view of the 3D map 410. After zooming in for stage 402, the user decides to zoom out for stage 403. In this stage the user has placed two fingers 430 on the screen and brought them closer together. Bringing the fingers closer together has the effect of shrinking the map (both the part between the fingers and the rest of the map). The zoom-out adjustment is accomplished by moving the virtual camera 412 farther away from the 3D map 410 along the line 455. In some embodiments, the line 455 along which the mapping application moves the virtual camera 412 is a line formed by the front of the virtual camera 412 and the virtual camera 412's point of focus. The mapping application of some embodiments moves the virtual camera 412 along a line formed by the front of the virtual camera 412 and a location in the 3D map 410 based on the user's input to zoom into (or out of) the view of the 3D map 410.”,
Supplemental Note: as shown in Figure C, the user can dictate the amount being shown in the canvas based on the zooming in and out operations. This can be to fit items not currently within the width or height of the canvas and the zoom levels are preset).
Regarding claim 13, Arikan, as modified, teaches further comprising:
determining a container center position of the container and a canvas center position of the canvas;
determining an offset from the container center position to the canvas center position;
moving the zoomed-in canvas according to the offset (Arikan: Col. 11, line 33 – Col. 12, line 5: “The navigation map view 318 looks as though it was shot by a camera from above and behind the device's location indicator 316. The location and angle of the virtual camera places the location indicator 316 near the bottom of the navigation map view 318. This also results in the majority of the screen being filled with the streets and buildings ahead of the present location of the device. In contrast, in some embodiments, the location indicator 316 is in the center of the screen, with half of the screen representing things ahead of the device and the other half representing things behind the device. In order to simplify the figure, no road signs are depicted for the views 318, 328, and 338. The second stage 302 shows the virtual camera 312 at a different position, pointing downwards towards the scene 310 at a larger second angle (e.g., a 45° angle). The application renders the scene 310 from this angle, resulting in the 3D navigation map view 328. The buildings and the roads are smaller than their illustration in the first navigation map view 318. Once again the virtual camera 312 is above and behind the location indicator 326 in the scene 310. This again results in the location indicator appearing in the lower part of the 3D map view 328. The location and orientation of the camera also results again in the majority of the screen displaying things ahead of the car, which is what someone navigating needs to know. The third stage 303 shows the virtual camera 312 at a top-down view that looks downwards on a location on a 2D map 345 that corresponds to the location in the 3D map scene 310 that was used to render the 3D views 318 and 328. The scene that is rendered from this perspective is the 2D map view 338. Unlike the 3D rendering operations of the first and second stages that in some embodiments are perspective 3D rendering operations, the rendering operation in the third stage is relatively simple as it only needs to crop a portion of the 2D map that is identified by a zoom level specified by the application or the user. Accordingly, the virtual camera characterization in this situation somewhat unnecessarily complicates the description of the operation of the application, as cropping a portion of a 2D map is not a perspective rendering operation.”,
Supplemental Note: the center position of the container is determined to be the location indicator. The rest of the canvas is provided with other route and map information. The different stages represent the different views the canvas portrays based on the offset from the location indicator as shown in Figure D).
PNG
media_image4.png
1180
842
media_image4.png
Greyscale
Figure D: Arikan: Figure 3
Regarding claim 14, Arikan, as modified, teaches further comprising:
receiving a route generation request;
acquiring maps of other areas other than the target area from the server; (Arikan: Col. 7, line 46 – Col. 8, line 8: “FIG. 1 shows six stages 105, 110, 115, 117, 119, 121 of interaction with the mapping application. The first stage 105 shows a device's UI 120, which includes several icons of several applications in a dock area 125 and on a page of the UI. One of the icons on this page is the icon for the mapping application 130. The first stage shows a user's selection of the mapping application through touch contact with the device's screen at the location of this application on the screen. The second stage 110 shows the device after the mapping application has opened. As shown in this stage, the mapping application's UI has a starting page that in some embodiments (1) displays a map of the current location of the device, and (2) several UI controls arranged in a top bar 140, and as floating controls. As shown in FIG. 1, the floating controls include an indicator 145, a 3D control 150, and a page curl control 155, while the top bar 140 includes a direction control 160, a search field 165, and a bookmark control 170. In some embodiments, a user can initiate a search by tapping in the search field 165. This directs the application to present an animation that (1) presents an on-screen keyboard and (2) opens a search table full of invaluable completions. This table has some important subtleties. When the search field is tapped and before the terms are edited, or when the search field is empty, the table contains a list of “recents,” which in some embodiments are recent searches and route directions that the user has requested. This makes it very easy to quickly bring up recently accessed results.”)
when a route requested to be generated passes through the target area, generating the route according to the maps of the other areas and the map of the target area (Arikan: Col. 42, lines 40 – 68: “The map generator 4935 of some embodiments generates map information (e.g., map tiles) to transmit to the requestor device. The requestor device requests a map for a particular region (e.g., using latitude/longitude information), and the map generator 4935 creates (or uses pre-generated) map tiles for the region, then sends data for these tiles (e.g., as encoded vector and/or image data) to the device. The route generator 4945 calculates optimal routes between two or more points in response to user requests. In some embodiments, the route generator 4945 calculates the routes based on the map data, using optimization algorithms. The routes may be defined as a series of intersections, a series of road pathways, or in other manners. In addition, when a user requests a route, the route generator 4945 provides intersection data for use by the device in turn-by-turn navigation. In some embodiments, the intersection analyzer 4955 retrieves intersection data 4925, and modifies this data for navigation of the route, as described below. As shown, at stage 4910, the device 4905 sends a request for a route to the mapping service 4900. In some embodiments, the user enters a starting address (or place) and an ending address (or place), potentially including additional midpoint locations (e.g., starting at A, going to B, then going to C from B). The device then transmits location information to the mapping service. In some embodiments, the device translates the locations into latitude and longitude data, while in other embodiments this conversion is performed by the mapping service.”).
Regarding claim 15, Arikan teaches a map generation apparatus, comprising a processor, and the processor is configured to: (Arikan: Col. 59, lines 41 – 56: “Many of the above-described features and applications are implemented as software processes that are specified as a set of instructions recorded on a computer readable storage medium (also referred to as computer readable medium). When these instructions are executed by one or more computational or processing unit(s) (e.g., one or more processors, cores of processors, or other processing units), they cause the processing unit(s) to perform the actions indicated in the instructions. Examples of computer readable media include, but are not limited to, CD-ROMs, flash drives, random access memory (RAM) chips, hard drives, erasable programmable read-only memories (EPROMs), electrically erasable programmable read-only memories (EEPROMs), etc. The computer readable media does not include carrier waves and electronic signals passing wirelessly or over wired connections.”)
load a function of displaying and/or drawing maps in a server, and (Arikan: Col. 14, lines 23 – 32)
call an application programming interface (API) of the server, (Arikan: Col. 2, lines 1 – 16,
Supplemental Note: the server data is able to provide data of geometry data of the map features to the device with the application)
wherein the API provides a geometry utility function library for calculating spatial information corresponding to the function; (Arikan: Col. 11, lines 6 – 32,
Supplemental Note: the application which can show maps in 3D or 2D are interpreted as the geometry utility function library)
receive an identifier input by a user and determine a target area corresponding to the identifier; (Arikan: Col. 7, lines 66 – Col. 8, line 27,
Supplemental Note: the identifier is interpreted as the area the user wants to search)
process, through the geometry utility function library, geographic information of the target area, (Arikan: Col. 11, lines 45 – 57,
Supplemental Note: geographic information of the building and roads surrounding are used to show a 3D navigation view)
… coordinates of one or more feature points in the target area; (Arikan: Col. 18, lines 21 – 27,
Supplemental Note: the geometry information includes a string of coordinates representing the center of the road).
In sum, Arikan teaches a map generation apparatus, comprising a processor, and the processor is configured to: load a function of displaying and/or drawing maps in a server, and call an application programming interface (API) of the server, wherein the API provides a geometry utility function library for calculating spatial information corresponding to the function; receive an identifier input by a user and determine a target area corresponding to the identifier; process, through the geometry utility function library, geographic information of the target area, coordinates of one or more feature points in the target area. Arikan however does not teach to determine a height and a width of the target area and determine a container height and a container width of a container for display; determine a canvas height and a canvas width according to the height, the width, the container height and the container width; determine a ratio of distance to pixels in the canvas according to the width of the target area and the canvas width, or according to the height of the target area and the canvas height; determine pixel coordinates of the feature points in the canvas according to the ratio factor and the coordinates; and generate a map of the target area in the canvas according to the pixel coordinates, and display the map of the target area for the user to view.
Cornell teaches to determine a height and a width of the target area and (Cornell: Paragraph 0078,
Supplemental Note: the map data tiles are equivalent to the target area. The amount of map tiles shown depends on the viewing window, if the viewing window is the same size as the display screen, the map data tiles able to fit within the display window are shown)
… determine a container height and a container width of a container for display;
determine a canvas height and a canvas width according to the height, the width, the container height and the container width; (Cornell: Paragraph 0031; Paragraph 0048; Paragraph 0078; Paragraph 0090,
Supplemental Note: The physical size of the display is interpreted as the container height. The whole of the display or parts of the display can be used is used to display the map surface thus, the display size is also equivalent to the canvas height)
determine a ratio of distance to pixels in the canvas according to the width of the target area and the canvas width, or according to the height of the target area and the canvas height; (Cornell: Paragraph 0049; Paragraph 0090,
Supplemental Note: the amount of map data to show depth (map plane pixel depth) depends on the viewing plan pixel height within the display)
determine pixel coordinates of the feature points in the canvas according to the ratio factor and the coordinates; and
generate a map of the target area in the canvas according to the pixel coordinates, and display the map of the target area for the user to view (Cornell: Paragraph 0092; Paragraph 0035; Paragraph 0066,
Supplemental Note: the map on the screen is able to show map features of roads and buildings. The positions of these features are already gathered within the map data, thus using the vertical position, zoom level and tilt angle corresponding to the ratio of the map pixel depth and screen pixel, the pixel coordinates of these features are determined. Please see Figure A as it shows the map features within the display).
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have been modified the invention disclosed by Arikan with the teachings of Cornell with a reasonable expectation of success. Please refer to the rejection of claim 1 as both claim the same function and therefore rejected under the same pretenses.
Regarding claim 16, Arikan, as modified, does not teach wherein the processor is configured to: determine that the canvas width is equal to the container width in response to determining that the width is greater than the height, and determine the canvas height according to a product of the canvas width and a ratio of the height to the width; and/or determine that the canvas height is equal to the container height in response to determining that the height is greater than the width, and determine the canvas width according to a product of the canvas height and a ratio of the width to the height.
Cornell teaches wherein the processor is configured to: determine that the canvas width is equal to the container width in response to determining that the width is greater than the height, and determine the canvas height according to a product of the canvas width and a ratio of the height to the width;
and/or determine that the canvas height is equal to the container height in response to determining that the height is greater than the width, and determine the canvas width according to a product of the canvas height and a ratio of the width to the height (Cornell: Paragraph 0031; Paragraph 0048; Paragraph 0078; Paragraph 0090,
Supplemental Note: The physical size of the display is interpreted as the container height. The whole of the display or parts of the display can be used to display the map surface thus, the display size is also equivalent to the canvas height).
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have been modified the invention disclosed by Arikan with the teachings of Cornell with a reasonable expectation of success. Please refer to the rejection of claim 2 as both claim the same function and therefore rejected under the same pretenses.
Regarding claim 17, Arikan, as modified, does not teach wherein determine the ratio of the canvas width to the width of the target area as the ratio when the width is greater than the height; or determine a ratio of the canvas height to the height of the target area as the ratio when the height is greater than the width.
Cornell teaches wherein determine the ratio of the canvas width to the width of the target area as the ratio when the width is greater than the height;
or determine a ratio of the canvas height to the height of the target area as the ratio when the height is greater than the width (Cornell: Paragraph 0049: “an area of the map surface viewable on the display screen may depend on a magnification of the viewing screen. The magnification of the viewing window may describe a scale upon which the map surface is being rendered. Maps are generally drawn to a scale, expressed as a ratio such as 1:1,000, meaning that 1 of any unit of measurement on the viewing window corresponds exactly or approximately to 1,000 actual units. For example, in a case in which a viewing window is measured in inches, the distance scale may translate an inch of the viewing window to a length of 1,000 miles (or kilometers).”; Paragraph 0090: “an algorithm may be used to set viewing bands based on a vertical position on a display screen. The algorithm may use a function that outputs a ratio of map plane pixel depth to display screen (viewing plane) pixel height based on a depth dimension of the map plane… A map pixel depth may refer to a distance dimension 1543 of the unit of area of the map plane (see FIG. 15C). A display screen pixel height may refer to the height of a display screen pixel which may be represented by length 1544 (see FIG. 15C).”,
Supplemental Note: the amount of map data to show depth (map plane pixel depth) depends on the viewing plan pixel height within the display).
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have been modified the invention disclosed by Arikan with the teachings of Cornell with a reasonable expectation of success. Please refer to the rejection of claim 3 as both claim the same function and therefore rejected under the same pretenses.
Regarding claim 18, Arikan, as modified, teaches wherein the feature points comprise: vertices of outline of the target area, vertices of a circumscribed quadrangle of outline of the target area, vertices of a covering outline in the target area or any combination thereof (Arikan: Col. 14, lines 20 – 64,
Supplemental Note: the tiles are generated for a target area. Map tiles are known by one with knowledge in the art to represent a portion of a larger map set by geometric shapes).
Regarding claim 19, Arikan, as modified, teaches wherein the feature points comprise the vertices of outline of the target area and the vertices of the circumscribed quadrangle of outline of the target area, the processor is configured to: determine a basic vertex as an origin among the vertices of the circumscribed quadrangle; (Arikan: Col. 9, lines 14 – 21; Col. 9, lines 35 – 57,
Supplemental Note: in this example, the circumscribed quadrangle pertains to the route with the user selecting their starting and ending points. The vertex that is defined as the origin along the path is interpreted as the starting location)
calculate first distances in a width direction and second distances in a height direction from other feature points excluding the base vertex to the base vertex; and
determine coordinates of the other feature points according to the first distances and the second distances. (Arikan: Col. 18, lines 14 – 48,
Supplemental Note: the road segment consists of a string of coordinates indicating its location and parameters for width and offset distances to analyze the sides of the roads)
Regarding claim 22, Arikan teaches a non-transitory computer-readable storage medium, on which a computer program is stored, wherein the program, when executed by a processor, causes the processor to: (Arikan: Col. 59, lines 41 – 56)
load a function of displaying and/or drawing maps in a server, and (Arikan: Col. 14, lines 23 – 32)
call an application programming interface (API) of the server, (Arikan: Col. 2, lines 1 – 16,
Supplemental Note: the server data is able to provide data of geometry data of the map features to the device with the application)
wherein the API provides a geometry utility function library for calculating spatial information corresponding to the function; (Arikan: Col. 11, lines 6 – 32,
Supplemental Note: the application which can show maps in 3D or 2D are interpreted as the geometry utility function library)
receive an identifier input by a user and determine a target area corresponding to the identifier; (Arikan: Col. 7, lines 66 – Col. 8, line 27,
Supplemental Note: the identifier is interpreted as the area the user wants to search)
process, through the geometry utility function library, geographic information of the target area, (Arikan: Col. 11, lines 45 – 57,
Supplemental Note: geographic information of the building and roads surrounding are used to show a 3D navigation view)
… coordinates of one or more feature points in the target area; (Arikan: Col. 18, lines 21 – 27,
Supplemental Note: the geometry information includes a string of coordinates representing the center of the road).
In sum, Arikan teaches a non-transitory computer-readable storage medium, on which a computer program is stored, wherein the program, when executed by a processor, causes the processor to: load a function of displaying and/or drawing maps in a server, and call an application programming interface (API) of the server, wherein the API provides a geometry utility function library for calculating spatial information corresponding to the function; receive an identifier input by a user and determine a target area corresponding to the identifier; process, through the geometry utility function library, geographic information of the target area, coordinates of one or more feature points in the target area. Arikan however does not teach to determine a height and a width of the target area and determine a container height and a container width of a container for display; determine a canvas height and a canvas width according to the height, the width, the container height and the container width; determine a ratio of distance to pixels in the canvas according to the width of the target area and the canvas width, or according to the height of the target area and the canvas height; determine pixel coordinates of the feature points in the canvas according to the ratio and the coordinates; and generate a map of the target area in the canvas according to the pixel coordinates, and display the map of the target area for the user to view.
Cornell teaches to determine a height and a width of the target area and (Cornell: Paragraph 0078,
Supplemental Note: the map data tiles are equivalent to the target area. The amount of map tiles shown depends on the viewing window, if the viewing window is the same size as the display screen, the map data tiles able to fit within the display window are shown)
… determine a container height and a container width of a container for display;
determine a canvas height and a canvas width according to the height, the width, the container height and the container width; (Cornell: Paragraph 0031; Paragraph 0048; Paragraph 0078; Paragraph 0090,
Supplemental Note: The physical size of the display is interpreted as the container height. The whole of the display or parts of the display can be used is used to display the map surface thus, the display size is also equivalent to the canvas height)
determine a ratio of distance to pixels in the canvas according to the width of the target area and the canvas width, or according to the height of the target area and the canvas height; (Cornell: Paragraph 0049; Paragraph 0090,
Supplemental Note: the amount of map data to show depth (map plane pixel depth) depends on the viewing plan pixel height within the display)
determine pixel coordinates of the feature points in the canvas according to the ratio and the coordinates; and
generate a map of the target area in the canvas according to the pixel coordinates, and display the map of the target area for the user to view (Cornell: Paragraph 0092; Paragraph 0035; Paragraph 0066,
Supplemental Note: the map on the screen is able to show map features of roads and buildings. The positions of these features are already gathered within the map data, thus using the vertical position, zoom level and tilt angle corresponding to the ratio of the map pixel depth and screen pixel, the pixel coordinates of these features are determined. Please see Figure A as it shows the map features within the display).
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have been modified the invention disclosed by Arikan with the teachings of Cornell with a reasonable expectation of success. Please refer to the rejection of claim 1 as both claim the same function and therefore rejected under the same pretenses.
Claim(s) 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Arikan et al. (US 9489754 B2) and Cornell et al. (US 20130093750 A1) as applied to claim 1 above, and further in view of Hamby et al. (US 20190043227 A1).
Regarding claim 6, Arikan, as modified, teaches further comprising: calculating the first distances and the second distances, and (Arikan: Col. 18, lines 14 – 48: “FIG. 8 illustrates the data structure 800 of some embodiments for a road segment as well as the data structure 815 for a junction. As shown, the road segment includes a segment ID (i.e., a unique identification), one or more names, geometry information, and attribute information. The geometry information (which is different than the road geometries created for defining vector data) defines the path and other geometric information about a road segment. As shown, the geometry information includes centerline path data (e.g., an ordered string of coordinates that define the center of the road), start and end junction information, parameters to indicate the width and offset with respect to the centerline, and functionality enabling evaluation of the sides of the road at any point along the road segment. In some embodiments, this is a function on the road segment class that utilizes the centerline, offset, and width information to calculate the location of the sides of the road. While this diagram shows the road drawing data including start and end junctions, some embodiments do not define one as the start and one as the end, but rather simply indicate two junction IDs as endpoints (or a single junction ID if the road segment dead-ends). The attribute information describes metadata about the road segment, such as the road type (or functional road class, which defines the level of importance of a road, from freeway down to pseudo path), the number of lanes, the speed limit, the relative elevation of the road (which may contain references to one or more other road segments and/or junctions, indicating that the present road segment runs below or above the referenced object), the height of the road (relevant for identifying elevation), the form of way (which defines a path as a dual carriageway, single carriageway, walkway, stairs, connector road, slip road, etc.), restrictions (e.g., toll restrictions, vehicle type restrictions, indications that a road is private, etc.).”,
Supplemental Note: the road segment consists of a string of coordinates indicating its location and parameters for width and offset distances to analyze the end of the sides of the roads).
In sum, Arikan teaches wherein the first distances and the distance are calculated. Arikan however does not teach the height and the width are determined according to a base class related manner provided by the API.
Hamby teaches determining the height and the width through a function of distance calculation in the geometry utility function library provided by the API (Hamby: Paragraph 0006: “The present invention enables dynamic rendering of digital maps. A system in an embodiment of the present invention includes a web server, a mapping engine and a map database. The web server receives a request from a client specifying a location and a bounding area. In one embodiment the location is specified as an address, while in an alternative embodiment it is specified as a latitude and longitude. The mapping engine performs a geocoding operation on the address, if necessary, and creates a tile grid centered at the specified location. A seed tile is then created, either including or adjacent to the center location, depending on whether the tile grid has an even or odd number of rows and columns. The web server creates a resource identifier such as a URL for each tile in the tile grid, and returns the tile grid including the resource identifiers to the client. The resource identifier for each tile includes the location of the seed tile and a position offset for the tile relative to the seed tile, in one embodiment specified in units of northward and eastward movement.”: Paragraph 0024 – 0025: “FIG. 2 illustrates a method for responding to a request for a tile grid in accordance with an embodiment of the present invention. Initially, web server 102 receives 202 a request from client 108 for a tile grid. In one embodiment, client 108 makes the request by providing an XML query. An example of such a query is illustrated in FIG. 3. In listing 300, line 2 specifies a desired pixel width and height attributes for each tile within the grid. Lines 3-10 indicate that the address to be centered on is “4 N. 2.sup.nd St, San Jose, Ca” with a 1 km radius bounding area. Line 11 indicates that the grid should include 4 rows and 4 columns. Server 102 then determines 204 whether the request includes an address that must be geocoded, for example a street address. If so, mapping engine 106 performs a geocoding operation and returns a latitude and longitude for the specified address to web server 102. Next, or if no geocoding was required, server 102 determines 208 the position of a seed tile. In one embodiment, if the number of rows and columns is even, the seed tile is the tile that borders the center to the northeast. If the number of rows and columns is odd, seed tile is the tile that includes the center d02. Those of skill in the art will appreciate that other tiles can be defined as the seed tile in alternative embodiments.”).
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the invention disclosed by Arikan with the teachings of Hamby with a reasonable expectation of success. Both Arikan and Hamby teach the ability to acquire tiles of a geographic region based on the area a user requires. These tiles to one with knowledge in the art would be a simple substitution as both Arikan and Hamby utilize these map tiles for a generated view of that location on a display. Hamby teaches the tiles are measured in specified units, thus would improve the mapping system of Arikan as it can utilize these units to more accurately lay out tiles for the user.
Response to Arguments
Applicant’s arguments, see section Claims 1-6, 8-19 and 22 are rejected under 35 U.S.C. 103 as being unpatentable over Arikan (US 9489754 B2), further in view of Hamby (US 20190043227 Al) and Scarr (US10921150 B2) of the REMARKS, filed 03/30/2026, with respect to the 35 U.S.C. 103 prior art rejection of claims 1 – 6, 8 – 19 and 22 has been fully considered but are not fully persuasive.
Applicant states Hamby does not teach the claim limitation of independent claim 1 stating: “processing geographic information of the target area, to determine a height and a width of the target area”. Regarding the limitation of “processing geographic information of the target area”, Examiner states that the prior art of Arikan does teach this limitation as it is able to determine the location of buildings and roads within a 3D map view. Thus, Arikan teaches the ability of being able to process information about the target area. The claim limitation of “to determine a height and width of the target area”, Examiner agrees that is not taught in view of Hamby, however through further search and consideration a rejection has been made in view of Cornell (US 20130093750 A1). Independent claims 15 and 22 recite a similar claim limitation as claim 1, thus this response also applies to those claims as well.
Applicant further states Arikan does not teach the claim limitation of independent claim 1 stating: “determining a canvas height and canvas width according to the height, the width, the container height and container width”. Examiner agrees with Applicant, however through further search and consideration a rejection has been made in view of Cornell (US 20130093750 A1). Independent claims 15 and 22 recite a similar claim limitation as claim 1, thus this response also applies to those claims as well.
Applicant further states neither Arikan nor Arikan in view of Hamby and Scarr, teach the claim limitation of independent claim 1 stating: “determining a ratio of distance to pixels in the canvas according to the width of the target area and the canvas width, or according to the height of the target area and the canvas height;”. Examiner agrees with Applicant, however through further search and consideration a rejection has been made in view of Cornell (US 20130093750 A1). Independent claims 15 and 22 recite a similar claim limitation as claim 1, thus this response also applies to those claims as well.
Applicant further states neither Arikan nor Arikan in view of Hamby and Scarr, teach the claim limitation of claim 3 stating: “determining a ratio of the canvas width to the width of the target area, or a ratio of the canvas height to the height of the target area as the ratio”. Examiner agrees with Applicant, however through further search and consideration a rejection has been made in view of Cornell (US 20130093750 A1). Independent claims 15 and 22 recite a similar claim limitation as claim 1, thus this response also applies to those claims as well.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHIVAM SHARMA whose telephone number is (703)756-1726. The examiner can normally be reached Monday-Friday 8:00-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, Erin Bishop can be reached at 571-270-3713. 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.
/SHIVAM SHARMA/Examiner, Art Unit 3665
/David P. Merlino/Primary Examiner, Art Unit 3665
Prosecution Insights