DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
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 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.
Examiner’s Note
Examiner has cited particular paragraphs/columns and line numbers or figures in the references as applied to the claims below for convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations with the individual claim, other passages and figures may apply as well. It is respectfully requested from the applicant, in preparing the responses, to fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner. Applicant is reminded that the Examiner is entitled to give the broadest reasonable interpretation to the language of the claims. Furthermore, the Examiner is not limited to the Applicant’s definition which is not specifically set forth in the claims.
Information Disclosure Statements
The Information Disclosure Statement(s) (IDS) filed on 10/11/2024 (both IDS documents on file were filed 10/11/2024) has/have been acknowledged.
Specification
The lengthy specification has not been checked to the extent necessary to determine the presence of all possible minor errors. Applicant's cooperation is requested in correcting any errors of which applicant may become aware of, in the specification.
Drawing Objections
The drawings are objected to because Figure 4 as filed 10/03/2024 lacks clarity due to the overlapping grayscale regions in the Figure, which makes it difficult to visually discern the cited “satellite imagery post sunset in a city at multiple time stamps,” which the Applicant indicates as present in Figure 4 in at least paragraph 0033 of the Applicant’s specification.
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. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. The figure or figure number of an amended drawing should not be labeled as “amended.” If a drawing figure is to be canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the remaining figures must be renumbered and appropriate changes made to the brief description of the several views of the drawings for consistency. Additional replacement sheets may be necessary to show the renumbering of the remaining figures. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Status of Application
The list of claims 1-20 are pending in this application. In the claim set filed 10/03/2024:
Claim(s) 1, 11 and 20 is/are the independent claim(s) observed in the application.
Claim Objections
Claim(s) 1, 2, 8, 9, 11, 12, 17, 18 and 20 is/are objected to because of the following minor informalities:
Claim(s) 1, 11 and 20 contain(s) the same minor grammatical error namely: “by identifying a lighting metrics based on pixel values.” Therefore, appropriate correction is required such that claim(s) 1, 11 and 20 should instead respectively recite: “by identifying lighting metrics based on pixel values.”
Claim(s) 2 and 12 contain(s) the same minor antecedent basis issues due to recitation of the term “pickup and drop-off locations;” however, claims 1 and 11, from which claims 2 and 12 respectively depend, already recite “a pickup location” and “a drop-off location.” Therefore, appropriate correction is required such that claims 2 and 12 should instead respectively recite: “the pickup and drop-off locations.”
Claim(s) 8 and 17 contain(s) the same minor antecedent basis issues due to recitation of the term “pickup and drop-off locations;” however, claims 1 and 11, from which claims 8 and 17 respectively depend, already recite “a pickup location” and “a drop-off location.” Therefore, appropriate correction is required such that claims 8 and 17 should instead respectively recite: “the pickup and drop-off locations.”
Claim(s) 9 and 18 contain(s) the same minor antecedent basis issues due to recitation of the term “residential areas;” however, claims 2 and 12, from which claims 9 and 18 respectively depend, already recite “residential areas.” Therefore, appropriate correction is required such that claims 9 and 18 should instead respectively recite: “the residential areas.”
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.
Claim(s) 1, 11 and 20 is/are rejected under 35 USC 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Claim(s) 1, 11 and 20 is/are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claim(s) recite(s) “a computer-implemented method” (claim 1), “A computing system comprising: a memory that stores instructions; and one or more processors configured by the instructions to perform operations” (claim 11), and “A non-transitory computer-readable medium comprising instructions stored thereon that are executable by at least one processor to cause a computing system to perform operations” (claim 20) to perform the following: 1) receiving a request for service indicating a start location and a destination location for the service; 2) determining that a time of day for the request for service triggers a safety analysis; 3) analyzing the start location and destination location to identify a pickup location to start the service and a drop-off location to end the service based on lighting metrics associated with the pickup location and the drop-off location; 4) generating a plurality of candidate routes for the service from the pickup location to the drop-off location; 5) generating a safety score for each candidate route of the plurality of candidate routes by identifying a lighting metrics based on pixel values in imagery for each segment of each candidate route; 6) selecting a route for the service based on a least the safety score of each candidate route; and 7) and providing the selected route to the computing device.
The limitations of 1) receiving a request for service indicating a start location and a destination location for the service; 2) determining that a time of day for the request for service triggers a safety analysis; 3) analyzing the start location and destination location to identify a pickup location to start the service and a drop-off location to end the service based on lighting metrics associated with the pickup location and the drop-off location; 4) generating a plurality of candidate routes for the service from the pickup location to the drop-off location; 5) generating a safety score for each candidate route of the plurality of candidate routes by identifying a lighting metrics based on pixel values in imagery for each segment of each candidate route; 6) selecting a route for the service based on a least the safety score of each candidate route; and 7) and providing the selected route to the computing device, as drafted, is a process that, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components. That is, other than reciting “a computer-implemented method,” “A computing system comprising: a memory that stores instructions; and one or more processors configured by the instructions to perform operations,” and “A non-transitory computer-readable medium comprising instructions stored thereon that are executable by at least one processor to cause a computing system to perform operations,” nothing in the claim(s) preclude(s) the steps from practically being performed in the mind. For example, but for the “a computer-implemented method,” “A computing system comprising: a memory that stores instructions; and one or more processors configured by the instructions to perform operations,” and “A non-transitory computer-readable medium comprising instructions stored thereon that are executable by at least one processor to cause a computing system to perform operations,” language, in the context of this claim encompasses the user manually performing steps of: determining that the time of day a request is received triggers a safety analysis, analyzing lighting metrics at the start location and destination of the request to identify a pick-up and drop-off location, generating a plurality of candidate routes for the identified pick-up and drop-off location, generating a safety score for each of the generated plurality of candidate routes that is by using a pen and paper to analyze pixel values of a printed image to identify lighting metrics for multiple images along segments of each of the generated plurality of candidate routes, and selecting a route based on a comparison of the respective generated safety scores. The remaining steps, 1 and 7, reciting: receiving a request for service indicating a start location and a destination location, and providing the selected route to the computing device, respectively, comprise Insignificant Extra-Solution Activity as explained in MPEP § 2106.05(g). Therefore, they are not satisfactory in integrating the exception into a practical application. Receiving a request for service indicating a start location and a destination location amounts to no more than mere data gathering, and therefore recites Insignificant Pre-Solution Activity. Providing the selected route to the computing device amounts to no more than mere outputting of data, and therefore recites Insignificant Post-Solution Activity. If claim a limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components and Insignificant Extra-Solution Activity, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
This judicial exception is not integrated into a practical application. In particular, the claim(s) only recite(s) the following additional element(s) – “a computer-implemented method,” “A computing system comprising: a memory that stores instructions; and one or more processors configured by the instructions to perform operations,” and “A non-transitory computer-readable medium comprising instructions stored thereon that are executable by at least one processor to cause a computing system to perform operations,” to perform: 1) receiving a request for service indicating a start location and a destination location for the service; 2) determining that a time of day for the request for service triggers a safety analysis; 3) analyzing the start location and destination location to identify a pickup location to start the service and a drop-off location to end the service based on lighting metrics associated with the pickup location and the drop-off location; 4) generating a plurality of candidate routes for the service from the pickup location to the drop-off location; 5) generating a safety score for each candidate route of the plurality of candidate routes by identifying a lighting metrics based on pixel values in imagery for each segment of each candidate route; 6) selecting a route for the service based on a least the safety score of each candidate route; and 7) and providing the selected route to the computing device. The “a computer-implemented method,” “A computing system comprising: a memory that stores instructions; and one or more processors configured by the instructions to perform operations,” and “A non-transitory computer-readable medium comprising instructions stored thereon that are executable by at least one processor to cause a computing system to perform operations” in these steps are recited at a high-level of generality (i.e., as a generic processor performing a generic computer function of generating, transmitting, receiving data from a generic sensor and outputting data) such that they amount no more than mere instructions to apply the exception using a generic computer component(s). Accordingly, the additional elements do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim(s) is/are directed to an abstract idea.
The claim(s) do/does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of “a computer-implemented method,” “A computing system comprising: a memory that stores instructions; and one or more processors configured by the instructions to perform operations,” and “A non-transitory computer-readable medium comprising instructions stored thereon that are executable by at least one processor to cause a computing system to perform operations” to perform: 1) receiving a request for service indicating a start location and a destination location for the service; 2) determining that a time of day for the request for service triggers a safety analysis; 3) analyzing the start location and destination location to identify a pickup location to start the service and a drop-off location to end the service based on lighting metrics associated with the pickup location and the drop-off location; 4) generating a plurality of candidate routes for the service from the pickup location to the drop-off location; 5) generating a safety score for each candidate route of the plurality of candidate routes by identifying a lighting metrics based on pixel values in imagery for each segment of each candidate route; 6) selecting a route for the service based on a least the safety score of each candidate route; and 7) and providing the selected route to the computing device amount to no more than mere instructions to apply the exception using a generic computer component. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. The claim(s) is/are not patent eligible.
Examiner’s Note: In order to overcome this rejection, the Office suggests further defining the limitations of the independent claim(s), for example linking the claimed subject matter to a non-generic device and controlling an apparatus in a specific way based on the data comparison performed or further showing that the claimed subject matter is an improvement to a technical field. Limitations such as these suggested above would further bring the claimed subject matter out of the realm of abstract idea and into the realm of a statutory category.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, 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 set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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 under pre-AIA 35 U.S.C. 103(a), the examiner presumes that the subject matter of the various claims was commonly owned at the time any inventions covered therein were made absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and invention dates of each claim that was not commonly owned at the time a later invention was made in order for the examiner to consider the applicability of pre-AIA 35 U.S.C. 103(c) and potential pre-AIA 35 U.S.C. 102(e), (f) or (g) prior art under pre-AIA 35 U.S.C. 103(a).
Claim(s) 1, 11 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Shirani-Mehr et al. (United States Patent Publication 2020/0318983 A1) in view of ZHANG et al. (Chinese Patent Publication 104596740 A), referenced as Shirani-Mehr and Zhang, respectively, moving forward.
With respect to claim 1, Shirani-Mehr discloses:
“A computer-implemented method comprising: receiving, from a computing device, a request for service indicating a start location and a destination location for the service” [Shirani-Mehr; ¶: "In operation 502, a computing device (e.g., a server system, such as the server system 102 or the safety determination system 124, or a client device 110) determines or receives location data corresponding to a first location and a second location. A first location may be a location of a user, as explained above, or a start or pickup location. A second location may be a destination or end location. For example, the location data may be included in a request for a route from a starting location to a destination or end location. In one example, the starting location is a current location of a user based on the location of his or her computing device (e.g., smart phone, tablet, car computer, etc.), and the destination is a location to which the user intends to travel (e.g., a pickup or drop-off location);" Fig. 5; ¶: 0064; See also: ¶: 0057-0062];
“determining that a time of day for the request for service triggers a safety analysis” [Shirani-Mehr; ¶: "The brightness profile or ambient light level for each candidate location is stored as data associated with the candidate location. The brightness profile or ambient light level may comprise various calculations based on a day of the week, a time of day, a month of year, or other factors;" ¶: 0039;
"In one example, the brightness profile is generated by storing each initial measurement (e.g., ALS data, street light data, other light data) from a geolocation. In one example, these initial measurements are stored in buckets indicating a month, day, and hour. It is to be understood that other ways of defining buckets may be used in other examples. For example, buckets can be defined using one or more of the hour of the day, the day of the week, the date, the month, the season, whether it is daytime or nighttime, and so forth. The timestamp of the measurement can be used to determine the month, day, and hour (or other date/time data) for each initial measurement. Granularity of geolocation can be configured in the order of meters, for example. For each new measurement received for that geolocation falling into the same bucket, the ambient light level is updated using the new measurement. When a request corresponding to a location is received, the timestamp of the request is used to identify the relevant bucket or buckets and return the historical ambient level for the candidate location;" 0040; See also: ¶: 0034, 0037];
“analyzing the start location and destination location to identify a pickup location to start the service and a drop-off location to end the service based on lighting metrics associated with the pickup location and the drop-off location” [Shirani-Mehr; ¶: "Brightness or ambient light levels can be determined as described above with respect to determining candidate locations for a pickup or drop-off location. For example, brightness or ambient light levels can be determined from ALS data, street lights, and so forth as explained in detail above;" ¶: 0079];
“generating a plurality of candidate routes for the service from the pickup location to the drop-off location” [Shirani-Mehr; ¶: "In operation 504, the computing device generates a plurality of candidate routes for travel from the first location to the second location (e.g., from a start location to an end location or destination), based on the location data;" Fig. 5; ¶: 0066; See also: ¶: 0057-0062];
“selecting a route for the service based on a least the safety score of each candidate route” [Shirani-Mehr; ¶: "The computing device selects a best candidate route using the safety score associated with each of the candidate routes. For example, each candidate route is associated with a safety score;" ¶: 0084; See also: Fig. 5; ¶: 0063, 0086];
“and providing the selected route to the computing device” [Shirani-Mehr; ¶: "In operation 510, the computing device provides a recommendation for a travel route comprising the best candidate;" Fig. 5; ¶: 0088];
And while Shirani-Mehr discloses “generating a safety score for each candidate route of the plurality of candidate routes” “in imagery for each segment of each candidate route” [Shirani-Mehr; ¶: "In one example, to calculate a safety score for a candidate route, a safety score for each segment within a candidate route is calculated. Subsequently, the safety scores of the segments within a route are combined to generate the safety score of the candidate route;" Fig. 5; ¶: 0069;
"In operation 506, the computing device generates a safety score for each segment of each candidate route of the plurality of candidate routes. In one example, generating a safety score is based on at least one feature of a plurality of features, such as a number of surveillance cameras located in the segment, brightness or ambient light information for the segment, crime data for the segment, and so forth;" Fig. 5; ¶: 0070; See also: ¶: 0073, 0074, 0079-0081];
Shirani-Mehr does not specifically state that the safety score generated for each candidate route of the plurality of routes based on lighting information from gathered imagery is further based on “identifying a lighting metrics based on pixel values in imagery”
Zhang, which is in the same field of invention of systems/methods for evaluating image information based on various parameters such as lighting, for example, teaches: “identifying a lighting metrics based on pixel values in imagery” [Zhang; In at least the paragraphs and figures cited, Zhang teaches at least determining a gray value of each pixel in each image by converting each RGB value of each pixel to a gray value using a formula (¶: 0032). Zhang further teaches calculating an average gray value for all the pixels across each image, as well as the average gray value across one or more images. One of ordinary skill in art, in view of at least ¶: 0038 of the Applicant's specification, that the disclosed determination of RGB values for each pixel in a plurality of images as patentably indistinct from the Applicant's broadly recited "identifying a lighting metrics based on pixel values in imagery for each segment;" See also: Fig. 4; ¶: 0030, 0031, 0033-0036].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system/method for evaluating route safety based on lighting from image data as disclosed by Shirani-Mehr to incorporate the teachings regarding determining lighting values for an image by analyzing RGB values of the respective image pixels across a plurality of images in order to compare the values as taught by Zhang with a reasonable expectation of success. By combining these inventions, the outcome is a system/method for evaluating route safety based on lighting from image data that is more robust in its ability to ensure accuracy of detection when assessing lighting values of pixels in images [Zhang; ¶: 0010].
With respect to claim 11, Shirani-Mehr discloses:
“A computing system comprising: a memory that stores instructions; and one or more processors configured by the instructions to perform operations comprising: receiving, from a computing device, a request for service indicating a start location and a destination location for the service” [Shirani-Mehr; ¶: "In operation 502, a computing device (e.g., a server system, such as the server system 102 or the safety determination system 124, or a client device 110) determines or receives location data corresponding to a first location and a second location. A first location may be a location of a user, as explained above, or a start or pickup location. A second location may be a destination or end location. For example, the location data may be included in a request for a route from a starting location to a destination or end location. In one example, the starting location is a current location of a user based on the location of his or her computing device (e.g., smart phone, tablet, car computer, etc.), and the destination is a location to which the user intends to travel (e.g., a pickup or drop-off location);" Fig. 5; ¶: 0064; See also: ¶: 0057-0062];
“determining that a time of day for the request for service triggers a safety analysis” [Shirani-Mehr; ¶: "The brightness profile or ambient light level for each candidate location is stored as data associated with the candidate location. The brightness profile or ambient light level may comprise various calculations based on a day of the week, a time of day, a month of year, or other factors;" ¶: 0039;
"In one example, the brightness profile is generated by storing each initial measurement (e.g., ALS data, street light data, other light data) from a geolocation. In one example, these initial measurements are stored in buckets indicating a month, day, and hour. It is to be understood that other ways of defining buckets may be used in other examples. For example, buckets can be defined using one or more of the hour of the day, the day of the week, the date, the month, the season, whether it is daytime or nighttime, and so forth. The timestamp of the measurement can be used to determine the month, day, and hour (or other date/time data) for each initial measurement. Granularity of geolocation can be configured in the order of meters, for example. For each new measurement received for that geolocation falling into the same bucket, the ambient light level is updated using the new measurement. When a request corresponding to a location is received, the timestamp of the request is used to identify the relevant bucket or buckets and return the historical ambient level for the candidate location;" 0040; See also: ¶: 0034, 0037];
“analyzing the start location and destination location to identify a pickup location to start the service and a drop-off location to end the service based on lighting metrics associated with the pickup location and the drop-off location” [Shirani-Mehr; ¶: "Brightness or ambient light levels can be determined as described above with respect to determining candidate locations for a pickup or drop-off location. For example, brightness or ambient light levels can be determined from ALS data, street lights, and so forth as explained in detail above;" ¶: 0079];
“generating a plurality of candidate routes for the service from the pickup location to the drop-off location” [Shirani-Mehr; ¶: "In operation 504, the computing device generates a plurality of candidate routes for travel from the first location to the second location (e.g., from a start location to an end location or destination), based on the location data;" Fig. 5; ¶: 0066; See also: ¶: 0057-0062];
“selecting a route for the service based on a least the safety score of each candidate route” [Shirani-Mehr; ¶: "The computing device selects a best candidate route using the safety score associated with each of the candidate routes. For example, each candidate route is associated with a safety score;" ¶: 0084; See also: Fig. 5; ¶: 0063, 0086];
“and providing the selected route to the computing device” [Shirani-Mehr; ¶: "In operation 510, the computing device provides a recommendation for a travel route comprising the best candidate;" Fig. 5; ¶: 0088];
And while Shirani-Mehr discloses “generating a safety score for each candidate route of the plurality of candidate routes” “in imagery for each segment of each candidate route” [Shirani-Mehr; ¶: "In one example, to calculate a safety score for a candidate route, a safety score for each segment within a candidate route is calculated. Subsequently, the safety scores of the segments within a route are combined to generate the safety score of the candidate route;" Fig. 5; ¶: 0069;
"In operation 506, the computing device generates a safety score for each segment of each candidate route of the plurality of candidate routes. In one example, generating a safety score is based on at least one feature of a plurality of features, such as a number of surveillance cameras located in the segment, brightness or ambient light information for the segment, crime data for the segment, and so forth;" Fig. 5; ¶: 0070; See also: ¶: 0073, 0074, 0079-0081];
Shirani-Mehr does not specifically state that the safety score generated for each candidate route of the plurality of routes based on lighting information from gathered imagery is further based on “identifying a lighting metrics based on pixel values in imagery”
Zhang teaches: “identifying a lighting metrics based on pixel values in imagery” [Zhang; In at least the paragraphs and figures cited, Zhang teaches at least determining a gray value of each pixel in each image by converting each RGB value of each pixel to a gray value using a formula (¶: 0032). Zhang further teaches calculating an average gray value for all the pixels across each image, as well as the average gray value across one or more images. One of ordinary skill in art, in view of at least ¶: 0038 of the Applicant's specification, that the disclosed determination of RGB values for each pixel in a plurality of images as patentably indistinct from the Applicant's broadly recited "identifying a lighting metrics based on pixel values in imagery for each segment;" See also: Fig. 4; ¶: 0030, 0031, 0033-0036].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system/method for evaluating route safety based on lighting from image data as disclosed by Shirani-Mehr to incorporate the teachings regarding determining lighting values for an image by analyzing RGB values of the respective image pixels across a plurality of images in order to compare the values as taught by Zhang with a reasonable expectation of success. By combining these inventions, the outcome is a system/method for evaluating route safety based on lighting from image data that is more robust in its ability to ensure accuracy of detection when assessing lighting values of pixels in images [Zhang; ¶: 0010].
With respect to claim 20, Shirani-Mehr discloses:
“A non-transitory computer-readable medium comprising instructions stored thereon that are executable by at least one processor to cause a computing system to perform operations comprising: receiving, from a computing device, a request for service indicating a start location and a destination location for the service” [Shirani-Mehr; ¶: "In operation 502, a computing device (e.g., a server system, such as the server system 102 or the safety determination system 124, or a client device 110) determines or receives location data corresponding to a first location and a second location. A first location may be a location of a user, as explained above, or a start or pickup location. A second location may be a destination or end location. For example, the location data may be included in a request for a route from a starting location to a destination or end location. In one example, the starting location is a current location of a user based on the location of his or her computing device (e.g., smart phone, tablet, car computer, etc.), and the destination is a location to which the user intends to travel (e.g., a pickup or drop-off location);" Fig. 5; ¶: 0064; See also: ¶: 0057-0062];
“determining that a time of day for the request for service triggers a safety analysis” [Shirani-Mehr; ¶: "The brightness profile or ambient light level for each candidate location is stored as data associated with the candidate location. The brightness profile or ambient light level may comprise various calculations based on a day of the week, a time of day, a month of year, or other factors;" ¶: 0039;
"In one example, the brightness profile is generated by storing each initial measurement (e.g., ALS data, street light data, other light data) from a geolocation. In one example, these initial measurements are stored in buckets indicating a month, day, and hour. It is to be understood that other ways of defining buckets may be used in other examples. For example, buckets can be defined using one or more of the hour of the day, the day of the week, the date, the month, the season, whether it is daytime or nighttime, and so forth. The timestamp of the measurement can be used to determine the month, day, and hour (or other date/time data) for each initial measurement. Granularity of geolocation can be configured in the order of meters, for example. For each new measurement received for that geolocation falling into the same bucket, the ambient light level is updated using the new measurement. When a request corresponding to a location is received, the timestamp of the request is used to identify the relevant bucket or buckets and return the historical ambient level for the candidate location;" 0040; See also: ¶: 0034, 0037];
“analyzing the start location and destination location to identify a pickup location to start the service and a drop-off location to end the service based on lighting metrics associated with the pickup location and the drop-off location” [Shirani-Mehr; ¶: "Brightness or ambient light levels can be determined as described above with respect to determining candidate locations for a pickup or drop-off location. For example, brightness or ambient light levels can be determined from ALS data, street lights, and so forth as explained in detail above;" ¶: 0079];
“generating a plurality of candidate routes for the service from the pickup location to the drop-off location” [Shirani-Mehr; ¶: "In operation 504, the computing device generates a plurality of candidate routes for travel from the first location to the second location (e.g., from a start location to an end location or destination), based on the location data;" Fig. 5; ¶: 0066; See also: ¶: 0057-0062];
“selecting a route for the service based on a least the safety score of each candidate route” [Shirani-Mehr; ¶: "The computing device selects a best candidate route using the safety score associated with each of the candidate routes. For example, each candidate route is associated with a safety score;" ¶: 0084; See also: Fig. 5; ¶: 0063, 0086];
“and providing the selected route to the computing device.” [Shirani-Mehr; ¶: "In operation 510, the computing device provides a recommendation for a travel route comprising the best candidate;" Fig. 5; ¶: 0088];
And while Shirani-Mehr discloses “generating a safety score for each candidate route of the plurality of candidate routes” “in imagery for each segment of each candidate route” [Shirani-Mehr; ¶: "In one example, to calculate a safety score for a candidate route, a safety score for each segment within a candidate route is calculated. Subsequently, the safety scores of the segments within a route are combined to generate the safety score of the candidate route;" Fig. 5; ¶: 0069;
"In operation 506, the computing device generates a safety score for each segment of each candidate route of the plurality of candidate routes. In one example, generating a safety score is based on at least one feature of a plurality of features, such as a number of surveillance cameras located in the segment, brightness or ambient light information for the segment, crime data for the segment, and so forth;" Fig. 5; ¶: 0070; See also: ¶: 0073, 0074, 0079-0081];
Shirani-Mehr does not specifically state that the safety score generated for each candidate route of the plurality of routes based on lighting information from gathered imagery is further based on “identifying a lighting metrics based on pixel values in imagery”
Zhang teaches: “identifying a lighting metrics based on pixel values in imagery” [Zhang; In at least the paragraphs and figures cited, Zhang teaches at least determining a gray value of each pixel in each image by converting each RGB value of each pixel to a gray value using a formula (¶: 0032). Zhang further teaches calculating an average gray value for all the pixels across each image, as well as the average gray value across one or more images. One of ordinary skill in art, in view of at least ¶: 0038 of the Applicant's specification, that the disclosed determination of RGB values for each pixel in a plurality of images as patentably indistinct from the Applicant's broadly recited "identifying a lighting metrics based on pixel values in imagery for each segment;" See also: Fig. 4; ¶: 0030, 0031, 0033-0036].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system/method for evaluating route safety based on lighting from image data as disclosed by Shirani-Mehr to incorporate the teachings regarding determining lighting values for an image by analyzing RGB values of the respective image pixels across a plurality of images in order to compare the values as taught by Zhang with a reasonable expectation of success. By combining these inventions, the outcome is a system/method for evaluating route safety based on lighting from image data that is more robust in its ability to ensure accuracy of detection when assessing lighting values of pixels in images [Zhang; ¶: 0010].
Claim Objections/Allowable Subject Matter
Claim(s) 2-10 and 12-19 is/are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims. As allowable subject matter has been indicated, applicant's reply must either comply with all formal requirements or specifically traverse each requirement not complied with. See 37 CFR 1.111(b) and MPEP § 707.07(a).
Prior Art (Not relied upon)
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure can be found in the attached form 892.
Sanchez (United States Patent 11,852,495 B1) discloses: Systems and methods are provided for providing recommendations of safe driving routes that are tailored to the driving habits of particular drivers. A machine learning model (e.g., an artificial neural network) may be trained using data indicative of insurance claim severity, road conditions, and/or vehicle telematics data associated with vehicle-related incidents, such as vehicle collisions. The machine learning model may be trained to identify road types and conditions that are predictive of claim frequency and severity. Any given driving route(s) may be provided to the trained machine learning model, and a risk value may be computed for the route(s). By further applying a personalized driver profile to the calculations of risk, personalized risk values may be computed for the route(s), and a safest route may be recommended to a driver.
Holtz et al. (United States Patent Publication 2019/0248487 A1) discloses: A technique is introduced for autonomous landing by an aerial vehicle. In some embodiments, the introduced technique includes processing a sensor data such as images captured by onboard cameras to generate a ground map comprising multiple cells. A suitable footprint, comprising a subset of the multiple cells in the ground map that satisfy one or more landing criteria, is selected and control commands are generated to cause the aerial vehicle to autonomously land on an area corresponding to the footprint. In some embodiments, the introduced technique involves a geometric smart landing process to select a relatively flat area on the ground for landing. In some embodiments, the introduced technique involves a semantic smart landing process where semantic information regarding detected objects is incorporated into the ground map.
Balva (United States Patent Publication 2021/0140777 A1) discloses: A provider, such as a transportation management service, can evaluate potential routing solutions based on various environmental metrics. Environmental metrics can include various aspect of potential routing solution that might impact routing solution desirability such as weather exposure to a predicted weather event. The evaluation can be based on weights indicating preferences of riders relating to the environmental metrics. These weights can be determined through surveys, reviews, or otherwise analyzing historical data and rider responses.
Johnson, JR. et al. (United States Patent Publication 2021/0172753 A1) discloses: To provide navigation directions for a scenic route, a machine learning model is trained using (i) characteristics of road segments that have been assigned a scenic metric and (ii) the scenic metrics for the road segments. In response to a request for navigation directions, a set of candidate routes for navigating from the starting location to the destination location is identified. Then for each road segment within each candidate route, characteristics of the road segment are applied to the machine learning model to generate the scenic metric for the road segment. A route is then selected from the set of candidate routes based at least in part on the scenic metrics of the road segments within the route. A set of navigation directions is provided for presentation on a client device for navigating from the starting location to the destination location via the selected route.
Kubin et al. (United States Patent Publication 2022/0351616 A1) discloses: Embodiments described herein provide for the generation of models, which may predict or otherwise model road safety conditions. For example, embodiments may determine attributes of roads and/or segments of roads based on sensor data, statistical data, and/or other suitable data to determine road safety models associated with the roads or road segments. Such models may be used when determining navigation routes, controlling autonomous vehicles, city planning, and/or other suitable operations that may take road safety into account.
KOBAYASHI (United States Patent Publication 2023/0291880 A1) discloses: In an image processing apparatus, an image corrector ascertains, for each pixel of a selected pixel region included in an image captured by an imaging unit, luminance-value ratios of respective colors of color filters in accordance with (i) a color luminance value of the corresponding pixel of the selected pixel region, and (ii) ascertainment data items predetermined for the respective colors if a measured illumination level around the imaging unit is lower than or equal to a predetermined threshold illumination level. The ascertainment data item, predetermined for each color, represents a corresponding color luminance-value ratio at any pixel in the selected pixel region with respect to a predetermined peak luminance value of the corresponding color in the selected pixel region. The image corrector generates a corrected image in accordance with the luminance-value ratios of the respective colors ascertained for each pixel of the selected pixel region.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RAMI N BEDEWI whose telephone number is (571)272-5753. The examiner can normally be reached Monday - Thursday - 6:00 am - 11:00 am & 12:00pm - 5:00 pm.
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, Scott A. Browne can be reached on (571-270-0151). 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.
/R.N.B./Examiner, Art Unit 3666C
/SCOTT A BROWNE/Supervisory Patent Examiner, Art Unit 3666