DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicant’s arguments, see page 8, filed 10/21/2025, with respect to written description and indefiniteness have been fully considered and are persuasive. The 35 USC 112 rejection of all the claims has been withdrawn.
Applicant’s arguments, see pages 10 to 11, filed 10/21/2025, with respect to the rejection(s) of claims under 35 USC 103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn.
Examiner does not find the claims obvious in view of 4 pieces of prior art. It does not make sense to combine so many pieces of references. However, upon further consideration, a new ground(s) of rejection is made in view of Hu US 2016/0094395.
The claimed invention is essentially a SDN or Controlled Area Network (CAN) for an automobile. This is fairly well known. The claimed in-vehicle control apparatus does not have any details (e.g. only comprising a processor and memory). The claimed apparatus does not have to be a part of a vehicle, and could be remote to a vehicle.
The claimed controlled scenario and control contents do not have any substance. These could be interpreted as policies and rules of s SDN. Also, the claim does not define any vehicle states, what the states are, or if there is more than one state.
Response to Amendment
Claim Rejections - 35 USC § 103
Claims 1, 3-9, 11-12, 14, 16-17, 19-24 are pending and rejected.
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
Claims 1, 3-9, 11-12, 14, 16-17, 19-21 are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over Hu US 2016/0094395 in view of Litichever, WO 2019/123447.
For claim 1, an in-vehicle control apparatus comprising: a processor; and a memory storing instructions executable by the processor to: (See Hu, Fig. 12)
store a prepared control scenario having control contents associated with states of a vehicle for each of a plurality of repeaters included in an in-vehicle network assembled in the vehicle, (Hu, Fig. 8, step 810-820, presumably these policy and rules are stored on a computer)
wherein the prepared control scenario is designed by a network designer (Hu, Fig. 5, Element 510 ) to control communication in the in-vehicle network in the prepared control scenario previously evaluated (Hu, Fig. 12, Element 1218, paragraph 92 teaches CAN or controlled area network. This is a well-known standard for in-vehicle networks) with respect to communication bandwidth and delay of the in-vehicle network; (Hu, PP63 teaches policy controlling resources – that includes bandwidth and delay) and
when a current state of the vehicle has changed (Hu, Fig. 8, Step 830, PP74), control bandwidth limitation and priority levels of the plurality of repeaters, based on a control content, among the control contents (Hu, PP 74, a policy rule of set of policy rules correspond to a control content amount the control contents), associated with the changed current state of the vehicle in the prepared control scenario. (Hu, Fig. 8, Step 840, PP74).
Hu does not explicitly recite each of a plurality of repeaters included in an in-vehicle network assembled in the vehicle.
However, in the analogous art of SDN, Litichever teaches each of a plurality of repeaters included in an in-vehicle network assembled in the vehicle. (See Fig. 10, ECUs, page 61 teaches bridge, page 88 teaches CAN, page 110 teaches ECUs.
It would have been obvious for one of ordinary skill in the art before the effective filing date of the current application to combine the teachings of Hu and Litichever. Both refereces teach SDN and CAN. It would be obvious to implement improvements in SDN policy and rules in vehicles, as shown in Litichever, Fig. 10a, and Fig. 12. The claims do not recite any specificity for vehicles that prevents such implementation.
PNG
media_image1.png
624
844
media_image1.png
Greyscale
For Claims 3, 14 and 19, Hu and Litichever teach the in-vehicle control apparatus according to claim 1. Litichever, Fig. 6 further teaches to display a status of the in-vehicle network on a screen. (Litichever, page 111, The vehicle 21 may include … a dashboard display 26, (also known as instrument panel (IP), or fascia) that is a control panel located directly ahead, or in plain view, of a vehicle's driver or passenger, displaying instrumentation, infotainment, and controls for the vehicle's operation.)
For Claims 4, 16 and 20, Hu and Litichever teach the in-vehicle control apparatus according to claim 1. monitor presence or absence of a query regarding a setting of one or more of the control contents from one or more of the repeaters included in the in-vehicle network (the claimed query is interpreted as a policy input, see PP 24 and PP32 – receive policy input).
For claims 5, 17 and 21, Hu and Litichever teach the in-vehicle control apparatus according to claim 1. Hu further teaches control of the plurality of repeaters includes at least one of (Examiner chooses to address only one of the following) path control, bandwidth control, priority level control for packet forwarding, and control for rewriting packet information. (Hu, paragraph 18).
For claim 6, an in-vehicle network design apparatus comprising: a processor; and a memory storing instructions executable by the processor to: (See Hu, Fig. 12)
generate a control scenario having control contents (this limitation is interpreted as generate a SDN policy with rules, Hu, PP19 and Fig. 7, step 740; PP72) associated with states of a vehicle for each of a plurality of repeaters included in an in-vehicle network assembled in the vehicle, (Hu, Fig. 12, Element 1218, paragraph 92 teaches CAN or controlled area network. This is a well-known standard for in-vehicle networks)
wherein the control scenario is evaluated with respect to communication bandwidth and delay of the in-vehicle network; (Hu, PP63 teaches policy controlling resources – that includes bandwidth and delay)
and send the control scenario to an in-vehicle control apparatus that, (Hu, Fig. 8, step 810-820, presumably these policy and rules are stored on a computer)
when a current state of the vehicle has changed, controls bandwidth limitation and priority levels of the plurality of repeaters based on a control content, among the control contents (Hu, PP 74, a policy rule of set of policy rules correspond to a control content amount the control contents), associated with the changed current state of the vehicle in the control scenario. (Hu, Fig. 8, Step 840, PP74).
Hu does not explicitly recite each of a plurality of repeaters included in an in-vehicle network assembled in the vehicle.
However, in the analogous art of SDN, Litichever teaches each of a plurality of repeaters included in an in-vehicle network assembled in the vehicle. (See Fig. 10, ECUs, page 61 teaches bridge, page 88 teaches CAN, page 110 teaches ECUs.
It would have been obvious for one of ordinary skill in the art before the effective filing date of the current application to combine the teachings of Hu and Litichever. Both refereces teach SDN and CAN. It would be obvious to implement improvements in SDN policy and rules in vehicles, as shown in Litichever, Fig. 10a, and Fig. 12. The claims do not recite any specificity for vehicles that prevents such implementation.
For claim 7, Hu and Litichever teach the in-vehicle network design apparatus according to claim 6. Hu teaches the control scenario is generated by using a virtual network that simulates the in-vehicle network. (Hu, Fig. 8, NFV, network function virtualization)
For claim 8, Hu and Litichever teach the in-vehicle network design apparatus according to claim 7. Hu teaches generation of the control scenario includes evaluation of communication characteristics of the in-vehicle network by using the virtual network (Hu, Fig. 7, step 730, receive network data).
For claim 9, Hu teaches a communication method for an in-vehicle control apparatus for a vehicle in which a vehicle network including a plurality of repeaters assembled in the vehicle, the communication method comprising:
referring, by a processor, to a control scenario having control contents associated with states of the vehicle for each of the plurality of repeaters, (Hu, Fig. 8, step 810-820, presumably these policy and rules are stored on a computer)
wherein the control scenario is designed by a network designer (Hu, Fig. 5, Element 510) to keep control communication in the in-vehicle network in the control scenario previously evaluated (Hu, Fig. 12, Element 1218, paragraph 92 teaches CAN or controlled area network. This is a well-known standard for in-vehicle networks) with respect to safety for communication bandwidth and delay of the in-vehicle network (Hu, PP63 teaches policy controlling resources – that includes bandwidth and delay); and
controlling, by the processor when a current state of the vehicle has changed, (Hu, Fig. 8, Step 830, PP74) bandwidth limitation and priority levels of the plurality of repeaters based on a control content, among the control contents, (Hu, PP 74, a policy rule of set of policy rules correspond to a control content amount the control contents)
associated with the changed current state of the vehicle in the control scenario. (Hu, Fig. 8, Step 840, PP74).
Hu does not explicitly recite each of a plurality of repeaters included in an in-vehicle network assembled in the vehicle.
However, in the analogous art of SDN, Litichever teaches each of a plurality of repeaters included in an in-vehicle network assembled in the vehicle. (See Fig. 10, ECUs, page 61 teaches bridge, page 88 teaches CAN, page 110 teaches ECUs.
It would have been obvious for one of ordinary skill in the art before the effective filing date of the current application to combine the teachings of Hu and Litichever. Both refereces teach SDN and CAN. It would be obvious to implement improvements in SDN policy and rules in vehicles, as shown in Litichever, Fig. 10a, and Fig. 12. The claims do not recite any specificity for vehicles that prevents such implementation.
For claim 11, Hu and Litichever teach the in-vehicle control apparatus according to claim 1. Hu teaches a non-transitory storage medium in which the prepared control scenario is internally and rewritable stored, wherein the in-vehicle network internally assembled in the vehicle is updatable by changing the prepared control scenario as internally and rewritably stored in the non-transitory storage medium, from outside of the vehicle. (Hu, Fig. 12, Disk Storage 1224)
For claim 12, Hu and Litichever teach the in-vehicle control apparatus according to claim 1. Litichever teaches each state of the vehicle is a matter or an event that occurs due to a vehicle-specific action or operation. (Broadly speaking, the claim is one vehicle state tied to a vehicle action. Because the claim does not require any particular number of states or any specific action. A car could be in a state of either parked, stationary, moving, or idle. These concepts are well known and not require further explanation; Litichever teaches a vehicle state mananger)
Claims 22-24 are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over Hu US 2016/0094395 in view of Litichever, WO 2019/123447.
For claims 22, 23 and 24, Hu and Litichever teach the in-vehicle control apparatus according to claim 1. They do not teach the instructions are executable by the processor to further control the plurality of repeaters to: perform a bandwidth control operation, perform a packet forwarding path control operation and perform a priority level control operation.
However, these operations are well known in the art before the effective filing date of the current application. For example, Ko teaches perform a bandwidth control operation, perform a packet forwarding path control operation and perform a priority level control operation. (Ko, PP72-73)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the current application to combine the teachings of Hu and Ko. Both references teach SDN and OpenFlow. It would be obvious to implement improvements in SDN policy and rules to control packet flow through bandwidth and priority throttling and packet forwarding path. These are well known in congestion control.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Charles C Jiang whose telephone number is (571)270-7191. The examiner can normally be reached Monday to Thursday 7 am to 5 pm Eastern Time.
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, TC Group director, Deborah Reynolds can be reached at (571) 272-0734. 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.
/CHARLES C JIANG/Supervisory Patent Examiner, Art Unit 2412
