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 .
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 03/23/2022. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered by the examiner.
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 10-14 and 17-20 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 pre-AIA the applicant regards as the invention. Regarding claim 10, the claim recites “the file path identifier”. There is insufficient antecedent basis for the term “the file path identifier” in the claim.
Regarding claim 11, the claim recites “the vehicle status ”. There is insufficient antecedent basis for the term “the vehicle status ” in the claim.
Regarding claim 12, the claim recites “the first value” and “the second value”. There is insufficient antecedent basis for the terms “the first value” and “the second value” in the claim.
Regarding claim 13, the claim recites “the first sensor”. There is insufficient antecedent basis for the term “the first sensor” in the claim.
Regarding claim 14, the claim recites “the first value”. There is insufficient antecedent basis for the term “the first value” in the claim.
Regarding claim 17, the claim recites “the plurality of values stored in the first file path”. There is insufficient antecedent basis for the term “the plurality of values” and “the first file path” in the claim.
Regarding claim 20, the claim recites “the plurality of values stored in the first file path”. There is insufficient antecedent basis for the term “the plurality of values” and “the first file path” in the claim.
Regarding claims 18-19, dependent claims inherit the deficiencies of the respective parent claim.
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.
Claims 1, 10-17 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Ricci (US 20130138714 A1) in view of Silvester (US 20140200736 A1).
Regarding claim 1, Ricci teaches:
A non-transitory computer-readable medium having instructions recorded thereon that, in response to execution by one or more processors, cause performance of operations comprising: (Claim 16. A computer readable medium having stored thereon computer-executable instructions, the computer executable instructions causing a processor to execute a method for providing a universal bus, the computer-executable instructions comprising:)
receiving, from an Human Machine Interface (HMI) application, a request to read data; ([0073] The vehicle control system 204 may communicate with a device or user interface 212. The user interface 212 may be as described in conjunction with FIG. 5. The user interface 212 may be operable to receive user input either through touch input, on one or more user interface buttons, or through a graphical user interface that may include a gesture capture region, as described in conjunction with FIG. 5. Further, the symbol 212 can represent a device that is located or associated with the vehicle 104. The device 212 can be a mobile device, including, but not limited to, a mobile telephone, a mobile computer, or other type of computing system or device that is either permanently located in or temporarily associated with the automobile 104. Thus, the vehicle control system 204 can interface with the device 212 and leverage the devices computing capability to provide one or more of the features or functions as described herein. [200] receiving input on a user interface of the vehicle, wherein the input requests a cloud service; routing the input to a device; receiving, from the device, data from the cloud service; and providing the data on the display of the vehicle.)
and transmitting requested data among application specific data stored in a second file path in response to determining that the request is not for property data. ([0074] The device or user interface 212 can receive input or provide information to a user 216. The user 216 may thus interact with the vehicle control system 204 through the interface or device 212. Further, the device 212 may include or have access to device data 220. The device data 220 can be any type of data that is used in conjunction with the device 212, including, but not limited to, multimedia data, preferences data, bioinformatics, data associated with the user 216, or other types of data. The data may be stored in a device data 220 as a storage system similar to that described in conjunction with system data 208. [0125] An embodiment of a data structure 800 to store different settings is shown in FIG. 8. The data structure 800 may include one or more of data files or data objects 804. Thus, the data structure 800 may represent different types of data bases or data storage, for example, object-oriented data bases, flat file data structures, relational database, or other types of data storage arrangements. The data file 804 may include several portions 808-836 representing different types of data. Each of these types of data may be associated with a user, as shown in portion 808.)
Ricci does not appear to explicitly teach: determining whether the request is for property data; transmitting a requested value among a plurality of values stored in a first file path in response to determining that the request is for property data;
However, Silvester teaches: [0042] FIGS. 9A-9D show a flowchart of the procedure used by the computer of FIG. 1 to provide information about the automobile of FIG. 1 to the user, according to embodiments of the invention. In FIG. 9A, at block 905, the owner's manual is displayed to the user. At block 910, the computer receives a request for information from the user. At decision point 915, the computer decides what kind of data the user requested. If the user requested real-time data about a part of the automobile, then at block 920 the computer receives the real-time data from the appropriate sensor. If the user requested information about how to use the part, then at block 925 the computer accesses the appropriate information from the owner's manual. [0043] If the user requested any data from the storage of the computer, then at decision point 927 (FIG. 9B) the computer determines whether the user requested the service history of the automobile or stored sensor data. If the user requested the service history of the automobile, then at block 930 the computer accesses the service history of the automobile from storage. If the user requested stored sensor data, then at decision point 932 the computer determines if there is any stored sensor data to access. If there is, then at decision point 933 the stored sensor data is accessed.
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Ricci and Silvester before them, to include Silvester’s request type determination and corresponding data source in Ricci’s vehicle HMI system for vehicle and application data. One would have been motivated to make such a combination to more efficiently route HMI request to the storage source containing the requested information and reliable provide vehicle data or application data for the use as taught by Silvester [0041-0045]
Regarding claim 10, Ricci teaches:
The computer-readable medium of claim 1, wherein the operations further comprise changing the file path identifier of the first file path in response to a vehicle status. ([0166] The provision of certain types of multimedia data, for example video data, may not be allowed during certain vehicle operations or to certain passengers within the vehicle 104. For example, a driver cannot watch a movie while driving. Thus, the processor 504 can determine if the safety parameters for the particular person desiring the multimedia data are met.[0167-0168] If those safety parameters are not met, the method 1700 proceeds NO to step 1732. In step 1732, the processor 504 may record the data to local storage. Thus, the data may be provided at a later time from this local storage. Likewise, the processor 504 can send a signal to another data storage element that can record the data. Thus, the processor 504 can coordinate the recording of the data for the user in a different source that allows the user to view it after they are done operating the vehicle 104.)
Regarding claim 11, Ricci teaches:
The computer-readable medium of claim 1, wherein the vehicle status is one of speed, automated driving, or emergency situation. ([0085] In one implementation, the control system 424 receives and reads sensor signals, such as wheel and engine speed signals, as a digital input comprising, for example, a pulse width modulated (PWM) signal. The processor 304 can be configured, for example, to read each of the signals into a port configured as a counter or configured to generate an interrupt on receipt of a pulse, such that the processor 304 can determine, for example, the engine speed in revolutions per minute (RPM) and the speed of the vehicle in miles per hour (MPH). One skilled in the art will recognize that the two signals can be received from existing sensors in a vehicle comprising a tachometer and a speedometer, respectively. Alternatively, the current engine speed and vehicle speed can be received in a communication packet as numeric values from a conventional dashboard subsystem comprising a tachometer and a speedometer.)
Regarding claim 12, Ricci teaches:
The computer-readable medium of claim 1, wherein the first value is retrieved from a first vehicle sensor, and the second value is retrieved from a second vehicle sensor. ([0083] The vehicle 104 includes a number of sensors in wireless or wired communication with the vehicle control system 204 and/or display device 212 to collect sensed information regarding the vehicle state, configuration, and/or operation. Exemplary sensors include wheel state sensor 460 to sense one or more of vehicle speed, acceleration, deceleration, wheel rotation, wheel speed (e.g., wheel revolutions-per-minute), wheel slip, and the like, a power source energy output sensor 464 to sense a power output of the power source 409 by measuring one or more of current engine speed (e.g., revolutions-per-minute), energy input and/or output (e.g., voltage, current, fuel consumption, and torque) (e.g., turbine speed sensor, input speed sensor, crankshaft position sensor, manifold absolute pressure sensor, mass flow sensor, and the like), and the like, a switch state sensor 468 to determine a current activation or deactivation state of the power source activation/deactivation switch 444, a transmission setting sensor 470 to determine a current setting of the transmission (e.g., gear selection or setting), a gear controller sensor 472 to determine a current setting of the gear controller 416, a power controller sensor 474 to determine a current setting of the power controller 420, a brake sensor 476 to determine a current state (braking or non-braking) of the braking system 436, a seating system sensor 478 to determine a seat setting and current weight of seated occupant, if any) in a selected seat of the seating system 448, exterior and interior sound receivers 490 and 492 (e.g., a microphone and other type of acoustic-to-electric transducer or sensor) to receive and convert sound waves into an equivalent analog or digital signal.)
Regarding claim 13, Ricci teaches:
The computer-readable medium of claim 1, wherein the first sensor is one of a speedometer, a fuel sensor, or a tachometer. ([0085] ). One skilled in the art will recognize that the two signals can be received from existing sensors in a vehicle comprising a tachometer and a speedometer, respectively. Alternatively, the current engine speed and vehicle speed can be received in a communication packet as numeric values from a conventional dashboard subsystem comprising a tachometer and a speedometer.)
Regarding claim 14, Ricci teaches:
The computer-readable medium of claim 1, wherein the first value is one of a vehicle speed, an amount of fuel, an engine RPM, or a number of connected devices. ([0085] In one implementation, the control system 424 receives and reads sensor signals, such as wheel and engine speed signals, as a digital input comprising, for example, a pulse width modulated (PWM) signal. The processor 304 can be configured, for example, to read each of the signals into a port configured as a counter or configured to generate an interrupt on receipt of a pulse, such that the processor 304 can determine, for example, the engine speed in revolutions per minute (RPM) and the speed of the vehicle in miles per hour (MPH).)
Regarding claim 15, Ricci teaches:
The computer-readable medium of claim 1, wherein the HMI application is one of a navigation application, a media application, or a user communication application. ([0103] The applications 664 can be any higher level software that executes particular console functionality for the user. Applications 664 can include programs such as vehicle control applications, email clients, web browsers, texting applications, games, media players, office suites, etc. The applications 664 can be stored in an application store 660, which may represent any memory or data storage, and the management software associated therewith, for storing the applications 664. Once executed, the applications 664 may be run in a different area of memory 608. [0164] The user may select from the vehicle user interface 568 a request for multimedia, in step 1760. The user touch sensitive display 568 can receive the request and send the request to the processor 504. The processor 504 can determine the source for the multimedia selected and request that media from that source, in step 1720. In embodiments the processor 504 may request the multimedia from two or more sources. The request can be sent from the processor 504 to the signal processor 1108. There, the signal processor 1108 can send the request to the device 1008 or to the server 224.)
Regarding claim 16, Haidar teaches:
The computer-readable medium of claim 1, wherein the application specific data is one of account data or user information. ([0126] There may be one or more user records 840 and associated data stored within the data file 804. The user can be any person that uses or rides within the vehicle or conveyance 104. The user may be identified in portion 812. For the vehicle 104, the user may include a set of one or more features that may identify the user. These features may be the physical characteristics of the person that may be identified by facial recognition or some other type of system. In other embodiments, the user may provide a unique code to the vehicle control system 204 or provide some other type of data that allows the vehicle control system 204 to identify the user. The features or characteristics of the user are then stored in portion 812.)
Regarding claim 17, the claim recites similar limitation as corresponding claim 1 and is rejected for similar reasons as claim 1 using similar teachings and rationale.
Regarding claim 20, the claim recites similar limitation as corresponding claim 1 and is rejected for similar reasons as claim 1 using similar teachings and rationale.
Claims 2, 6-9 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Ricci (US 20130138714 A1) in view of Silvester (US 20140200736 A1) and further view of Haidar (US 20170078398 A1).
Regarding claim 2, Ricci does not appear to explicitly teach:
The computer-readable medium of claim 1, wherein the operations further comprise: retrieving a first value through a first vehicle Application Programming Interface (API);retrieving a second value through a second vehicle API; converting at least one of the first value or the second value from a proprietary format into a common format; and recording the first value and the second value to a first file path among the plurality of values.
However, Haidar teaches: ([0049] The instruction sets and subroutines of client-side vehicle infotainment processes 12, 14, 16, 18, which may be stored on storage devices 36, 38, 40, 42 (respectively) coupled to client electronic devices 28, 30, 32, 34 (respectively), may be executed by one or more processors (not shown) and one or more memory architectures (not shown) incorporated into client electronic devices 28, 30, 32, 34 (respectively). Storage devices 36, 38, 40, 42 may include but are not limited to: hard disk drives; tape drives; optical drives; solid state storage devices; RAID arrays; random access memories (RAM); read-only memories (ROM); compact flash (CF) storage devices; secure digital (SD) storage devices; and memory stick storage devices. [0078]A collection of API's 350 suitable for use with a vehicle platform are shown in FIG. 7. These API's can include without limitation Device API 305; Transaction API 315; Vehicle AP 310; Event API 307; Telemetry API 320; Trip API 327; Diagnostic API 328; Safety API 325; and Behavioral API 328. These API's can be used to develop application for use on the platform that request data or other information with an API and receive from the platform or device 11, third party content providers or other data repositories. [0125] Various data structures, APIs (application programming interfaces), data types, and other computing architectures can be used. In one embodiment, JavaScript Object Notation (JSON) is used as data exchange/data transmission format. Other data exchange/data transmission formats can be used between the various devices, platforms, portals, and APIs described and depicted herein without limitation.)
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Ricci, Silvester and Haidar before them, to include Haidar’s plurality of vehicle API’s in Ricci Silvester vehicle information system. One would have been motivated to make such combination to allow values from different components or data to be retrieved through an API in the same format and avoid the need for each application to separately process source specific data formats as taught by Haidar [0078], [0125].
Regarding claim 6, Haidar teaches:
The computer-readable medium of claim 2, wherein the first value is retrieved in response to a change notification received through the first vehicle API. ([0061] The vehicle infotainment application can use local or server-based vehicle telemetry data to determine how and when to display information to a user. For instance, notifications sent by multiple 3.sup.rd party applications can be queued by the infotainment display while the vehicle is moving and only shown to the driver when the vehicle has come to a stop. Similarly certain information may be displayed based on triggers and rules that depend on real-time vehicle information. For instance, when stopped, the infotainment display can notify a user that their fuel economy was improved in the preceding section of the trip or that they exceeded the speed limit 2 times so far this trip. Geofences and other boundary constraints can be used to define rules which when triggered result in events or data that changes application output on the platform.) Refer to claim 2 for the motivation to combine.
Regarding claim 7, Silvester teaches:
The computer-readable medium of claim 2, wherein the first value is retrieved in response to the request to read data. ([0022] FIG. 2 also shows storage 205 as storing sensor data 230. Not only may computer 110 display the real-time data to the user, but computer 110 may also store the data in storage 205 for later retrieval. For example, if sensor 225 is detecting the automobile speed, then sensor data 230 may store the speed history of the vehicle. This allows the user to determine how fast the automobile has been driven. Or, if sensor 225 is an impact sensor, then sensor data 230 may store any times the automobile sensed an impact. Then, instead of requesting the real-time data generated by sensor 225, the user may request sensor data 230 from storage 205. By retrieving sensor data 230 from storage 205, the user may review how others have used the car in his absence.). Refer to claim 1 for the motivation to combine.
Regarding claim 8, Haidar teaches:
The computer-readable medium of claim 1, wherein the request is received through a property manager API. ([0078] Carport may be based on vehicle information platform APIs and may enable rich experiences based on vehicle specific and relevant data. Driving patterns, vehicle health and trip specific scenarios are viewable in Carport at a glance. Carport may enable drivers with visibility to the connections, people and devices outside of the car. Carport's focus is enhancing the experience for the driver, while allowing the car to seamlessly connect and communicate with the world around them. A collection of API's 350 suitable for use with a vehicle platform are shown in FIG. 7. These API's can include without limitation Device API 305; Transaction API 315; Vehicle AP 310; Event API 307; Telemetry API 320; Trip API 327; Diagnostic API 328; Safety API 325; and Behavioral API 328. These API's can be used to develop application for use on the platform that request data or other information with an API and receive from the platform or device 11, third party content providers or other data repositories. Additional exemplary details for implementing such API's are provided in Appendix A as non-limiting examples of suitable APIs.). Refer to claim 2 for the motivation to combine.
Regarding claim 9, Haidar teaches:
The computer-readable medium of claim 1, wherein the first file path has a higher access restriction than the second file path. ([0082] Unauthorized persons may not access or communicate through Carport and only those devices authenticated may gain access. Username and password are required to access the Carport system, followed by phone messaging to validate that this is rightful access. Carport does not store any data on its own besides some configuration and vehicle-specific settings. The Carport system and 3rd-party applications may rely primarily on the data within the vehicle information platform. In one embodiment, this information comes from the vehicles IVI memory or through an on board device such as a dongle or plug that connects to an OBD port). Refr to claim 2 for the motivation to combine.
Regarding claim 18, the claim recites similar limitation as corresponding claim 2 and is rejected for similar reasons as claim 2 using similar teachings and rationale.
Claims 3-5 are rejected under 35 U.S.C. 103 as being unpatentable over Ricci (US 20130138714 A1) in view of Silvester (US 20140200736 A1) and further view of Haidar (US 20170078398 A1) and O'Meara (US 20150230277 A1).
Regarding claim 3, Ricci does not appear to explicitly teach:
The computer-readable medium of claim 2, wherein the operations further comprise receiving, from an HMI application, a request to write data among the application specific data.
However, O'Meara teaches: [0084] It should be understood that an interface similar to that of the web portal 605 can be displayed on the head unit of the vehicle. The user could then make selections from such interface for selecting applications from the controlled list 610. The selected applications could be downloaded immediately to the vehicle instead of being put in the download directory when the selections are made from the interface. [0156] If the vehicle head unit 1412 receives an application instruction, the vehicle head unit 1412 may build a graphical user interface with software buttons for a mobile device application that can utilize the vehicle head unit 1412 as an extended interface (signal 1509). The displayed GUI may utilize one of the HMI screens 1423 (FIG. 14) of the template HMI application 1421 (FIG. 14). In response to a user input selecting a mobile device application to utilize the vehicle head unit 12 as an extended interface, the vehicle head unit 12 executes a corresponding one of the downloaded application instruction(s) (signal 1511). The vehicle head unit operates the template HMI application based on a result of the executing the corresponding application instruction(s) (signal 1513). See also [0184-0186]
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Ricci and O'Meara before them, to include O'Meara’s head unit HMI application selection and processing features in Ricci’s vehicle HMI system for vehicle and application data. One would have been motivated to make such a combination to allow the user to access, manage application data , configuration and content through the vehicle. The combination would have involved the predictable use of O'Meara’s known head unit HMI in Haidar’s vehicle infotainment.
Regarding claim 4, O'Meara teaches:
The computer-readable medium of claim 3, wherein the operations further comprise recording the data among the application specific data to the second file path in response to the request to write the data among the application specific data. ([0081] A vehicle user can also select applications to be included in the download directory 239 using a computing terminal 626, for example using any internet accessible computing device such as the mobile device or a desktop computer. The computing terminal 626 accesses the application selection portion 628 of the user web portal 605 (which is hosted by a web server operated by the provider in one example) to view the controlled list 610 of applications that can be installed on his vehicle. The user can then send communications 661 to select applications from the controlled list 610 that the user would like installed on his vehicle. These selections 662 are fed into the download directory 239. [0108] According to the above, applications can be accumulated into the per-vehicle download directories 339A-B on a per-directory basis. Upon the head unit coupling to a particular one of the mobile devices, data from a corresponding one of the download directories 339A-B can be downloaded and installed onto the vehicle to provide a customized application set and a customized user interface.[0109] It should be understood that an interface similar to that of the web portal 905 can be displayed on the head unit of the vehicle. The user could then make selections from such interface for selecting applications from the controlled list. The selected applications could be downloaded immediately to the vehicle instead of being put in the download directory when the selections are made from the interface.) Refer to claim 3 for the motivation to combine.
Regarding claim 5, O'Meara teaches:
The computer-readable medium of claim 2, wherein the request includes a file path identifier, and the determining is based on the file path identifier. ([0093] The software 332 then checks the selected one of the download directories A-B to determine if there are any applications currently stored in the selected directory. A scheme for intelligently selecting applications that are present in the download directories A-B will be discussed in detail later with reference to FIG. 9. For now, let it be assumed for the purposes of illustration that the download directories 339A and 339B currently include applications 340A (M-P) and 340B (Q-S), respectively, in addition to the head unit frontend configurations 369A and 369B.[0094] As noted briefly in the previous paragraph, the download directories A-B include head unit frontend configurations A-B, respectively, in addition to the applications 340A and 340B. The configurations A-B can be stored as HTML code or other web code compatible with the web code renderer of the 399. Depending on which one of the head unit frontend configurations A-B is downloaded to the head unit 321, a display 380 of the head unit 321 will display a different graphical user interface. Each of the different web code files 369A and 369B will produce a different graphical user interface when displayed using the display 380 and the renderer 399. For example, each graphical user interface could have its own user customized settings such as a particular wallpaper selected by a user. A scheme for generating the different head unit frontend configurations A-B will be discussed in detail later with reference to FIG. 9.) Refer to claim 3 for the motivation to combine.
Claim 19 is rejected under 35 U.S.C. 103 as being unpatentable over Ricci (US 20130138714 A1) in view of Silvester (US 20140200736 A1) and O'Meara (US 20150230277 A1).
Regarding claim 19, Ricci does not appear to explicitly teach:
The method of of claim 17, further comprising receiving, from an HMI application, a request to write data among the application specific data.
However, O'Meara teaches: [0084] It should be understood that an interface similar to that of the web portal 605 can be displayed on the head unit of the vehicle. The user could then make selections from such interface for selecting applications from the controlled list 610. The selected applications could be downloaded immediately to the vehicle instead of being put in the download directory when the selections are made from the interface. [0156] If the vehicle head unit 1412 receives an application instruction, the vehicle head unit 1412 may build a graphical user interface with software buttons for a mobile device application that can utilize the vehicle head unit 1412 as an extended interface (signal 1509). The displayed GUI may utilize one of the HMI screens 1423 (FIG. 14) of the template HMI application 1421 (FIG. 14). In response to a user input selecting a mobile device application to utilize the vehicle head unit 12 as an extended interface, the vehicle head unit 12 executes a corresponding one of the downloaded application instruction(s) (signal 1511). The vehicle head unit operates the template HMI application based on a result of the executing the corresponding application instruction(s) (signal 1513). See also [0184-0186]
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Ricci and O'Meara before them, to include O'Meara’s head unit HMI application selection and processing features in Ricci’s vehicle HMI system for vehicle and application data. One would have been motivated to make such a combination to allow the user to access, manage application data , configuration and content through the vehicle. The combination would have involved the predictable use of O'Meara’s known head unit HMI in Haidar’s vehicle infotainment.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CARLOS A ESPANA whose telephone number is (703)756-1069. The examiner can normally be reached Monday - Friday 8 a.m - 5 p.m EST.
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, LEWIS BULLOCK JR can be reached at (571)272-3759. 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.
/C.A.E./Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199
Prosecution Insights