DETAILED CORRESPONDENCE
This Office action is in response to the application filed 10/16/2024, with claims 1-7 pending.
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 .
Information Disclosure Statement
At the time of the first Office action on the merits, no information disclosure statements (IDS) submission was found in the file wrapper. Accordingly, there is no IDS for the Examiner to consider.
Drawings
The drawings are objected to under 37 CFR 1.83(a) because they fail to show the written descriptive labels for the blocks in the block diagrams of figure 1 and figure 2 are absent. Figures 1 and figure 2 are both missing at least a ledger detailing the meaning of each item number. Any structural detail that is essential for a proper understanding of the disclosed invention should be shown in the drawing. MPEP § 608.02(d). Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-7 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Claim 1 recites:
A map service providing method based on autonomous driving simulation testing, wherein the method is implemented using an emulator, a map server, a server, and a map engine, comprising:
performing a scenario building step, wherein the emulator is used for building a test scenario and converting the test scenario to a first format of map data;
performing a map uploading step, wherein the first format of map data is uploaded to the map server;
performing a map downloading step, wherein the server downloads the first format of map data from the map server in the case that the server requires to access to the first format of map data;
performing an own-vehicle positioning step, wherein the emulator uploads own-vehicle positioning information to the server;
performing a map parsing step, wherein the map engine obtains the own-vehicle positioning information from the server and obtains own-vehicle surrounding road network information according to parsing of the own-vehicle positioning information and the first format of map data;
performing a route generation step, wherein the map engine generates a planning path according to a simulation origin and a simulation endpoint, wherein the simulation origin and simulation endpoint are disposed in the emulator and provided to the map engine via the server by uploading to the server;
performing a map data conversion step, wherein the map engine converts the own-vehicle surrounding road network information and the planning path to a second format of map data and returns the second format of map data to the server; and
performing a map service providing step, wherein the server obtains the second format of map data and provides the second format of map data as a map service to the emulator.
Step 1: Statutory category- Yes
The claim 1 recites an method including at least one step. The claim falls within one of the four statutory categories. See MPEP 2106.03
Step 2A Prong one evaluation: Judicial Exception - Yes - Mathematical processes.
In Step 2A, Prong one of the 2019 Patent Eligibility Guidance (PEG), a claim is to be analyzed to determine whether it recites subject matter that falls within one of the following groups of abstract ideas: a) mathematical concepts, b) mental processes, and/ or c) certain methods of organizing human activity.
The Office submits that the foregoing bolded limitation(s) constitutes judicial exceptions in terms of “mathematical concept” because under its broadest reasonable interpretation, the limitations are a “relationship between variables or numbers”. See MPEP 2106.04(a)(2)(I).
The claim recites (in-part):
performing a scenario building step, wherein the emulator is used for building a test scenario and converting the test scenario to a first format of map data;
performing a map uploading step, wherein the first format of map data is uploaded to the map server;
performing a map downloading step, wherein the server downloads the first format of map data from the map server in the case that the server requires to access to the first format of map data;
performing an own-vehicle positioning step, wherein the emulator uploads own-vehicle positioning information to the server;
performing a map parsing step, wherein the map engine obtains the own-vehicle positioning information from the server and obtains own-vehicle surrounding road network information according to parsing of the own-vehicle positioning information and the first format of map data;
performing a route generation step, wherein the map engine generates a planning path according to a simulation origin and a simulation endpoint, wherein the simulation origin and simulation endpoint are disposed in the emulator and provided to the map engine via the server by uploading to the server;
performing a map data conversion step, wherein the map engine converts the own-vehicle surrounding road network information and the planning path to a second format of map data and returns the second format of map data to the server; and
performing a map service providing step, wherein the server obtains the second format of map data and provides the second format of map data as a map service to the emulator.
These “performing” limitations, as drafted, under their broadest reasonable interpretation, covers performance of these limitations using mathematical concepts. For example, but for the “performing” language, the claims encompasses that a model on a processor computes the mathematical relationship between the collected data from various sensors and map data. The mere recitation of performing a route generation step, wherein the map engine generates a planning path according to a simulation origin and a simulation endpoint, wherein the simulation origin and simulation endpoint are disposed in the emulator and provided to the map engine via the server by uploading to the serve does not take the claim limitations out of the mathematical process grouping because the claim language does not positively recite controlling the subject vehicle via the generated route (emphasis added).
Thus, the claim 1 recites a mathematical processes.
Step 2A Prong two evaluation: Practical Application – No
In Step 2A, Prong two of the 2019 PEG, a claim is to be evaluated whether, as a whole, it integrates the recited judicial exception into a practical application. As noted in MPEP 2106.04( d), it must be determined whether any additional elements in the claim beyond the abstract idea integrate the exception into a practical application in a manner that imposes a meaningful limit on the judicial exception, such that the claim is more than a drafting effort designed to monopolize the judicial exception. The courts have indicated that additional elements such as: merely using a computer to implement an abstract idea, adding insignificant extra solution activity, or generally linking use of a judicial exception to a particular technological environment or field of use do not integrate a judicial exception into a “practical application.”
However, this claim does not recite additional elements. Therefore, this claim does not use the judicial exception in a manner that imposes a meaningful limit on the judicial exception, such that the claim is more than a drafting effort designed to monopolize the exception.
Accordingly, even in combination, this additional elements does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea.
Respectively, dependent claims 2 and 3 as a whole, do not integrate the recited judicial exception into a practical application.
Regarding claims 4 and 5. Claims 4 and 5 are methods similar to the method of claim 1; therefore, claims 4 and 5 are rejected under the same rationale of claim 1.
Regarding claim 6. Claim 6 is the storage that uses the method of claim 1; therefore, claim 6 is rejected under the same rationale of claim 1.
Regarding claim 7. Claim 7 is the system that uses the method of claim 1; therefore, claim 7 is rejected under the same rationale of claim 1.
Step 2B evaluation: Inventive Concept: - No
In Step 2B of the 2019 PEG, the claim(s) is to be evaluated as to whether the claim, as a whole, amounts to significantly more than the recited exception, i.e., whether any additional element, or combination of additional elements, adds an inventive concept to the claim. See MPEP 2106.05.
As discussed with respect to Step 2A Prong Two, the claims do not recite an additional elements. The same analysis applies here in 2B, i.e., data manipulation and/or data output to apply an exception on a generic computer cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B, MPEP 2106.0S(f).
Thus, these claims are ineligible.
Claim 6 is rejected under 35 USC § 101 because this claim is directed to a non-statutory subject matter.
The claimed invention does not fall within at least one of the four categories of patent eligible subject matter recited in 35 U.S.C. 101 (process, machine, manufacture, or composition of matter) because in view of the ordinary and customary meaning of “computer readable medium” is broad enough to encompass forms of non-transitory tangible media as well as transitory propagating signals, which are non-statutory per se (In re Nuijten). As currently claimed, one skilled in the art would reasonably conclude that the scope of the claim covers transitory media such as electromagnetic and other signals, as it is commonplace to use transitory signals as a means for recording executable software for transmission to a computing device. Therefore, the claims 13-20 as a whole are non-statutory. See MPEP 2106.03.
The Examiner suggests amending the claim to recite “non-transitory computer readable storage medium” which would serve to exclude non-statutory subject matter from the claim's scope.
Claim Rejections - 35 USC § 102
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.
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim 1, 2, and 4-7 are rejected under 35 U.S.C. 102 (a)(1) as being anticipated by D’Avanzo et al., US 2024/0060788 hereinafter “D’Avanzo”.
Claims 1 and 4-7. D’Avanzo teaches a map service providing method based on autonomous driving simulation testing, wherein the method is implemented using an emulator, a map server, a server, and a map engine, comprising:
performing a scenario building step, wherein the emulator is used for building a test scenario and converting the test scenario to a first format of map data ([0079] reads on this element as such—“The simulation platform 756 may enable testing and validation of the algorithms, machine learning models, neural networks, and other development efforts for the AV 702, the remote assistance platform 758, the ridesharing platform 760, the map management platform 762, and other platforms and systems. The simulation platform 756 may replicate a variety of driving environments and/or reproduce real-world scenarios from data captured by the AV 702, including rendering geospatial information and road infrastructure (e.g., streets, lanes, crosswalks, traffic lights, stop signs, etc.) obtained from the map management platform 762; modeling the behavior of other vehicles, bicycles, pedestrians, and other dynamic elements; simulating inclement weather conditions, different traffic scenarios; and so on. In some embodiments, the simulation platform 756 may include a map simulation tester 757 (e.g., similar the map simulation tester 120) that generates map test cases for a map based on ODD information and/or map test configuration, evaluates a vehicle compute process or planning process against the map test cases, and determines a metric for the map….” While [0061] teaches “At 606, a map test object including the plurality of map test cases is output. The map test object may be stored in a data structure or database including all the generated map test cases in any suitable format. The map test object can be stored and loaded into a simulator (e.g., the simulation platform 110 of FIG. 1 or the simulation platform 756 of FIG. 7) for map testing and/or AV planning stack testing at any suitable time.” Thus, taken together the cited section reads on this element. Also, [0045] teaches “Accordingly, the map simulation tester 120 may generate 5000 map test cases covering 200 traffic links in an area bounded by the geofence, where each map test cases may include one of a plurality of paths along one or more traffic links or traffic link segments in the area. In some instances, the map simulation tester 120 may further receive ODD information (e.g., the ODD information 140) indicating one or more avoidance areas (e.g., a blacklist including area(s), street(s), and/or lane(s) to avoid)”);
performing a map uploading step, wherein the first format of map data is uploaded to the map server ([0030] reads on this section as such—“In some examples, the simulation platform 110 can include a map storage 130 in which map data may be stored. In other examples, the map storage 130 may located at a remote server or cloud storage, for example, provided by a map service, and the simulation platform 110 may request for the map 102 from the map service.” Here the uploaded map data to the server is implied.);
performing a map downloading step, wherein the server downloads the first format of map data from the map server in the case that the server requires to access to the first format of map data (Taken together [0030] along with [0061] reads on this element as such “…the map storage 130 may located at a remote server or cloud storage, for example, provided by a map service, and the simulation platform 110 may request for the map 102 from the map service ….At 606, a map test object including the plurality of map test cases is output. The map test object may be stored in a data structure or database including all the generated map test cases in any suitable format. The map test object can be stored and loaded into a simulator (e.g., the simulation platform 110 of FIG. 1 or the simulation platform 756 of FIG. 7) for map testing and/or AV planning stack testing at any suitable time.” Thus, taken together the cited section reads on this element.);
performing an own-vehicle positioning step, wherein the emulator uploads own-vehicle positioning information to the server ([0015] reads on this element as such—“As part of planning, the AV may access map information and localize itself based on location information (e.g., from location sensors) and the map information. Subsequently, instructions can be sent to a controller to control the AV (e.g., for steering, accelerating, decelerating, braking, etc.) according to the planned path….”);
performing a map parsing step, wherein the map engine obtains the own-vehicle positioning information from the server and obtains own-vehicle surrounding road network information according to parsing of the own-vehicle positioning information and the first format of map data ([0069] reads on this element as such—“Mapping and localization stack 714 may determine the AV's position and orientation (pose) using different methods from multiple systems (e.g., GPS, IMUs, cameras, LIDAR, RADAR, ultrasonic sensors, the HD geospatial database 722, etc.). For example, in some embodiments, the AV 702 may compare sensor data captured in real-time by the sensor systems 704-708 to data in the HD geospatial database 722 to determine its precise (e.g., accurate to the order of a few centimeters or less) position and orientation. The AV 702 may focus its search based on sensor data from one or more first sensor systems (e.g., GPS) by matching sensor data from one or more second sensor systems (e.g., LIDAR). If the mapping and localization information from one system is unavailable, the AV 702 may use mapping and localization information from a redundant system and/or from remote data sources. Paragraphs [0032]-[0035] also reads on this element because it teaches a “plurality of path in the geographical area”);
performing a route generation step, wherein the map engine generates a planning path according to a simulation origin and a simulation endpoint, wherein the simulation origin and simulation endpoint are disposed in the emulator and provided to the map engine via the server by uploading to the server ([0015] along with [0056] reads on this element as such—“The predictions may be used to plan a path for the AV (e.g., from a starting position to a destination). As part of planning, the AV may access map information and localize itself based on location information (e.g., from location sensors) and the map information. Subsequently, instructions can be sent to a controller to control the AV (e.g., for steering, accelerating, decelerating, braking, etc.) according to the planned path….For instance, the vehicle planning process may be executed in a simulator configured with a traffic scenario as specified by each map test case, and the performance of the vehicle planning process will be evaluated (e.g., whether the vehicle planning process successfully navigate through a respective path).”);
performing a map data conversion step, wherein the map engine converts the own-vehicle surrounding road network information and the planning path to a second format of map data and returns the second format of map data to the server (fig. 4A illustrates a conversion process in which the map simulation tester 120 receives ODD information in real time regarding the geographical area, see [0030]-[0033] and fig. 1. Here ODD is certain map data type. While [0049] teaches “map data integration” and [0027] teaches the concept of data compatibility “between vehicle planning and map data”. Which implies that vehicle planning data is in a different format from the map test cases data); and
performing a map service providing step, wherein the server obtains the second format of map data and provides the second format of map data as a map service to the emulator ([0077]—teaches that the data management platform as illustrated in fig. 7 is “capable of receiving and transmitting data”….the data is “data of different types (e.g., sensor data, mechanical system data, ridesharing service data, map data, audio data, video data, etc.” Here the server is transmitting and receiving at least second format of map data). Furthermore, D’Avanzo in [0093] teaches “The particular sequence of such executable instructions or associated data structures represents examples of corresponding acts for implementing the functions described in such steps.” While [0049] teaches “map data integration” which is form of conversion. Additionally, [0090] teaches a “non-transitory and/or computer-readable memory device”.
Claim 2. D’Avanzo teaches the map service providing method based on autonomous driving simulation testing according to claim 1 and further teaches, wherein: the first format of map data is map data in Opendrive format, and the second format of map data is map data in PNC format ([0061] reads on this element as such—“At 606, a map test object including the plurality of map test cases is output. The map test object may be stored in a data structure or database including all the generated map test cases in any suitable format. The map test object can be stored and loaded into a simulator (e.g., the simulation platform 110 of FIG. 1 or the simulation platform 756 of FIG. 7) for map testing and/or AV planning stack testing at any suitable time.” Here the map testing data is different data type from the AV planning stack and is being considered as an Opendrive format. While the AV planning stack is being considered as an PNC format. Furthermore, [0077] teaches that data management platform uses variety data type.)
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over D’Avanzo in view of Stankoulov, US 2024/0005296.
Claim 3. D’Avanzo teaches the map service providing method based on autonomous driving simulation testing according to claim 1; however, D’Avanzo is silent on
authentication.
Yet, Stankoulov teaches wherein: in the map downloading step, the server requires to perform an identity authentication before downloading the map data from the map server and is configured to download the map data from the map server only in the case that the identity authentication is successful (fig. 13 best illustrates verification process. Here the user information may be validated or denied at step 1330. While fig. 5 best illustrates service point map service).
Therefore, it would have been obvious to one of ordinary skills in the art before the effective filing data of the claimed invention to combined the teaching of Stankoulov with the invention of D’Avanzo because such combination would to provide ubiquitous contactless vehicle identification to enable services and payments for users while inside a vehicle in a fast and secure manner, and without touching buttons or handing out cards or cash. (see [0027], Stankoulov).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
S. K. Y. Donzia, H. -K. Kim and Y. P. Geum, "Implementation of Autoware Application to real-world Services Based Adaptive Big Data Management System for Autonomous Driving," 2021 21st International Conference on Computational Science and Its Applications (ICCSA), Cagliari, Italy, 2021, pp. 251-257 –This reference teaches an autonomous driving software component that uses big data services.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ANA D THOMAS whose telephone number is (571)272-8549. The examiner can normally be reached Monday - Friday 8 - 5.
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, Ramya Burgess can be reached at 571-272-6011. 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.
/A.D.T/Examiner, Art Unit 3661
/RUSSELL FREJD/Primary Examiner, Art Unit 3661