NON-FINAL REJECTION
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 .
Claim Objections
Claims 1-14 objected to because of the following informalities:
Independent claim 1 (line 8), claim 10 (line 13), claim 13 (line 7) and claim 14 (line 8), include limitation “for the each shadow” which should be corrected to --for each shadow-- OR --for each of the shadows--, or a similar correction.
Independent claim 1 (line 12), claim 10 (line 8), claim 13 (line 9) and claim 14 (line 11), include limitation “a vehicle” which should be corrected to --the vehicle--.
Dependent claim 10 (line 10) and claim 11 (line 4), include limitation “an in-vehicle device” should be changed to --the in-vehicle device--.
Appropriate correction is required.
All remaining dependent claims objected due to their dependency.
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 1-14 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.
Independent claims 1 (line 9), 10 (line 14), 13 (line 8) and 14 (line 9) include the limitation phrase “access request from an outside” which is not clearly defined. The claim is interpreted under broadest reasonable interpretation, to indicate that a request is received from any outside/external environment to the interface unit.
Remaining dependent claims rejected due to their dependency.
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.
All claims were reviewed for appropriate compliance with 35 U.S.C. 101.
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.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(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.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1, 10, and 13-14 is/are rejected under 35 U.S.C. 102(a)(2) as being anticipated by AZUSA (JP2021019276A - machine translation attached – All figures referenced are based on FOR document supplied by Applicant).
Re claim 1. AZUSA discloses (abstract) a mobility service base server 10/200 (see all Figures – data collection device 10/user terminal 200 – user unit 200 operates in cooperation with device 10) comprising:
a vehicle-side unit 10 including a first database (tag data T which is metadata in which the actual data R is converted into meta information – generated based on program or generation data stored in user terminal 200 – data collection device 10 collects tag data T) storing a plurality of shadows [0017] (the data collected for vehicles can be analyzed due to specific events occurring when certain event conditions are met) each of which represents a state [0020] of a vehicle (vehicles V-1, V-2, V-3) at a specific time (date and time) [0047], each of the plurality of shadows being generated for the vehicle based on vehicle data [0073] provided from an in-vehicle device (in-vehicle device 100) mounted on the vehicle [0011-0013]; and
a service-side unit 200 including a second database (metadata DB 204b) storing an index (tag ID) corresponding to each of the shadows [0046-0049] accumulated in the first database and having information to be used for searching (metadata) for the each shadow [0046, 0073], and an interface unit 201 configured to receive an access request [0046-0048] from an outside (FIG.3),
wherein
the vehicle-side unit further includes a vehicle control unit (a vehicle control unit is implicit given that functions required by the unit 10 requires that control of functions corresponding the vehicle be performed, such as communicating data) configured to execute access to a target vehicle (V-1 etc.), the target vehicle being a vehicle to be accessed, by performing wireless communication with the in-vehicle device mounted on the target vehicle when the interface unit receives the access request for the vehicle (when interface unit receives an access request for a vehicle V-1, the vehicle-side unit executes access to the target vehicle by performing wireless communication with an in-vehicle device 100 mounted on the target vehicle (FIG.1), which is a vehicle to be accessed, and executes a control in response to a control instruction transmitted and received to and from the in-vehicle device (when the data user wants to collect and transmit predetermined actual data R (vehicle data, for example, video data, etc.), the user terminal 200. The tag data T corresponding to the actual data R to be collected is designated. Accordingly, the user terminal 200 outputs a transmission request for predetermined actual data R (vehicle data) to the data collection device 10. Then, the data collection device 10 outputs a transmission instruction (in other words, instruction data specifying the actual data R) of the actual data R in response to the transmission request to the corresponding in-vehicle device 100. Then, as shown in FIG. 1, the specified actual data R is transmitted (uploaded) from each in-vehicle device 100 to the data collection device 10 based on the transmission instruction, and is stored in the data collection device 10. Then, a data user accesses the actual data R stored in the data collection device 10 by the user terminal 200, and transmission processing of the actual data R from the data collection device 10 to the user terminal 200 such as browsing and downloading of the actual data R is performed) [0025] - [0026]), and
the vehicle control unit is configured to execute relay control in response to a control instruction (when the data user wants to collect and transmit predetermined actual data R (vehicle data, for example, video data, etc.) [0051-0052]) transmitted to and received from the in-vehicle device (FIG.1 – i.e. data transmitted and received due to request signals).
Re claim 10. AZUSA discloses (as applied for claim 1 given the overlap of limitations) a mobility service providing system (FIG.1) comprising:
an in-vehicle device mounted on a vehicle; and
a mobility service base server configured to provide a mobility service to the vehicle on which the in-vehicle device is mounted,
wherein
the mobility service base server includes
a vehicle-side unit including a first database storing a plurality of shadows each of which represents a state of a vehicle at a specific time, each of the plurality of shadows being generated for the vehicle based on vehicle data provided from an in-vehicle device mounted on the vehicle, and
a service-side unit including a second database storing an index corresponding to each of the shadows accumulated in the first database and having information to be used for searching for the each shadow, and an interface unit configured to receive an access request from an outside,
the vehicle-side unit further includes a vehicle control unit configured to execute access to a target vehicle, the target vehicle being a vehicle to be accessed, by performing wireless communication with the in-vehicle device mounted on the target vehicle when the interface unit receives the access request for the vehicle, and
the vehicle control unit is configured to execute relay control in response to a control instruction transmitted to and received from the in-vehicle device.
Re claim 13. AZUSA discloses (as applied for claim 1 given the overlap of functional limitations) a vehicle access control method in a mobility service base server including a first database storing a plurality of shadows each of which represents a state of a vehicle at a specific time, each of the plurality of shadows being generated for the vehicle based on vehicle data provided from an in-vehicle device mounted on the vehicle, a second database storing an index corresponding to each of the shadows accumulated in the first database and having information to be used for searching for the each shadow, and an interface unit configured to receive an access request from an outside, the vehicle access control method comprising:
executing access to a target vehicle, the target vehicle being a vehicle to be accessed, by performing wireless communication with the in-vehicle device mounted on the target vehicle when the interface unit receives the access request for the vehicle; and
executing relay control in response to a control instruction transmitted to and received from the in-vehicle device in access to the target vehicle.
Re claim 14. AZUSA discloses (as applied for claim 1 given the overlap of limitations) a non-transitory computer-readable storage medium (i.e. implicitly all units as claimed require at least one type of medium or memory elements [0013, 0022, 0040, 0044, 0064] for proper operation) storing a program causing a computer to function as a vehicle control unit, the computer including mobility service base server together with a first database storing a plurality of shadows each of which represents a state of a vehicle at a specific time, each of the plurality of shadows being generated for the vehicle based on vehicle data provided from an in-vehicle device mounted on the vehicle, a second database storing an index corresponding to each of the shadows accumulated in the first database and having information to be used for searching for the each shadow, and an interface unit configured to receive an access request from an outside,
the vehicle control unit being configured to execute access to a target vehicle, the target vehicle being a vehicle to be accessed, by performing wireless communication with the in-vehicle device mounted on the target vehicle when the interface unit receives the access request for the vehicle and execute relay control in response to a control instruction transmitted to and received from the in-vehicle device in access to the target vehicle.
Claim(s) 1, 10, and 13-14 is/are rejected under 35 U.S.C. 102(a)(2) as being anticipated by SOTARO (JP 2020-190893A - machine translation submitted).
Re claim 1. SOTARO discloses (abstract) a mobility service base server 10 [0012] comprising:
a vehicle-side unit including a first database (metadata) storing a plurality of shadows each of which represents a state (data on vehicle condition, environment, etc.) [0013, 0017] of a vehicle at a specific time (a plurality of timings), each of the plurality of shadows being generated for the vehicle based on vehicle data provided from an in-vehicle device 20 mounted on the vehicle; and
a service-side unit including a second database (DB 13) storing an index corresponding [0042] to each of the shadows accumulated in the first database and having information to be used for searching for the each shadow (format that allows vehicle ID, sensor values and event information included in the metadata to be searched), and an interface unit (data request receiving unit 121 from data collection unit 12) configured to receive an access request from an outside [0038],
wherein
the vehicle-side unit further includes a vehicle control unit (i.e. including communication possibility estimation unit 122 cooperating with request generating unit 123 and request sending unit 124 to performs operations – for vehicle that matches due to sorting, the conditions specified in data request from data utilization server 30, the vehicle is specified based on the metadata group stored in vehicle search database DB 13, a vehicle to be the transmission destination of the actual data transmission request is selected based on the communication possibility estimated by the communication possibility estimation unit 122, and a request (the actual data transmission request started by server 30) to the in-vehicle device 20 of the vehicle is generated) configured to execute access to a target vehicle [0038], the target vehicle being a vehicle to be accessed [0038], by performing wireless communication (FIG.1-2) with the in-vehicle device mounted on the target vehicle when the interface unit receives the access request for the vehicle [0038], and
the vehicle control unit is configured to execute relay control (i.e. data transmitted and received due to request signals) in response to a control instruction transmitted to and received from the in-vehicle device (request transmission unit 124 sends request generated by the request generation unit 123, to selected vehicle – wherein a data response is received by actual data receiving unit 125 after the request is transmitted) [0038].
Re claim 10. AZUSA discloses (as applied for claim 1 given the overlap of limitations) a mobility service providing system (FIG.1) comprising: an in-vehicle device mounted on a vehicle; and a mobility service base server configured to provide a mobility service to the vehicle on which the in-vehicle device is mounted, wherein the mobility service base server includes a vehicle-side unit including a first database storing a plurality of shadows each of which represents a state of a vehicle at a specific time, each of the plurality of shadows being generated for the vehicle based on vehicle data provided from an in-vehicle device mounted on the vehicle, and a service-side unit including a second database storing an index corresponding to each of the shadows accumulated in the first database and having information to be used for searching for the each shadow, and an interface unit configured to receive an access request from an outside, the vehicle-side unit further includes a vehicle control unit configured to execute access to a target vehicle, the target vehicle being a vehicle to be accessed, by performing wireless communication with the in-vehicle device mounted on the target vehicle when the interface unit receives the access request for the vehicle, and the vehicle control unit is configured to execute relay control in response to a control instruction transmitted to and received from the in-vehicle device.
Re claim 13. SOTARO discloses (as applied for claim 1 given the overlap of functional limitations) a vehicle access control method in a mobility service base server including a first database storing a plurality of shadows each of which represents a state of a vehicle at a specific time, each of the plurality of shadows being generated for the vehicle based on vehicle data provided from an in-vehicle device mounted on the vehicle, a second database storing an index corresponding to each of the shadows accumulated in the first database and having information to be used for searching for the each shadow, and an interface unit configured to receive an access request from an outside, the vehicle access control method comprising: executing access to a target vehicle, the target vehicle being a vehicle to be accessed, by performing wireless communication with the in-vehicle device mounted on the target vehicle when the interface unit receives the access request for the vehicle; and executing relay control in response to a control instruction transmitted to and received from the in-vehicle device in access to the target vehicle.
Re claim 14. SOTARO discloses (as applied for claim 1 given the overlap of limitations) a non-transitory computer-readable storage medium storing a program (i.e. implicitly all units as claimed require at least one type of medium or memory elements) causing a computer to function as a vehicle control unit, the computer including mobility service base server together with a first database storing a plurality of shadows each of which represents a state of a vehicle at a specific time, each of the plurality of shadows being generated for the vehicle based on vehicle data provided from an in-vehicle device mounted on the vehicle, a second database storing an index corresponding to each of the shadows accumulated in the first database and having information to be used for searching for the each shadow, and an interface unit configured to receive an access request from an outside, the vehicle control unit being configured to execute access to a target vehicle, the target vehicle being a vehicle to be accessed, by performing wireless communication with the in-vehicle device mounted on the target vehicle when the interface unit receives the access request for the vehicle and execute relay control in response to a control instruction transmitted to and received from the in-vehicle device in access to the target vehicle.
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(s) 2-4 is/are rejected under 35 U.S.C. 103 as being unpatentable over SOTARO (JP 2020-190893A).
Re claim 2. SOTARO discloses the mobility service base server according to claim 1, wherein the vehicle control unit includes
a control history memory unit (a unit keeps track of success of communications – DB14) storing content and a control status of the control instruction to be transmitted to the vehicle, [0081-0082]
a history registration unit (a unit (i.e. communication possibility model) can determine when a communication function is successful, as set to OK and recorded as such, or when a communication is a failure, set as NG) configured to set the control status to an acceptance state and registers the control instruction in the control history memory unit, [0081-0082]
a delivery confirmation unit (implicitly successful communication or a failure is determined by at least one module unit) configured to monitor the control status after transmission of the control instruction to check delivery of the control instruction, and
a history update unit (at least one unit would updatesfor communication possibility model) configured to update the control status of the control instruction in the control history memory unit to a completion state when receiving a response from the in-vehicle device to the control instruction. [0081-0083]
Arguably, SOTARO discloses (FIG.9) the various units as claimed in claim 2, performing the various functions.
However, even if SOTARO may not explicitly show these distinct units as claimed, the following is applied.
SOTARO at a minimum suggests to a person having ordinary skill in the art the concept of performing various distinct functions, which could be operated by a single or multiple modules such as shown in FIG.9.
It would have been obvious to one having ordinary skill in the art at the time the invention was made to separate each function to be performed by an individual unit (i.e. a memory module for storing history data, a registering module for recording status data, a module determining transmission delivery of communication, a module for processing updates for the history data), since it has been held that constructing a formerly integral structure in various elements involves only routine skill in the art. Nerwin v. Erlichman, 168 USPQ 177, 179. (PTO Bd. of Int. 1969).
Re claim 3. SOTARO discloses [0098] the mobility service base server according to claim 2, wherein the vehicle control unit further includes an invalidation unit (implicit a unit must operate to invalidate instruction signals given communication failure) configured to invalidate the control instruction when delivery of the control instruction is not confirmed within a preset allowable time by the delivery confirmation unit (if the transmission of the actual data fails, a retry time or a timeout time occurs).
Re claim 4. SOTARO discloses [0017, 0082-0083] the mobility service base server according to claim 2, wherein the vehicle control unit further includes a pre-transmission determination unit configured to transmit the control instruction to the in-vehicle device within an allowable time designated by the control instruction before transmitting the control instruction to the in-vehicle device, and determine whether execution by the in-vehicle device is capable of being completed, and when the pre-transmission determination unit makes a negative determination, the history update unit stops transmitting the control instruction to the in-vehicle device and updates the control status of the control instruction in the control history memory unit to a state indicating that the transmission has failed.
Claim(s) 5-7 is/are rejected under 35 U.S.C. 103 as being unpatentable over AZUSA (JP2021019276A) in view of KATOU et al. (US 20150057840 A1).
Re claim 5. However, AZUSA fails to explicitly disclose:
the mobility service base server according to claim 1, wherein the control instruction has a priority, and the vehicle control unit includes a priority processing unit configured to set a transmission order of the control instruction according to the priority.
KATOU teaches (abstract) in a similar field of invention (FIG.1) a vehicle-mounted control system 10 including a mobility service base server 20, wherein control instructions (i.e. requests) have a priority [0052] determined (FIG.2) when a user request signal is received and could conflict with another control function, and to determine which if user request is higher priority for the purpose of determining which request to execute based on which has highest priority level (FIG.2 – see steps S1-S8).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to try using a unit to determine a priority as taught by KATOU in order to process user requests which have higher priority and therefore prevent interference between controls functions.
Re claim 6. However, AZUSA fails to explicitly disclose:
the mobility service base server according to claim 5, wherein the priority is set by the interface unit for each access request.
KATOU further teaches [0052] the priority level is set by an interface unit (FIG.1 i.e. center apparatus sends center request signal – which serves as a server) for each access request (FIG.2-3) so as to determine priority level for proper processing.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to determining a priority as taught by KATOU in order to process control functions/requests in a proper order of priority.
Re claim 7. However, AZUSA fails to explicitly disclose:
the mobility service base server according to claim 5, wherein the priority is determined according to control content indicated in the access request.
KATOU further teaches [0052] the priority level is determined according to control content (i.e. from signals processing during steps S2-S6) indicated in a corresponding access request.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to determining a priority as taught by KATOU in order to process control functions/requests in a proper order of priority.
Claim(s) 8-9 and 12 is/are rejected under 35 U.S.C. 103 as being unpatentable over AZUSA (JP2021019276A) in view of CAHILL et al. (US 20060052159 A1).
However, AZUSA fails to explicitly disclose:
Re claim 8.
the mobility service base server according to claim 1, wherein the vehicle control unit includes an order control unit configured to assign a serial number representing an execution order of control to a series of control instructions that require order control.
Re claim 9.
the mobility service base server according to claim 8, wherein the order control unit is configured to, when the access request includes a plurality of controls that require order control, generate a plurality of the control instructions from the access request and assign the serial number to each of the control instructions.
Re claim 12.
the mobility service providing system according to claim 10, wherein the vehicle control unit includes an order control unit configured to assign a serial number representing an execution order of control to a series of control instructions that require order control, and the in-vehicle device is configured to execute the control instruction received from the mobility service base server in order of the serial numbers assigned to the control instruction.
The prior art of CAHILL also teaches the known technique of assigning serial numbers for control signals [0144] (i.e. command and control data message) for the purpose of distinguishing between different control signals, which would implicitly require at least one order control unit to assign serial numbers. A person of ordinary skill in the art would have recognized that applying the known technique of using serial numbers would have yielded predictable results and would have improved the performance of the vehicle control unit.
Claim(s) 11 is/are rejected under 35 U.S.C. 103 as being unpatentable over AZUSA (JP2021019276A) in view of PECK et al. (US 5748843 A).
Re claim 11. AZUSA discloses [0013, 0088] the mobility service providing system according to claim 10, wherein the vehicle control unit is configured to transmit, as the control instruction, a specific control instruction (implicitly, a controlling unit from data collection device 10 transmits a specific control instruction defining the request for data collection, received and performed by in-vehicle device 100) that defines a series of instructions for a target device that is an in-vehicle device to be controlled mounted on the target vehicle (in-vehicle device 100 acquires a collection instruction from the data collection device 10 in response to the collection request received by the data collection device 10).
However, AZUSA fails to explicitly disclose:
the series of instructions including a control timing of each instruction, and the in-vehicle device is configured to sequentially output individual instructions included in the series of instructions indicated by the specific control instruction to the target device one by one according to the control timing when the specific control instruction is received.
PECK teaches (abstract) in a similar field of invention, a sequence or set of instructions including order and timing of a series of control signals for processing data.
A person of ordinary skill in the art would have had good reason to pursue the known options of using a control timing included with a series of instructions for each instruction so that the proper order of data collection operations is performed. It would require no more than "ordinary skill and common sense," to attempt to use a control timing for each instruction and sequentially output individual instructions as needed throughout the operation of data collection across various different vehicles.
Conclusion
The prior art made of record in PTO-892 Form and not relied upon is considered pertinent to applicant’s disclosure.
For example, CUI et al. (US 20210400242 A1) teaches in a similar field of invention, monitoring of an event (abstract) occurring within an environment (FIG.1), detecting such event by using local detection units communicating with a cloud server and database.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CARLOS E GARCIA whose telephone number is (571)270-1354. The examiner can normally be reached M-Th 9-6pm F 9-5pm.
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, Brian Zimmerman can be reached at (571) 272-3059. 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.
CARLOS E. GARCIA
Primary Examiner
Art Unit 2686
/Carlos Garcia/Primary Examiner, Art Unit 2686 11/18/2025