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
The following is a non-final, first office action in response to the communication filed 09/13/2024. Claims 1-20 are currently pending and have been examined.
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 08/02/2022 and 05/17/2023 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement has been considered by the examiner.
Claim Objections
Claims 12 and 13 are objected to because of the following informalities: it appears that the phrase “the one or more processors are further configured to” in the preamble should be removed, as suggested by analogous claim 17, and because the current preamble formulation does not appear to fit with the body of the claim. Appropriate correction is required.
Claim 15 is objected to because of the following informality: it appears that the word “is” is missing in lines 2-3: “a validity time that comprises an amount of time for which the at least one ionosphere coefficient is effective”.
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.
Claims 8 and 11-13 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 8 recites the limitation "from the at least one measurement" in line 2. There is insufficient antecedent basis for this limitation in the claim, as a measurement has not been previously introduced. For examination purposes, claim 8 will be read as "from at least one measurement".
Claim 11 recites the limitation "the ionosphere file" in line 1. There is insufficient antecedent basis for this limitation in the claim, as an ionosphere file has not been previously introduced in parent claims 10 and 1. For examination purposes, claim 10 will be read as depending on claim 2, which introduces an ionosphere file. Making this suggested change would require changing “a refresh timer” in claim 12 to “the refresh timer” in order to avoid further antecedent basis issues.
Dependent claims 12 and 13 are likewise rejected.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 2, 4, 5, 7-9, 14, 19 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Peake et al. (US-20180095177-A1; hereinafter Peake) in view of the third reference on the 11/12/2024 IDS (INTERNATIONAL GNSS SERVICE (IGS), "IGS State Space Representation (SSR) Format", Version 1.00, Available Online at: https://files.igs.org/pub/data/format/ligs_ssr_v1.pdf, October 05, 2020, 49 pages; hereinafter referred to as SSR Format).
Regarding claim 1, Peake discloses [Note: what Peake fails to disclose is strike-through]
A server device (see at least Fig. 3B, convergence data sharing system 110 comprising convergence data server 101) comprising:
one or more processors (see at least [0019]; “One or more processors in the GNSS receiver utilize the correction data along with other signal measurements to produce convergence data that allows centimeter level positioning.” See also [0061]; “Convergence data server 101 of FIG. 6 includes an address/data bus 405 for communicating information, and a processor 430A coupled to bus 405 for processing information and instructions.”) configured to:
receive a bit stream (see at least [0018]; “The correction data is received from external sources…The correction data is broadcast or otherwise provided to GNSS receivers, typically by satellite service or cellular link, but can be done by any of a number of communications links.”) corresponding to a (see at least [0018]; “The correction data is data that is used in PPP (PPP correction data) or other differential positioning techniques. The correction data may include atmospheric models (e.g., ionospheric and/or tropospheric modeling errors), orbit models (e.g., ephemeris data), and/or satellite clock errors.”);
generate, based on the bit stream, correction data (see at least [0019]; “One or more processors in the GNSS receiver utilize the correction data along with other signal measurements to produce convergence data that allows centimeter level positioning. As an example, PPP correction data may be used to generate PPP convergence data. In addition to refined correction data, the convergence data may also include…”) for correcting at least one error in at least one satellite signal due to at least one ionospheric condition (see at least [0018]; “The correction data may include atmospheric models (e.g., ionospheric and/or tropospheric modeling errors), orbit models (e.g., ephemeris data), and/or satellite clock errors.”); and
communicate the convergence data to a content delivery network for distribution (see at least [0022]; “For the purpose of the present application, the term “convergence data server” refers to a device that receives, stores, and communicates convergence data. In accordance with various embodiments, convergence data server 101 may comprise a computer system that is configured to receive convergence data (e.g., using wireless communication transceiver 103) from a converged GNSS receiver, to store the convergence data (e.g., in data storage device 102), and to convey the convergence data to another GNSS receiver that may or may not be in a converged state. In accordance with various embodiments, the convergence data may be conveyed from convergence data server 101 to the GNSS receiver directly or via an intervening communication device.”).
However, Peake does not explicitly teach that the ionospheric model used includes a spherical harmonic expansion model, and Peake does not explicitly teach generating and communicating an “ionosphere coefficient”.
Peake discloses systems that receive ionospheric correction models communicated from by satellite service or cellular link, and SSR Format teaches a standard format for communicating State Space Representation Global Navigation Satellite System correction data, including for ionospheric correction models. SSR Format teaches:
a bit stream (see at least SSR Format section 2, “An IGS SSR data stream consists of different message types…”) corresponding to a spherical harmonic expansion model of an ionosphere (see at least SSR Format section 4.5.1; “The Ionosphere Vertical TEC (VTEC) is provided using spherical harmonic expansions. A
spherical harmonic expansion allows a global and continuous model of the ionosphere but can also be applied to regional representation. It is the first constituent of a multiple stage ionospheric correction.”) for precise point positioning (PPP) (see at least SSR Format section 1; “The proposed schedule
or work plan consisted of the following major steps: …stage 2 with vertical Total Electron Content (VTEC) ionospheric message to enable code-based RT-PPP for single frequency receivers and satellite phase bias messages to enable phase-based RT-PPP…”); and
at least one ionosphere coefficient (see at least SSR Format section 8.4.1; “Table 24 through Table 27 provide the contents of the SSR Ionosphere VTEC Spherical Harmonics message. The message consists of a header part (Table 24) followed by the model for every individual ionospheric layer (Table 25 - Table 27). Every ionospheric layer model has an Ionosphere Layer Header (Table 25) and two subsequent model parts with Cosine Coefficients (Table 26) and Sine Coefficients (Table 27).”) for correcting at least one error in at least one satellite signal due to at least one ionospheric condition (see at least section 8.4; “SSR ionosphere correction message”).
Peake teaches receiving correction messages for use in PPP. SSR Format teaches a standard format for such correction messages. It would therefore have been obvious to one of ordinary skill in the art before the filing date of the claimed invention to use the format taught in SSR Format for the correction messages received by Peake, meaning those messages would correspond to a spherical harmonic expansion model, and that using the correction data would involve ionosphere coefficients.
Regarding claim 2, Peake in view of SSR Format discloses the server device of claim 1. Peake further teaches:
wherein the one or more processors are further configured to:
detect an expiration of a refresh timer (see at least [0029]; “In accordance with various embodiments, once GNSS receiver 111 has achieved convergence, it will determine new convergence data on an epoch-by-epoch basis (e.g., each second, each half second, etc.) and store the convergence data in data storage device 102.”);
encode, in response to expiration of the refresh timer, the bit stream to create an encoded bit stream (see at least [0029]; “In accordance with various embodiments, once GNSS receiver 111 has achieved convergence, it will determine new convergence data on an epoch-by-epoch basis (e.g., each second, each half second, etc.) and store the convergence data in data storage device 102.”); and
pack the encoded bit stream to generate an ionosphere file comprising the convergence data (see at least [0029]; “In accordance with various embodiments, once GNSS receiver 111 has achieved convergence, it will determine new convergence data on an epoch-by-epoch basis (e.g., each second, each half second, etc.) and store the convergence data in data storage device 102.” See also [0018]; “The correction data may include atmospheric models (e.g., ionospheric and/or tropospheric modeling errors)…”).
As discussed regarding claim 1, it would have been obvious in light of SSR Format for the ionospheric models of Peake to comprise ionosphere coefficients.
Regarding claim 4, Peake in view of SSR Format discloses the server device of claim 2. Peake further teaches:
wherein the one or more processors are further configured to:
communicate the ionosphere file to the content delivery network (see at least [0029]; “In accordance with various embodiments, once GNSS receiver 111 has achieved convergence, it will determine new convergence data on an epoch-by-epoch basis (e.g., each second, each half second, etc.) and store the convergence data in data storage device 102.” Referring to Fig. 3B, Convergence Data Server 101 is part of the content delivery network and comprises storage device 102.); and
initiate the refresh timer in response to communicating the ionosphere file (referring again to [0029], the cycle involves calculating new convergence data after saving convergence data on an epoch-by-epoch basis).
Regarding claim 5, Peake in view of SSR Format discloses the server device of claim 4. Peake further teaches:
wherein the one or more processors are further configured to:
receive, prior to expiration of the refresh timer, an additional bit stream corresponding to an additional (see at least [0029]; “In accordance with various embodiments, once GNSS receiver 111 has achieved convergence, it will determine new convergence data on an epoch-by-epoch basis (e.g., each second, each half second, etc.) and store the convergence data in data storage device 102.” See also [0018]; “The correction data may be produced at a central location where precise orbits and clocks of all tracked navigation satellites are generated and updated in real time.” The correction data is thus continuously updated after each determination of convergence data.).
As discussed regarding claim 1, it would have been obvious in light of SSR Format for the ionospheric model of Peake to be formulated as a spherical harmonic expansion model.
Regarding claim 7, Peake in view of SSR Format discloses the server device of claim 1. Peake further teaches:
wherein the bit stream is received from a PPP server (see at least [0018]; “The correction data is received from external sources. The correction data is data that is used in PPP (PPP correction data) or other differential positioning techniques. The correction data may include atmospheric models (e.g., ionospheric and/or tropospheric modeling errors), orbit models (e.g., ephemeris data), and/or satellite clock errors. The correction data may be produced at a central location where precise orbits and clocks of all tracked navigation satellites are generated and updated in real time. Atmospheric conditions that delay the propagation of the signals from the satellites may also be determined. The correction data is broadcast or otherwise provided to GNSS receivers, typically by satellite service or cellular link, but can be done by any of a number of communications links.”).
Regarding claim 8, Peake in view of SSR Format discloses the server device of claim 1. Peake further teaches:
wherein the convergence data is derived from at least one measurement of ionosphere conditions (see at least [0018]; “The correction data may include atmospheric models (e.g., ionospheric and/or tropospheric modeling errors), orbit models (e.g., ephemeris data), and/or satellite clock errors. The correction data may be produced at a central location where precise orbits and clocks of all tracked navigation satellites are generated and updated in real time. Atmospheric conditions that delay the propagation of the signals from the satellites may also be determined.”).
As discussed regarding claim 1, it would have been obvious in light of SSR Format for the ionospheric models of Peake to comprise ionosphere coefficients.
Regarding claim 9, Peake in view of SSR Format discloses the server device of claim 1. SSR Format further teaches:
wherein the spherical harmonic expansion model comprises a vertical total electron content (VTEC) spherical harmonic expansion model (see at least section 4.5.1; “The Ionosphere Vertical TEC (VTEC) is provided using spherical harmonic expansions”).
It would have been obvious to combine Peake and SSR Format for the reasons given regarding claim 1.
Regarding claim 14, Peake discloses [Note: what Peake fails to disclose is strike-through]
A server device (see at least Fig. 4B, system 100) comprising:
one or more processors (see at least [0070]; “Unless specifically stated otherwise, as apparent from the foregoing discussions, it is appreciated that throughout the description, discussions utilizing terms such as “receiving,” “utilizing,” “determining,” “deriving,” “calculating,” and “generating” refer to the actions and processes used to transform the state of a computer system, data storage system, storage system controller, microcontroller, hardware processor, or similar electronic computing device or combination of such electronic computing devices.”) configured to:
receive (see at least [0040]; “It is noted that convergence data sharing system 100 does not comprise a GNSS receiver and instead receives, stores, and disseminates convergence data from other converged GNSS receivers as they pass nearby…In accordance with various embodiments, when the convergence data sharing system of vehicle 203 receives a message from convergence data sharing system 100 indicating that it does not have convergence data, it will automatically access its data storage device and retrieve the latest convergence data. The convergence data sharing system of vehicle 203 will then automatically convey the convergence data to convergence data sharing system 100.”) at least one ionosphere correction for at least one error in at least one satellite signal due to at least one ionospheric condition (see at least [0018]; “The correction data is data that is used in PPP (PPP correction data) or other differential positioning techniques. The correction data may include atmospheric models (e.g., ionospheric…”);
store the at least one ionosphere correction (see at least [0040]; “It is noted that convergence data sharing system 100 does not comprise a GNSS receiver and instead receives, stores, and disseminates convergence data from other converged GNSS receivers as they pass nearby.”);
receive a request for updated ionosphere information (see at least [0041]; “Again, second vehicle 204 and convergence data sharing system 100 will automatically discover each other using the V2V protocols and establish a communication connection 252. Also, the convergence data sharing system of second vehicle 204 will convey that it does not have convergence data.”); and
communicate, in response to the request, the at least one ionosphere correction (see at least [0041]; “Because convergence data sharing system 100 has received and stored convergence data from vehicle 203 that is still valid based upon the time-tag, convergence data sharing system 100 will automatically access its data storage device and convey the convergence data to the convergence data sharing system of second vehicle 204.”).
However, Peake does not explicitly teach that the ionospheric models contain coefficients.
Peake discloses systems that receive ionospheric correction models communicated from by satellite service or cellular link, and SSR Format teaches a standard format for communicating State Space Representation Global Navigation Satellite System correction data, including for ionospheric correction models. SSR Format teaches:
at least one ionosphere coefficient (see at least SSR Format section 8.4.1; “Table 24 through Table 27 provide the contents of the SSR Ionosphere VTEC Spherical Harmonics message. The message consists of a header part (Table 24) followed by the model for every individual ionospheric layer (Table 25 - Table 27). Every ionospheric layer model has an Ionosphere Layer Header (Table 25) and two subsequent model parts with Cosine Coefficients (Table 26) and Sine Coefficients (Table 27).”) for at least one error in at least one satellite signal due to at least one ionospheric condition (see at least section 8.4; “SSR ionosphere correction message”).
Peake teaches receiving correction messages for use in PPP. SSR Format teaches a standard format for such correction messages. It would therefore have been obvious to one of ordinary skill in the art before the filing date of the claimed invention to use the format taught in SSR Format for the correction messages received by Peake, meaning that using the correction data would involve ionosphere coefficients.
Regarding claim 19, Peake discloses [Note: what Peake fails to disclose is strike-through]
A method, comprising:
communicating a request for ionosphere information in response to detecting at least one trigger associated with obtaining the ionospheric information (see at least [0038]; “In accordance with various embodiments, when the GNSS receiver of a vehicle is not in a converged state, the wireless communication transceiver may convey a message indicating that convergence data is needed to other V2V systems in its vicinity.” The un-converged state is mapped to the trigger condition. Correction data is taught to include ionosphere information in [0018]: “The correction data is data that is used in PPP (PPP correction data) or other differential positioning techniques. The correction data may include atmospheric models (e.g., ionospheric and/or tropospheric modeling errors)…”);
receiving, in response to the request, convergence data (see at least [0038]; “In accordance with various embodiments, once convergence data server 101-1 receives the message, it will access its own data storage device and retrieve the most recent convergence data. Convergence data server 101-1 will then send the convergence data to convergence data server 101-2 of second vehicle 202.”) for correcting at least one error in at least one satellite signal due to at least one ionospheric condition (see again [0018]); and
determining a current geographic location by using the correction data (see at least [0033]; “When a passing vehicle is detected using the V2V communication protocol, for example, convergence data sharing system 110 can provide the convergence data to the GNSS receiver of that vehicle to facilitate convergence of the receiver. In so doing, the vehicle will be able to achieve convergence of its own GNSS receiver almost instantly upon reception of the convergence data.”) to correct the at least one error in the at least one satellite signal due to the at least one ionospheric condition (see again [0018]).
However, Peake does not explicitly teach that the ionospheric models contain coefficients.
Peake discloses systems that receive ionospheric correction models communicated from by satellite service or cellular link, and SSR Format teaches a standard format for communicating State Space Representation Global Navigation Satellite System correction data, including for ionospheric correction models. SSR Format teaches:
at least one ionosphere coefficient (see at least SSR Format section 8.4.1; “Table 24 through Table 27 provide the contents of the SSR Ionosphere VTEC Spherical Harmonics message. The message consists of a header part (Table 24) followed by the model for every individual ionospheric layer (Table 25 - Table 27). Every ionospheric layer model has an Ionosphere Layer Header (Table 25) and two subsequent model parts with Cosine Coefficients (Table 26) and Sine Coefficients (Table 27).”) for at least one error in at least one satellite signal due to at least one ionospheric condition (see at least section 8.4; “SSR ionosphere correction message”).
Peake teaches receiving correction messages for use in PPP. SSR Format teaches a standard format for such correction messages. It would therefore have been obvious to one of ordinary skill in the art before the filing date of the claimed invention to use the format taught in SSR Format for the correction messages received by Peake, meaning that using the correction data would involve ionosphere coefficients.
Regarding claim 20, Peake in view of SSR Format discloses the method of claim 19. Peake further teaches:
further comprising: initiating a request timer for requesting updated ionosphere information (see at least [0032]; “Alternatively, a convergence data sharing system 110 located in a vehicle which is not currently converged can generate a query to determine whether there are any proximate convergence data servers (e.g., 101 of FIGS. 3A, 3B, and/or 3C) that have current convergence data available for sharing. In accordance with some embodiments, current convergence data is data that has been generated less than some threshold (e.g., 5 minutes) from the current time.”).
Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over Peake in view of SSR Format, further in view of Wang et al. (US-20230017707-A1; hereinafter Wang).
Regarding claim 3, Peake in view of SSR Format discloses the server device of claim 2. However, Peake does not explicitly teach:
wherein the ionosphere file is a compressed file.
Peake discloses systems that receive ionospheric correction models communicated from by satellite service or cellular link, and Wang is directed to ionosphere grid history and compression for GNSS processing. Wang teaches:
wherein the ionosphere file is a compressed file (see at least [0007]; “Certain aspects of the present disclosure relate to reducing the amount of ionosphere information that is transmitted to and/or stored by a GNSS receiver such as a UE. The amount of ionosphere information can be reduced through generating a compressed representation of an ionosphere grid product. In some implementations, the compressed representation includes coefficients of a spherical harmonic function.”).
As shown regarding claim 2, Peake in view of SSR Format teaches saving ionosphere correction data and ionosphere correction data expressed in spherical harmonics and coefficients. In light of Wang’s teachings, a file containing ionosphere correction data expressed in spherical harmonics and coefficients can be considered a compressed file due to its compressed representation of the ionosphere data.
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Peake et al. (US-20180095177-A1; hereinafter Peake) in view of SSR Format, further in view of the first reference on the 11/12/2024 IDS (Networked Transport of RTCM via Internet Protocol (Ntrip), Version 1.0, [retrieved on August 21, 2024] Available Online at: <https://gssc.esa.int/wp-content/uploads/2018/07/NtripDocumation.pdf>, 22 pages.; hereinafter referred to as NTRIP Documentation).
Regarding claim 6, Peake in view of SSR Format discloses the server device of claim 1. SSR Format further teaches:
wherein the bit stream comprises a Networked Transport of Radio Technical Commission For Maritime Services (RTCM) (see at least section 2; “The IGS SSR binary format uses the basic structure of RTCM3 developed by the RTCM SC-104.”)
It would have been obvious to combine Peake and SSR Format for the reasons given regarding claim 1.
However, Peake and SSR Format do not explicitly teach receiving data via Internet Protocol (NTRIP) bit stream.
Peake discloses systems that receive ionospheric correction models communicated from by satellite service or cellular link, and NTRIP Documentation provides documentation for Ntrip version 1.0. NTRIP Documentation teaches:
wherein the bit stream comprises a Networked Transport of Radio Technical Commission For Maritime Services (RTCM) via Internet Protocol (NTRIP) bit stream (see at least page iii, paragraph 1; “Networked Transport of RTCM via Internet Protocol (Ntrip) is an application-level protocol that supports streaming Global Navigation Satellite System (GNSS) data over the Internet. Ntrip is a generic, stateless protocol based on the Hypertext Transfer Protocol HTTP/1.1. The HTTP objects are extended to GNSS data streams.”).
Peake teaches receiving streamed ionosphere correction models from satellites. SSR Format teaches that such models may be streamed in RTCM format. NTRIP Documentation teaches that RTCM may be streamed using the NTRIP protocol. It would thus have been obvious to one of ordinary skill in the art before the filing date of the claimed invention to use the NTRIP protocol to stream the data used by Peake.
Claims 10-13 and 15-18 are rejected under 35 U.S.C. 103 as being unpatentable over Peake in view of SSR Format, further in view of 11/12/2024 IDS reference Hobiger et al. (HOBIGER et al., "Atmospheric Signal Propagation", Springer Handbook of Global Navigation Satellite Systems, Available Online at: <https://doi.org/10.1007/978-3-319-42928-1_6>, 2017, pp. 165-193.; hereinafter Hobiger).
Regarding claim 10, Peake in view of SSR Format discloses the server device of claim 1. Peake further teaches:
wherein the model can be used to correct for the at least one error in the at least one satellite signal (see at least [0032]; “Alternatively, a convergence data sharing system 110 located in a vehicle which is not currently converged can generate a query to determine whether there are any proximate convergence data servers (e.g., 101 of FIGS. 3A, 3B, and/or 3C) that have current convergence data available for sharing. In accordance with some embodiments, current convergence data is data that has been generated less than some threshold (e.g., 5 minutes) from the current time.”).
However, Peake does not specifically teach a validity time for the spherical harmonic expansion model and the at least one ionosphere coefficient.
Peake discloses systems that receive ionospheric correction models communicated from by satellite service or cellular link, and Hobiger is directed to ionospheric effects on GNSS signal propagation. Hobiger teaches:
wherein the spherical harmonic expansion model is associated with a validity time that comprises an amount of time for which the at least one ionosphere coefficient can be used to correct for the at least one error in the at least one satellite signal (see at least page 188, paragraph 2; “The model coefficients were determined by an iterative nonlinear least-squares technique applied to a long-term VTEC dataset from the Center for Orbit Determination in Europe (CODE) at the University of Berne as input. At CODE, the vertical TEC is modeled with a spherical harmonic expansion up to degree 15 and order 15 referring to a solar-geomagnetic reference frame [6.92, 93]. The two-hourly VTEC maps are derived from GPS data of the global network of the international GNSS service (IGS) [6.94].”).
Peake teaches applying ionospheric correction models to GNSS measurements to find a precise position. Hobiger teaches the generation of ionospheric models for use in measurement-based ionosphere correction of GNSS signals. It would have been obvious to one of ordinary skill in the art before the filing date of the claimed invention to use one of the ionosphere models of Hobiger, such as the NTCM model described on pages 187-188, in the ionosphere correction scenario taught by Peake.
Regarding claim 11, Peake in view of SSR Format and Hobiger discloses the server device of claim 10. Peake further teaches:
wherein the ionosphere file is distributed to user equipment (UE) according to a request timer (see at least [0032]; “Alternatively, a convergence data sharing system 110 located in a vehicle which is not currently converged can generate a query to determine whether there are any proximate convergence data servers (e.g., 101 of FIGS. 3A, 3B, and/or 3C) that have current convergence data available for sharing. In accordance with some embodiments, current convergence data is data that has been generated less than some threshold (e.g., 5 minutes) from the current time.”).
Regarding claim 12, Peake in view of SSR Format and Hobiger discloses the server device of claim 11. Peake further teaches:
the request timer (see again the 5-minute threshold for data supplied in response to requests taught in [0032]) is greater than a refresh timer (see at least [0029]; “In accordance with various embodiments, once GNSS receiver 111 has achieved convergence, it will determine new convergence data on an epoch-by-epoch basis (e.g., each second, each half second, etc.)…”), the refresh timer comprising a duration of time between generating the convergence data and generating another convergence data to update the convergence data (see at least [0018]; “The convergence data provided by the first GNSS receiver 111a to the second GNSS receiver 111b may include refinements to correction data. The correction data is received from external sources. The correction data is data that is used in PPP (PPP correction data) or other differential positioning techniques. The correction data may include atmospheric models (e.g., ionospheric…”);
It would have been obvious for the convergence data of Peake to comprise ionosphere coefficients for the reasons given regarding claim 1.
As discussed regarding claim 10, a two-hour validity time would have been obvious in view of the teachings of Hobiger. See also [0040] of Peake; “It is again noted that this convergence data is time-tagged so that once the convergence data is no longer valid (e.g., 5 minutes after it has been generated), it will not be used to attempt to attain convergence of a non-converged GNSS receiver.” Thus the request timer is less than the validity time as understood in light of Hobiger’s teachings.
Regarding claim 13, Peake in view of SSR Format and Hobiger discloses the server device of claim 11. Peake further teaches:
the request timer is 1 hour or less (see again the 5-minute threshold for data supplied in response to requests taught in [0032]);
the refresh timer is 3 minutes or less (see at least [0029]; “In accordance with various embodiments, once GNSS receiver 111 has achieved convergence, it will determine new convergence data on an epoch-by-epoch basis (e.g., each second, each half second, etc.)…”); and
As discussed regarding claim 10, a two-hour validity time would have been obvious in view of the teachings of Hobiger.
Regarding claim 15, Peake in view of SSR Format and Hobiger discloses the server device of claim 14. Peake further teaches:
wherein the convergence data is associated with a validity time that comprises an amount of time for which the convergence data effective for correcting for the at least one error in the at least one satellite signal (see at least [0032]; “Alternatively, a convergence data sharing system 110 located in a vehicle which is not currently converged can generate a query to determine whether there are any proximate convergence data servers (e.g., 101 of FIGS. 3A, 3B, and/or 3C) that have current convergence data available for sharing. In accordance with some embodiments, current convergence data is data that has been generated less than some threshold (e.g., 5 minutes) from the current time.”).
However, Peake does not specifically teach a validity time for the at least one ionosphere coefficient.
Peake discloses systems that receive ionospheric correction models communicated from by satellite service or cellular link, and Hobiger is directed to ionospheric effects on GNSS signal propagation. Hobiger teaches:
wherein the at least one ionosphere coefficient is associated with a validity time that comprises an amount of time for which the at least one ionosphere coefficient can be effective for correcting for the at least one error in the at least one satellite signal (see at least page 188, paragraph 2; “The model coefficients were determined by an iterative nonlinear least-squares technique applied to a long-term VTEC dataset from the Center for Orbit Determination in Europe (CODE) at the University of Berne as input. At CODE, the vertical TEC is modeled with a spherical harmonic expansion up to degree 15 and order 15 referring to a solar-geomagnetic reference frame [6.92, 93]. The two-hourly VTEC maps are derived from GPS data of the global network of the international GNSS service (IGS) [6.94].”).
Peake teaches applying ionospheric correction models to GNSS measurements to find a precise position. Hobiger teaches the generation of ionospheric models for use in measurement-based ionosphere correction of GNSS signals. It would have been obvious to one of ordinary skill in the art before the filing date of the claimed invention to use one of the ionosphere models of Hobiger, such as the NTCM model described on pages 187-188, in the ionosphere correction scenario taught by Peake.
Regarding claim 16, Peake in view of SSR Format and Hobiger discloses the server device of claim 15. Hobiger further teaches:
wherein the at least one ionosphere coefficient corresponds to a vertical total electron content (VTEC) spherical harmonic expansion model (see at least page 188, paragraph 2; “The model coefficients were determined by an iterative nonlinear least-squares technique applied to a long-term VTEC dataset from the Center for Orbit Determination in Europe (CODE) at the University of Berne as input. At CODE, the vertical TEC is modeled with a spherical harmonic expansion up to degree 15 and order 15 referring to a solar-geomagnetic reference frame [6.92, 93].”).
It would have been obvious to combine Peak and Hobiger for the reasons given regarding claim 15.
Regarding claim 17, Peake in view of SSR Format and Hobiger discloses the server device of claim 15. Peake further teaches:
the request is received according to a request timer (see at least [0040]; “The convergence data sharing system of vehicle 203 will then automatically convey the convergence data to convergence data sharing system 100. It is again noted that this convergence data is time-tagged so that once the convergence data is no longer valid (e.g., 5 minutes after it has been generated), it will not be used to attempt to attain convergence of a non-converged GNSS receiver.”),
the request timer is greater than a refresh timer (see at least [0029]; “In accordance with various embodiments, once GNSS receiver 111 has achieved convergence, it will determine new convergence data on an epoch-by-epoch basis (e.g., each second, each half second, etc.)…”), the refresh timer comprising a duration of time between generating the convergence data and generating another convergence data to update the convergence data (see at least [0029]; “In accordance with various embodiments, once GNSS receiver 111 has achieved convergence, it will determine new convergence data on an epoch-by-epoch basis (e.g., each second, each half second, etc.)…”)
It would have been obvious for the convergence data of Peake to comprise ionosphere coefficients for the reasons given regarding claim 14.
As discussed regarding claim 15, a two-hour validity time would have been obvious in view of the teachings of Hobiger. Thus the request timer is less than the validity time as understood in light of Hobiger’s teachings.
Regarding claim 18, Peake in view of SSR Format and Hobiger discloses the server device of claim 14. Peake does not explicitly teach:
wherein the one or more processors are further configured to:
replace a current ionosphere coefficient with the at least one ionosphere coefficient.
Peake does teach convergence data expiring, and acquiring new convergence data (see at least [0040]; “In accordance with various embodiments, when convergence data sharing system 110 of vehicle 203 has established a communication connection (e.g., 251A of FIG. 4B), it will convey that it does have convergence data. In accordance with various embodiments, when the convergence data sharing system of vehicle 203 receives a message from convergence data sharing system 100 indicating that it does not have convergence data, it will automatically access its data storage device and retrieve the latest convergence data. The convergence data sharing system of vehicle 203 will then automatically convey the convergence data to convergence data sharing system 100. It is again noted that this convergence data is time-tagged so that once the convergence data is no longer valid (e.g., 5 minutes after it has been generated), it will not be used to attempt to attain convergence of a non-converged GNSS receiver.”).
It would have been obvious to one of ordinary skill in the art, based on Peake’s teaching, to replace convergence data that is no longer valid with valid convergence data. It would have been obvious for the reasons given regarding claim 14 for Peake’s convergence data to comprise ionosphere coefficients.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Ashley B. Raynal whose telephone number is (703)756-4546. The examiner can normally be reached Monday - Friday, 8 AM - 4 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, Vladimir Magloire can be reached at (571) 270-5144. 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.
/ASHLEY BROWN RAYNAL/Examiner, Art Unit 3648
/OLUMIDE AJIBADE AKONAI/Primary Examiner, Art Unit 3648
Prosecution Insights