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 Amendment
This Final Office action is responsive to the communication filed under 37 C.F.R. § 1.111 on February 27, 2025 (hereafter “Response”). The amendments to the claims are acknowledged and have been entered.
Claims 1, 8, and 15 are now amended.
Claims 4, 11, and 18 are now canceled.
New claims 21–22 are now added.
Claims 1–3, 5–10, and 12–22 are pending in the application.
Response to Arguments
Applicant’s arguments with respect to claim(s) 1–22 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Claim Rejections – 35 U.S.C. § 102
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.
Claims 1, 2, 5–9, 12–16, 19, and 20 are rejected under 35 U.S.C. § 102(a)(1) as being anticipated by U.S. Patent Application Publication No. 2021/0122398 A1 (“Kim”).
Claim 1
Kim discloses:
A method, implemented by programmed one or more processors in a client terminal, for setting an operational rule of a vehicle, the method comprising:
Reference is made to FIG. 3, which illustrates a method implemented in the programming of a controller 1200 (the claimed “processor”). See Kim ¶ 154 and FIG. 3. The controller 1200 is an element of vehicle 1000 (the claimed “client terminal”) shown in FIG. 2.
outputting a user interface for setting an operational rule
“Upon determination of a need to change the autonomous driving level or change the driving route based on the driving distribution and the driver information, the controller 1200 may provide guidance on a possible driving change option through the user interface 1300.” Kim ¶ 245.
for controlling one or more components of a vehicle, wherein the one or more components includes an autonomous driving control of the vehicle;
“In this case, the driving change option may include an option to change the autonomous driving level without changing the driving route, an option to change to remote driving without changing the driving route, and an option to change the driving route without changing the autonomous level.” Kim ¶ 245. “When the vehicle 1000 is operated in the autonomous driving mode, the vehicle 1000 may be operated under the control of the operator 1700 that controls driving, parking, and unparking.” Kim ¶ 68.
receiving, via a user input to the user interface, a setting of the operational rule,
“The user interface 1300 may receive an input signal of the user,” Kim ¶ 255, including a user input selecting one of the aforementioned options. See Kim ¶¶ 246–249.
wherein the operational rule assists in avoiding unsafe driving;
Each of the three options are meant to mitigate risk under the current conditions. For example, “the driving control module 1280, may control the operator 1700 to move the ego vehicle to the safety zone when the driver selects the option to change the driving route.” Kim ¶ 253.
As another example, “controller 1200 may advise the driver to select the option to change the driving route without changing the autonomous driving level in order to reduce the fatigue of the driver” when the difference between the ego vehicle’s automation level and the other vehicles’ automation levels is greater than a threshold. Kim ¶ 251.
As yet another example, when the circumstances of the current route necessitate that the vehicle 1000 will need to switch to a lower level of automation, but “ the driver proficiency in the current driving distribution is less than a predetermined value or the driver does not have a driver’s license,” then in response, “the controller 1200 may respectively activate only the option to change the driving route without changing the autonomous driving level or the option to change to the remote driving without changing the driving route, among the driving change options.” Kim ¶ 250.
and transmitting the received setting to a server to implement the operational rule on the fly via an over-the-air transmission to the vehicle.
“The transceiver 1100 may transmit specific information over a 5G network when the vehicle 1000 is operated in the autonomous driving mode.” Kim ¶ 85. “The 5G network may include a server or a module for performing remote control related to autonomous driving,” Kim ¶ 90, and “the specific information may include information about the destination and the safety level of the vehicle, which are inputted through the user interface 1300.” Kim ¶ 88.
Likewise, “controller 1200 may receive a control signal of the server 3000 through the transceiver 1100, and control the autonomous driving mode operation according to the control signal.” Kim ¶ 153.
Claim 2
Kim discloses the method according to claim 1,
wherein the outputting of the user interface comprises outputting the user interface based on a successful authentication of the user.
“The controller 1200 may verify the autonomous driving level of the ego vehicle . . . based on driver information, and change the autonomous driving level of the ego vehicle according to the verification result. In this case, the driver information may be the driving proficiency information or driver’s license information.” Kim ¶ 238. “For example, when the autonomous driving level of the ego vehicle determined based on the autonomous driving level information of the overlap vehicle is level 1 and the driver holds a license exclusively for an autonomous vehicle, the controller 1200 may change the appropriate autonomous driving level to level 3.” Kim ¶ 239.
Claim 5
Kim discloses the method according to claim 1,
wherein the operational rule comprises a condition
The availability of each of the three options is based on a respective condition (or conditions) being met: the options to change the autonomous driving level without changing the driving route, or to request remote driving, are conditioned upon the driver’s proficiency and/or license, see Kim ¶¶ 238 and 250, and the option to change the driving route without changing the autonomous driving level is conditioned upon the “driving distribution” calculated according to Equation 1. Kim ¶ 251.
Additionally, all three options may be condition “[u]pon determination of a need to change the autonomous driving level,” Kim ¶ 245, as determined by an “appropriate autonomous driving level inference module 1250. See Kim ¶ 165.
and a control to be performed based on the condition.
All three options change the manner in which the vehicle is controlled:
When the driver selects the option to change the autonomous driving level without changing the driving route, the new driving level controls different autonomous systems of the vehicle as compared to the previous driving level. See Kim ¶¶ 55–61.
When the driver selects the option to change to the remote driving without changing the driving route, the vehicle is controlled by remotely transmitted signals, rather than with the components of the vehicle. See Kim ¶¶ 90–92.
And finally, when the driver selects the option to change the driving route without changing the autonomous level, then, at least in cases where the vehicle is at level 3 or above, the vehicle will be controlled to follow the new route, rather than the old route. See Kim ¶¶ 59–61.
Claim 6
Kim discloses the method according to claim 5,
wherein the condition comprises at least one of a number of passengers, a location, a distance traveled, a time of travel, a time, a drowsiness detection, and a careless driving detection.
Kim discloses at least the “location” alternative, thus disclosing “at least one of” the alternatives recited in claim 6. Specifically, Kim discloses that all three options may be condition “[u]pon determination of a need to change the autonomous driving level,” Kim ¶ 245, as determined by an “appropriate autonomous driving level inference module 1250. “The controller 1200, for example, the appropriate autonomous driving level inference module 1250, may determine the autonomous driving level of the vehicle 1000, which is the ego vehicle, based on the autonomous driving information of the overlap vehicle,” Kim ¶ 165, and the overlap vehicle is chosen based on any number of location-based criteria. For example, controller 1200 may “select, as the overlap vehicle, a vehicle among the plurality of other vehicles that is driving in the same lane as a driving lane of the ego vehicle or driving in a similar driving area to the ego vehicle.” Kim ¶ 159. Additionally, “controller 1200 may re-select and update the overlap vehicle in real-time as the vehicle 1000 moves. For example, the controller 1200 may select five overlap vehicles while the vehicle 1000 is driving on the Yangjae Boulevard and select one overlap vehicle as the vehicle 1000 enters the Olympic Boulevard.” Kim ¶ 162.
Claim 7
Kim discloses the method according to claim 5, further comprising
receiving, from the server, a notification of the condition being met.
Referring to FIG. 5, “[t]he 5G network may determine whether the vehicle 1000 is to be remotely controlled based on the specific information transmitted from the vehicle 1000 (vehicle remote control determination step, S24),” and in response, “[t]he autonomous vehicle 1000 may receive the DL grant through a physical [downlink (“DL”)] control channel for receiving a response on pre-transmitted specific information from the 5G network (DL grant receiving step, S25).” Kim ¶ 101. “The 5G network may transmit information (or a signal) related to the remote control to the autonomous vehicle 1000 based on the DL grant (remote control related information transmission step, S26).” Kim ¶ 102.
Claims 8, 9, and 12–14
Claims 8, 9, and 12–14 recite an apparatus comprising general-purpose computing components that have been programmed to perform exactly the same method as claims 1, 2, and 5–7. Since Kim’s vehicle 1000 and controller 1200 were used to reject claims 1, 2, and 5–7, the findings and rationale provided above in those rejections are hereby applied to claims 8, 9, and 12–14.
Claims 15, 16, 19, and 20
Claims 15, 16, 19, and 20 recite almost exactly the same memory and its stored computer-executable instructions recited as an element of claims 8, 9, 12, and 13. Therefore, claims 15–16 and 19–20 are rejected over the same findings and rationale as provided above for claims 8–9 and 12–13.
Claim Rejections – 35 U.S.C. § 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.
I. Kim and Penilla teach claims 3, 10, and 17.
Claim(s) 3, 10, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Kim as applied to claims 2, 9, and 16 above, and further in view of U.S. Patent Application Publication No. 2019/0196851 A1 (“Penilla”).
Claim 3
Kim teaches the method of claim 2, but does not explicitly disclose the details of successful authentication as required by claim 3.
Penilla, however, teaches a method in which a user interface for a vehicle is output based on a successful authentication, and further teaches:
the successful authentication of the user is verified based on one of a login procedure and/or biometric authentication.
“The access to the vehicle site may be granted by supplying credentials for accessing a user account, or establishing a new user account.” Penilla ¶ 176.
“The credentials can include usernames and passwords, keys, alphanumeric entries, biometric inputs, voice inputs, retina scan inputs, fingerprints, face recognition, etc.” Penilla ¶ 144.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to use Kim’s internal cameras to authenticate or verify the identity of the user, so that an appropriate profile may be loaded, as taught by Penilla. One would have been motivated to improve Kim with Penilla because Penilla’s technique makes the overall system more secure and reliable.
Claims 10 and 17
The additional elements of claims 10 and 17 are substantially similar to those in claim 3, and therefore rejected over the same findings and rationale (taken in conjunction with the additional findings provided in the § 102 rejection of their parent claims).
II. Xu, Chaves, and Aust teach claims 21 and 22.
Claim(s) 21 and 22 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Application Publication No. 2022/0032936 A1 (“Xu”) in view of U.S. Patent Application Publication No. 2022/0355802 A1 (“Chaves”) and U.S. Patent Application Publication No. 2020/0125355 A1 (“Aust”).
Claim 21
Xu teaches:
A system comprising:
“FIG. 1 illustrates an example of a distributed control system 1 for configuring and implementing rules relating to a vehicle 2 comprising a plurality of vehicle systems (exemplified by the engine 4) that may be controlled by a user of the vehicle.” Xu ¶ 54.
a user terminal;
“The system 1 may also comprise one or more non-vehicle systems (exemplified by the device 6), which may take the form of, for example, the user’s mobile device.” Xu ¶ 54.
a server;
The broadest reasonable interpretation of “a server” in the context of the Applicant’s specification includes “one or more devices” that “may be constituted by a plurality of servers, a portion of which may be deployed in different locations.” (Spec. ¶ 33).
Consistent with the broadest reasonable interpretation, the “server” of Xu’s system 1 is constituted by “at least one controller 8 located within the vehicle 2 (thereby providing ‘on-board’ control functionality), and at least one server 10 located remote from the vehicle 2 (thereby providing ‘off-board’ control functionality).” Xu ¶ 54.
and a vehicle, wherein:
As mentioned in the discussion above, Xu’s system 1 further includes a “vehicle 2.” See Xu ¶ 54 and FIG. 2.
the server is configured to send a notification to the user terminal in response to a vehicle speed of the vehicle exceeding a speed limit or in response to the vehicle leaving a designated location,
“As an example, a rule may be configured to specify that on a weekday, if the vehicle leaves a specific location (i.e. the work car park) within a particular time range, this should trigger the mobile device linked to the vehicle system to send a text message/notification to a particular recipient and having a specific content” by causing “the controller 8 [to] generate and send a control signal 13 to the user’s mobile device 6 (either via a dedicated application, or through an in-car connection).” Xu ¶ 73.
To be clear, in this rejection, the claimed “notification” is mapped to Xu’s transmission of control signal 13 to mobile device 6, rather than the subsequent forwarding of the message contained within control signal 13 by mobile device 6.
the user terminal is configured to receive an input from a user of the user terminal,
The mobile device is configured to receive “input of data by the user to a dedicated application on their mobile device.” Xu ¶ 62. This “input of data” is not necessarily responsive to the control signal 13, but there is no language in claim 21 that requires the claimed input to be responsive to the claimed notification. The claim does not even specify the timing of the input, e.g., before or after the notification is sent.
the input indicating a setting which is an operational rule corresponding to implementation of a
“[T]his data input is forwarded in the form of a rule configuration signal 11 to the server 10,” Xu ¶ 62, or alternatively, the mobile device 6 can also send the rule configuration signal 11 directly to the controller 8. Xu ¶ 76. Either way, the rule configuration signal 11 comprises “one or more action indicators 20 that are to be carried out when the rule is implemented, as well as one or more associated conditions (i.e. triggers 22 or events) that will be monitored and assessed to determine when the rule is to be implemented and the action is to be taken.” Xu ¶ 63.
One relevant example of a rule action includes “actions that require changing vehicle properties[,] such as the vehicle drive mode,” Xu ¶ 68, which, while not necessarily falling within the narrower species of a “limp” mode, at least teaches a rule that sets a physical mode of operation for the vehicle.
wherein the input from the user is received via a mobile phone application or a browser web page,
“[T]he user may interact with the controller 8 or server 10 . . . via an application on their mobile device 6 that is linked to the controller 8 or server 10.” Xu ¶ 75.
and the user is able to implement the operational rule in real-time,
Interacting with the application on the mobile device 6 enables the user to “activate or deactivate specific previously-defined actions according to their personal preference and changing requirements.” Xu ¶ 75.
the server is further configured to: i) verify that the setting is valid,
“Once the rule configuration signal 11 is received by the server 10, it carries out checks in step 110 to ensure that the newly-configured rule is not a replica of an existing rule that was previously stored by the server 10, and also that the newly-configured rule does not conflict with any existing stored rules.” Xu ¶ 64.
“The server 10 will also generate in step 130 a rule configuration signal 11 comprising the rule and the associated flag, and will transmit in step 135 the rule configuration signal 11 to the on-board controller 8.” Xu ¶ 70.
and the vehicle is configured to: i) receive the setting,
“The control signals 13 are then output in step 330 to the appropriate systems (which may be either vehicle systems 4 or non-vehicle systems 6, or a combination of the two) to cause those system to take the necessary actions.” Xu ¶ 72.
thereby assisting in avoiding unsafe driving.
“It is advantageous to be able to automatically control various different vehicle systems using such a control system as it may decrease the likelihood of distraction of the vehicle occupant.” Xu ¶ 11.
Xu does not appear to explicitly disclose that its “vehicle drive mode” includes the claimed “limp mode.”
Chaves, however, teaches:
A system comprising: a user terminal; a server; and a vehicle, wherein:
“FIG. 1 shows a pictorial diagram of an example environment 100 within which various aspects of the subject matter disclosed herein may be implemented. The environment 100 is shown to include (but is not limited to) a driving behavior detection system 110, a vehicle 120, . . . [and] one or more third party entities 170.” Chaves ¶ 68.
To be clear, the claimed system, user terminal, server, and vehicle correspond to Chaves’s environment 100, third party entities 170, the driving behavior detection system 110, and the vehicle 120, respectively. Please note that the driving behavior detection system 110 is also labeled as “400” in FIG. 4.
the server is configured to send a notification to the user terminal
“In response to the determination of unsatisfactory driving, the detection system 110 may generate an indication of unsatisfactory driving behavior of the vehicle 120. The indications may be provided to one or more of the entities 170.” Chaves ¶ 70.
in response to a vehicle speed of the vehicle exceeding a speed limit
The determination of unsatisfactory driving may include a determination that the vehicle 120 exceeded the speed limit. See Chaves ¶¶ 119 and 128.
or in response to the vehicle leaving a designated location,
The determination of unsatisfactory driving may also include a determination that the vehicle 120 left a permitted lane of travel. See Chaves ¶¶ 121 and
the user terminal is configured to receive an input from a user of the user terminal, the input indicating a setting which is an operational rule corresponding to implementation of a limp mode,
“In one implementation, an entity associated with a human driver of a vehicle having an unsatisfactory driving score may participate in selecting the limits and restrictions placed on the vehicle (or its human driver). For example, if a teenager is determined to exhibit unsatisfactory driving behavior, the detection system 400 may notify the teenager’s parents of the unsatisfactory driving behavior and solicit suggestions regarding which operations or features of the vehicle should be disabled, which operations or features of the vehicle should be restricted or limited, and which operations or features of the vehicle should be maintained in their current states.” Chaves ¶ 138.
“In some implementations, the one or more operations may include (but are not limited to) limiting a top speed of the vehicle, limiting the vehicle to a speed within a certain amount or percentage over a posted speed limit, prohibiting the vehicle from using HOV lanes or toll lanes, . . . disabling or restricting one or more features of a manual driving mode of the vehicle, disabling or restricting one or more features of an autonomous driving mode of the vehicle, or any combination thereof.” Chaves ¶ 133. “For example, in some instances, a vehicle having an unsatisfactory driving score may be limited to travel between home and one or more selected locations.” Chaves ¶ 135.
the server is further configured to . . . transmit the setting to the vehicle,
Detection system 110 (or 400) is configured with “transceivers 430” that “facilitate the exchange of communications (such as signals and messages) between the vehicle 120, . . . [and] the one or more entities 170.” Chaves ¶ 110. Accordingly, “the detection system 400 may limit one or more operations of the vehicle” in the manner discussed above. Chaves ¶ 133.
and the vehicle is configured to: i) receive the setting
For its part, the vehicle 120 (also illustrated as “vehicle 200” in FIG. 2) likewise includes a “communications system 220” that “may be used to establish and maintain communications links between the autonomous vehicle 200 and the detection system 110.” Chaves ¶ 91.
and iii) implement the setting to place the vehicle in a limp mode, thereby assisting in avoiding unsafe driving.
“The vehicle controller 230 may interface with the autonomous vehicle’s control system 210, and may be used to control various operations of the autonomous vehicle 200 including (but not limited to) assuming control of the autonomous vehicle 200, providing instructions to the autonomous vehicle 200, configuring the autonomous vehicle 200 for passenger service, disabling the autonomous vehicle 200, restricting one or more operations of the autonomous vehicle 200, and limiting one or more driving metrics of the autonomous vehicle 200. For example, in some instances, the vehicle controller 230 may be used to limit one or more of a maximum speed of the autonomous vehicle 200, a driving distance of the autonomous vehicle 200, and so on.” Chaves ¶ 93.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to supplement Xu’s distributed control system 1 with Chaves’s speed- and route-limiting operations, thereby implementing the claimed limp mode. One would have been motivated to supplement Xu’s distributed control system 1 with Chaves’s speed- and route-limiting operations because, prior to the effective filing date of the claimed invention, there was already “a need for systems and methods that can monitor the driving behavior of vehicles and generate indications of whether a respective one or more of the monitored vehicles is driving in an unsatisfactory manner (e.g., a manner that may be considered as dangerous or unsafe driving), that is likely to result in an accident, or that is likely to cause injury to occupants of the respective monitored vehicles or to occupants of one or more other vehicles.” Chaves ¶ 63.
That being said, neither Xu nor Chaves appear to explicitly disclose the remaining security features recited in claim 21. That is, while both references teach vehicles that are controlled by a server, the servers are not necessarily configured to “verify that the vehicle is able to receive the setting,” and the vehicles are not necessarily configured to “verify that the server is a valid source.”
Aust, however, teaches
A system comprising:
Reference is made to FIGS. 1 and 2, which teach a “software update system 100” for updating software on a vehicle. See Aust ¶ 50 and FIGS. 1–2.
a server; and a vehicle, wherein:
The system 100 includes “includes a server device 101, a wireless access point 102, and an on-vehicle device 103.” Aust ¶ 50.
the server is further configured to . . . ii) verify that the vehicle is able to receive the setting,
As shown in FIG. 2, “[a] software update by the wireless communication is performed under the initiative of the server device 101.” Aust ¶ 56. However, in order to receive the software update, the vehicle must be operational. Therefore, “the control unit 108 of the server device 101 transmits a wake-up request 121,” which is forwarded to “the wake-up receiving unit 107 of the on-vehicle device 103 mounted on the vehicle 104.” Aust ¶¶ 57–58. Likewise, “[w]hen the control unit 108 of the server device 101 receives [a] wake-up completion notice 130 via the communication unit 109, the control unit 108 recognizes that the on-vehicle device 103 having the desired wake-up ID is in a wake-up state at a desired location.” Aust ¶ 60.
and iii) transmit the setting to the vehicle,
“Then, the control unit 108 of the server device 101 transmits, by the communication unit 109, an update program 131 to the communication unit 106 of the on-vehicle device 103 via the wireless access point 102 at the location where the vehicle 104 is present.” Aust ¶ 61.
and the vehicle is configured to: i) receive the setting,
“When the communication unit 106 receives the update program 131, the communication unit 106 transfers it as an update program 132 to the ECU 105.” Aust ¶ 61.
ii) verify that the server is a valid source,
“When the wake-up receiving unit 107 of the on-vehicle device 103 mounted on the vehicle 104 that is present in the wireless coverage area 110 receives the wake-up request 122, it performs security check 123. In the security check 123, the wake-up ID included in the received wake-up request 122 is compared with the wake-up ID stored in advance in the wake-up receiving unit 107. When the received wake-up ID does not match the stored wake-up ID, the wake-up receiving unit 107 disregards the wake-up request. When the received wake-up ID matches the stored wake-up ID, if there is no other security check previously defined as essential, the wake-up receiving unit 107 accepts the wake-up request.” Aust ¶ 58.
and iii) implement the setting
“The ECU 105 receives the update program 132, and updates the currently used program by the received update program 132 (133).” Aust ¶ 61.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to improve the security of Xu and Chaves’s combined vehicle control systems with Aust’s technique of ensuring the vehicle is awake to receive updates, and ensuring that the updates are coming from a valid source. One would have been motivated to improve the security of Xu and Chaves’s respective systems with Aust’s technique because “when wireless communication for software update can be made even when the vehicle is in any place, there is a risk of unauthorized access by a malicious third party.” Aust ¶ 7.
Claim 22
Xu, Chaves, and Aust teach the system of claim 21,
wherein limp mode includes activating autonomous control of the vehicle to return the vehicle to the designated location.
“In some implementations, the one or more operations may include (but are not limited to) limiting a top speed of the vehicle, limiting the vehicle to a speed within a certain amount or percentage over a posted speed limit, prohibiting the vehicle from using HOV lanes or toll lanes, . . . disabling or restricting one or more features of a manual driving mode of the vehicle, disabling or restricting one or more features of an autonomous driving mode of the vehicle, or any combination thereof.” Chaves ¶ 133. “For example, in some instances, a vehicle having an unsatisfactory driving score may be limited to travel between home and one or more selected locations.” Chaves ¶ 135.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 C.F.R. § 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 C.F.R. § 1.17(a)) pursuant to 37 C.F.R. § 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Justin R. Blaufeld whose telephone number is (571)272-4372. The examiner can normally be reached M-F 9:00am - 4:00pm ET.
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, James K Trujillo can be reached at (571) 272-3677. 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.
Justin R. Blaufeld
Primary Examiner
Art Unit 2151
/Justin R. Blaufeld/Primary Examiner, Art Unit 2151