DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This office action is based on amendment filed on 12/22/2025 wherein claims 13-32 are pending, claims 29-32 are newly added, claims 14, 22, 23, and 28 are amended. Application claiming priority based on DE102020110970.0 filed on 04/22/2020.
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.
Claim(s) 13-17, 20-25, and 27-28 are rejected under 35 U.S.C. 103 as being unpatentable over Ahmed et al. (US PGPUB 2016/0328254).
As for claim 13, Ahmed teaches a control unit for a user interface of a motor vehicle (Fig. 2, paragraph 33, “…a user interface system for a vehicle….instrument cluster display…”), the control unit comprising:
a system on a chip having a main processor (paragraph 27, “….each of the operating system environments maybe dedicated to different cores (or multiple cores) of a multi-core system-on-a-chip (SoC)…”, and paragraph 64, “…multi-core processing environment 400 is implemented using a system-on-a-chip…architecture…”), wherein the system on a chip comprises:
a first virtual machine implemented by a hypervisor, wherein the first virtual machine is configured to execute a first function associated with a driving operation of the motor vehicle (paragraph 12, “…the first operating system is configured for at least one high reliability application for the vehicle user interface…” paragraph 25-26, “…the vehicle system described herein …includes a virtualization component….” “a high reliability driver information cluster domain may support critical vehicle applications that relate to the safety of the vehicle and/or critical vehicle operations…”, and paragraph 66, “the guest OSs are booted up to provide domains …”) ; and
a second virtual machine implemented by the hypervisor, wherein the second virtual machine is configured to execute a second function, the second function being an infotainment function (paragraph 12, “…the second operating system is configured for a lower reliability application…” paragraph 25-26, “…the vehicle system described herein …includes a virtualization component….” “an entertainment domain may provide….including, e.g., a music player, navigation, phone and/or connectivity applications…”, and paragraph 66, “the guest OSs are booted up to provide domains …”), wherein at least one of an availability requirement, a safety requirement, a robustness requirement, or a drive readiness requirement for the first function is higher than a corresponding requirement for the second function (paragraph 12, “….the first operating system is configured for at least one high reliability application for the vehicle user interface and the second operating system is configured for a lower reliability application…”); and
a flash memory arrangement configured for use by the system on a chip (paragraph 28, “…memory for each dedicated operating system is separated…each core assigned to a guest maybe able to access only a predefined area of physical memory…” in view of paragraph 39, “…solid state memory storage…” teaching memory can be flash memory/solid state memory), the flash memory arrangement comprising:
a first flash memory unit comprising:
data required [hypervisor registers] for starting up the control unit using a bootloader [bootloader], software programs configured to implement the hypervisor [hypervisor] and the first virtual machine [kernel images], and infrastructure software programs including an operating system and a framework of the operating system of the second virtual machine [kernel images and device trees] (paragraph 65, “…hypervisor 402 maybe integrated with a bootloader or work in conjunction with the bootloader to help create the multi-core process environment 400 during boot. The system firmware….can start the bootloader …using a first CPU core (core 0)…load the kernel images and device trees from a boot partition for the guest OSs…Hypervisor 402 can then boot the guest OS for core 1….switch to a hypervisor mode, initialize hypervisor registers…on core 0,” Here, the hypervisor can be integrated with bootloader, thus, the firmware/software used to implement the bootloader/hypervisor are understood as software programs configured to implement the hypervisor. Data required for starting up the control unit using a bootloader is understood as any data used during boot to create the multi-core processing environment 400. Moreover, the kernel images/device trees at the boot partition for the guest OSs are understood as software program to implement the first virtual machine and infrastructure software programs including an operating system and framework of the operating system of the second virtual machine. In particular, examiner note applicant specification contemplate the infrastructure software to include a kernel where the framework provides additional services such as graphics/audio. (See, specification, paragraph 44). Thus, under the BRI, the infrastructure and framework are understood as similar in content to the software program to implement the first virtual machine. Moreover, the infrastructure can be understood as the kernel images and the framework can be understood as device trees managed by the hypervisor/bootloader of the prior art in view of the Specification.); and
a second flash memory unit comprising an application software program [music player/navigation/phone/connectivity applications/applications/user interface components] configured to realize the second function of the second virtual machine (paragraph 26, “…entertainment domain may provide a high quality user experience for applications and user interface components including, e.g., a music player, navigation, phone and/or connectivity applications…” and paragraph 66, “after the guest OSs are booted up to provide domains 408-414…Display area B may represent a music player application user interface provided by displaying output generated by infotainment core 410…” in view of paragraph 67, “…Each guest OS may have its own address space for running processes under its operating system…” and Fig. 4 showing hypervisor separate from the partitions. Here, second flash memory unit is understood to correspond to the memory space allocated for operation of the guest OS that corresponds to the entertainment domain, which clearly runs the above exemplary applications inside its own respective memory space, and it is clearly distinct from the hypervisor/bootloader operated space. ) ,
wherein the first flash memory unit and the second flash memory unit are independently functional flash memory units having their own memory areas (paragraph 65, “….hypervisor…integrated with a bootloader….create the multi-core processing environment …the system firmware (not shown) can start the bootloader …using a first CPU core (core 0)…initialize the data structures used for the guest OS that will run on core 1…” in view of paragraph 28, “…memory for each dedicated operating system is separated. Each of the major operating systems may be bound to one (or more) cores of the processors….provides …hardware enforced security controls…each core assigned to a guest maybe able to access only a predefined area of physical memory and/or a predefined subset of peripheral devices…first guest operating system (OS) can run on a specific core (or cores) ….such that the first guest OS cannot interfere with the operations of other guest OSs running on different cores…” and paragraph 67, “each guest OS may have its own address space for running processes under its operating system…”. While the prior art doesn’t explicitly require each flash memory unit to have their own memory areas, prior art teaches hypervisor/bootloader can operate on a core 0, and instantiating/setting up deployment of guest OS domains on another core, and that each core assigned to a guest can be limited to access a predefined area such that guest OS of one core cannot interfere with the operations of other guest OSs running on different cores. Thus, it would be obvious to a person of ordinary skill in the art before the effective filing date of the application that the hypervisor/bootloader and associated data/images of the boot partition running on a core 0 are separate and independently functioning from the memory space allocated to the entertainment domain running the applications for the entertainment domain on its own respective core(s) that have specific memory address range to use because doing so allows for improved security and stability between the different domains. (Ahmed, paragraphs 28 and 66). Importantly, “independently” as understood in view of the Specification is understood to mean independent of one another in terms of can be addressed independently and independent in terms of their operations. See, Specification paragraph 23 and 46.).
As for claims 27 and 28, they contain similar limitations. Thus, they are rejected under the same rationales.
As for claim 14, Ahmed also teaches the first flash memory unit and the second flash memory unit are implemented as separate flash memory modules, wherein the first flash memory unit and the second flash memory unit are separate structural units (paragraph 65, “….hypervisor…integrated with a bootloader….create the multi-core processing environment …the system firmware (not shown) can start the bootloader …using a first CPU core (core 0)…initialize the data structures used for the guest OS that will run on core 1…” in view of paragraph 28, “…memory for each dedicated operating system is separated. Each of the major operating systems may be bound to one (or more) cores of the processors….provides …hardware enforced security controls…each core assigned to a guest maybe able to access only a predefined area of physical memory and/or a predefined subset of peripheral devices…first guest operating system (OS) can run on a specific core (or cores) ….such that the first guest OS cannot interfere with the operations of other guest OSs running on different cores…” and paragraph 67, “each guest OS may have its own address space for running processes under its operating system…”. As Examiner noted above, the claimed first flash memory unit and the second flash memory unit are independently functional flash units means they are is directed toward two flash memory modules that are independently addressable in two different memory areas (Specification, paragraph 23). The specification further teaches that “the flash memory units implemented as separate flash memory modules to include design the flash memory arrangement and the system on a chip in an integrated manner…” where the use of two different flash memory module is merely because of the existence of plurality of existing physical modules that can be advantageously used, where the separate module themselves are not determinative of the goal of independence between the flash memory areas. (Specification, paragraph 27) The courts has repeatedly found that when whether an object that is separate or a single entity does not affect the achieved goal of the invention, the decision to implement it as either a single object or separate objects is an engineering choice, see, e.g., In re Larson, 340 F.2D 965, 968, 144 USPQ 347, 349 (CCPA 1965); MPEP 2144.04(V)(B), and/or obvious, see, e.g., In re Dulberg 289 F.2D 522, 523, 129 USPQ 348,349 (CCPA1961); MPEP 2144.04(V)(C) Thus, prior art teaching of the independent regions of flash memory that are independent of other flash memory zones renders the claimed invention obvious. In addition, it is also obvious to a person of ordinary skill in the art that the different memory spaces/peripheral devices can be implemented in either a single memory module or separate memory module corresponds to either the different modules of NAND flash memory within a solid state memory storage, or within separate solid state memory storage devices in prior art at paragraphs 39 and 53-54 because doing so would be an engineering choice and obvious choice to take advantage of separate modules of flash memories.) .
As for claim 15, Ahmed also teaches the first flash memory unit and the second flash memory unit are provided in universal flash storage format, as a solid state disk [solid state memory storage] or as an embedded multimedia card [sd card] (paragraph 39, “…may include…integrated circuits, printed circuit…hard disk storage, solid state memory storage…” and paragraph 54, “…one or more Secure Digital (SD) card slots….accept an SD card….retrieve information….retrieve application data from the above described sources and/or write application data to the above described sources…”).
As for claim 16, Ahmed also teaches a software program for operating a hardware component of the system on a chip (paragraph 39, “….manages various inputs and outputs exchanged between application running within multi-core processing environment…and/or various peripheral devices (e.g., devices 303-455)…” and Fig. 3B and 4).
As for claim 17, Ahmed also teaches the hardware component is at least one of a digital signal processor [tuner control/vehicle control/power supply platform temp control/Cortex-A15 core] or a graphics processing unit (Fig. 3B and 4, and paragraphs 44-50. Alternatively, paragraph 72, “pixel buffer content…display output using pixel buffer content…” is understood as performing the functionality of a GPU.).
As for claim 20, Ahmed also teaches a memory space of the first flash memory unit [hypervisor protected memory area] is reserved for the basic software program to facilitate availability of the basic software program, should the second flash memory unit fail (paragraph 77).
As for claim 21, Ahmed also teaches the system on a chip is configured to store the basic software program in the reserved memory space [hypervisor protected memory area] when the second flash memory unit is not available based on a detection of un-availability of the second flash memory unit by the system on chip (paragraph 77).
As for claim 22, Ahmed also teaches the system on a chip is configured to use the reserved memory space for a database provided by the manufacturer and configured to be overwritten with the basic software program (paragraph 77. Examiner note, the claim and the specification does not limit database to be of any specific implementation or purpose or meaning, thus, it is understood as any memory storage area, such as the prior art’s hypervisor-protected memory area.).
As for claim 23, Ahmed also teaches the system on a chip is configured to automatically download the basic software program via a mobile radio interface of the motor vehicle (paragraph 26, “cloud domain may support downloads of vehicle ‘apps’ from the internet…” in view of paragraph 42, “…multi-core processing environment is connected to …..implemented with additional wireless communications devices (…antennas…WIFI-communication, communication over a local area network and/or wireless local area network, etc.….”).
As for claim 24, Ahmed teaches the basic software program is configured as one of a radio application for receiving radio stations, a media playback function, or a projection mode function for a connectable mobile device (Fig. 4 – Infotainment Domain/Native HMI Domain, paragraph 30).
As for claim 25, Ahmed also teaches the first flash memory unit further comprises a software program configured as at least one of a diagnostic function, a configuration function, a database provided by the manufacturer, or a trusted execution environment (paragraphs 65-66 and 77).
As for claim 29, Ahmed also teaches the first flash memory unit is implemented in a first flash memory zone and the second flash memory unit is implemented in a second flash memory zone is inmplemented in a single flash memory module (paragraph 65, “….hypervisor…integrated with a bootloader….create the multi-core processing environment …the system firmware (not shown) can start the bootloader …using a first CPU core (core 0)…initialize the data structures used for the guest OS that will run on core 1…” in view of paragraph 28, “…memory for each dedicated operating system is separated. Each of the major operating systems may be bound to one (or more) cores of the processors….provides …hardware enforced security controls…each core assigned to a guest maybe able to access only a predefined area of physical memory and/or a predefined subset of peripheral devices…first guest operating system (OS) can run on a specific core (or cores) ….such that the first guest OS cannot interfere with the operations of other guest OSs running on different cores…” and paragraph 67, “each guest OS may have its own address space for running processes under its operating system…” teaching separate memory zones. Paragraphs 39, 53, and 54 teaching one or more flash memory modules to implement the memory (solid state memory or SSD in the various paragraphs are understood as flash memory). It’s arbitrary whether the memory zones are implemented in a single memory module or plurality of memory zones. Thus, in the embodiment where a single memory module is used, the prior art).
Claim(s) 19 are rejected under 35 U.S.C. 103 as being unpatentable over Ahmed et al. (US PGPUB 2016/0328254), in view of Vulcano et al. (US PGPUB 2014/0365120).
As for claim 19, Ahmed teaches a first domain containing a copy of a software that runs on a different (second domain) (paragraph 77), thus, it functionally is teaching a basic software program for the second virtual machine is additionally stored in at least one of the first flash memory unit.
In the event that the basic software program provided by a manufacturer for the second virtual machine is understood as a build in application that is distinguished from software implementing the second function claimed in the independent claim. Examiner note Ahmed teaches system on chip including both Media/HMI domains that comes with the vehicle (Fig. 3B-4, with vehicle control system and tuner control systems and other systems of 3B working in conjunction with the various domains such as infotainment domain/native HMI domain/high reliability domain), and teaches the connection and use of smartphone supplied information (i.e., projection), USB/wireless/HDMI based display and operation (See, e.g., paragraph 40-44) and also cloud based applications (paragraph 66), thus it would have been obvious to a person off ordinary skill in the art to recognize this discloses the well-known concept of switch between manufacturer supplied default applications and mobile phone applications performing similar functionalities (i.e., navigation, audio functionalities, etc. provided either by native car supplied application or by exemplary apple phones mentioned in the prior art). Nevertheless, in the interest of compact prosecution, Examiner note Ahmed does not explicitly teach a basic software program provided by the manufacturer for the second virtual machine is additionally stored in at least one of the first flash memory unit where the basic software program is understood as a OEM application performing the same functionality as that of the second virtual machine using a different software application.
However, Vulcano teaches a known method of vehicle interface unit display having plurality of software/display environment combos including a basic software program provided by a manufacturer UI provided vehicle manufacturer/in-vehicle system manufacturer] for the second display/execution environment [mobile device] is additionally stored in at least one of the first flash memory unit (paragraph 16, “UI provided by the vehicle manufacturer….include …build-in navigation system, access to satellite radio, AM radio, FM radio, etc. and other functions…” teaching basic software programs provided by a manufacturer of the head unit. In view of paragraph 117, “…mobile device….radio application, etc.….” having application that is functionally the same, and is understood as different from “a basic software program that came with the head unit.). This known technique is applicable to the system of Ahmed as they both share characteristics and capabilities, namely, they are directed to management of computerized user interface for vehicles with plurality of different input execution environment for projection on shared display.
One of ordinary skill in the art before the effective filing date of the application would have recognized that applying the known technique of Vulcano would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Vulcano to the teachings of Ahmed would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such vehicle user interface management and execution features into similar systems. Further, applying a basic software program provided by a manufacturer for the second execution environment is additionally stored in at least one of the first flash memory unit to Ahmed with vehicle user interface execution multi-core processing environment storing infotainment domain/high reliability domain and native HMI domain software and ability to project connected external application of same functionality and network downloaded applications stored accordingly, would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow for flexible integration of applications that provide better functionalities than build in applications of vehicles (Vulcano, paragraph 3).
Claim(s) 26 are rejected under 35 U.S.C. 103 as being unpatentable over Ahmed et al. (US PGPUB 2016/0328254), in view of Shin et al. (US PGPUB 2019/0121540).
As for claim 26, Ahmed does not explicitly teach SOC is configured to apply flash wear leveling.
However, Shin teaches a known method of SoC implementation in a vehicle (paragraph 65, “….the host 510 may be an SoC (system-on-chip)….” And paragraph 123, claims 12 and 23,”electronic devices implemented in automotive vehicles….” And “apparatus is incorporated into a device selected from ….an automotive vehicle…”) including the system on a chip is configured to apply flash wear leveling to the flash memory arrangement (paragraph 29, “….perform wear leveling for the flash memory…”). This known technique is applicable to the system of Ahmed as they both share characteristics and capabilities, namely, they are directed to execution of SoC system in vehicles.
One of ordinary skill in the art before the effective filing date of the application would have recognized that applying the known technique of Shin would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Shin to the teachings of Ahmed would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such SoC memory management in vehicle features into similar systems. Further, applying the system on a chip is configured to apply flash wear leveling to the flash memory arrangement to Ahmed with vehicle user interface execution multi-core processing environment executed in an SoC with memory management functionality accordingly, would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow for improved memory wear (Shin, paragraph 29).
Allowable Subject Matter
Claims 30-32 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Response to Arguments
Applicant's arguments filed on 12/22/2025 have been fully considered but they are not persuasive.
Applicant argues in the remarks dated 12/22/2025:
Argument I: “…independent claims require “a first flash memory unit” and “a second flash memory unit’ ….Ahmed does not teach ….the recited ‘flash memory unit[s]’…the independent claims require that ‘the first flash memory unit and the second flash memory unit are independently functional flash memory units having their own memory areas.’…reference Ahmed….it simply means that different memory addresses are assignment for use by the two different applications….these different memory addresses do not function independently…” (App. Arg. Pg. 8).
Argument II: “…Ahmed….effectively creating isolated environments…..uses solid state memory storage…..does not teach the functionality or enablement of the two virtual machines is dependent on…two separate flash memories that are two separate structure units… “ (App. Arg. Pg. 9-10).
Examiner respectfully disagrees for the following reasons:
With respect to Argument I, see paragraphs 7 above. In addition, applicant’s argument is directly contradicted by both the explicit teaching of the specification, and dependent claims. In particular, Specification explicitly teaches “…providing a first flash memory unit and a second flash memory unit, memory sections that can be addressed independently are created…” (paragraph 23) and “…both flash memory units…to be implemented in a single flash memory module or a single flash memory component….wherein the first flash memory unit and the second flash memory unit comprise a first flash memory zone and a second flash memory zone in one flash memory module…” (paragraph 28). Thus, the words “unit” in view of specification clearly does not direct to what applicant alleges, but instead, is merely any independently addressable memory zones. Furthermore, memory zones in view of specification where plurality of zones can be in a single flash memory component or module clearly contemplates the use of one or more SSDs which are well known flash memory entities. In addition, the Specification do not define the structural distinctions to determine the met and bound of “flash memory component” and “flash memory module” to be particular objects with well-known basis for defining the mets and bounds of those objects. Indeed, dependent claims 14 further limits the units to mean structural units. Which means claim 13, claim upon which it depends, is broader, and does not have to be separate structural units by definition. Directly contradicting applicant’s argument. Moreover, Dependent claim 29 then explicitly claims the different memory units are within a single module, which directly contradicts applicant’s argument as well. Both in view of specification and in view of dependent claims, Applicant’s argument is unpersuasive and the prior art clearly reads upon the first flash memory unit and the second flash memory units that are operating independently because they are separate regions/memory zones that can not be accessed by other workloads, hence clearly independent in view of the specification of present application.
With respect to argument II, see paragraph 9 above. In addition, As Examiner noted above, The BRI of the claim with respect to first flash memory unit and the second flash memory unit are independently functional flash units means they are is directed toward two flash memory modules that are independently addressable in two different memory areas (Specification, paragraph 23). The specification further teaches that “the flash memory units implemented as separate flash memory modules to include design the flash memory arrangement and the system on a chip in an integrated manner…” where the use of two different flash memory module is merely because of the existence of plurality of existing physical modules that can be advantageously used, where the separate module themselves are not determinative of the goal of independence between the flash memory areas. (Specification, paragraph 27) Thus, structural separation of the units are merely an obvious implementation to take advantage of existence of multiple physical modules, not a necessity to realize the claimed inventive concept. The courts has repeatedly found that when whether an object that is separate or a single entity does not affect the achieved goal of the invention, the decision to implement it as either a single object or separate objects is an engineering choice, see, e.g., In re Larson, 340 F.2D 965, 968, 144 USPQ 347, 349 (CCPA 1965); MPEP 2144.04(V)(B), and/or obvious, see, e.g., In re Dulberg 289 F.2D 522, 523, 129 USPQ 348,349 (CCPA1961); MPEP 2144.04(V)(C) Thus, prior art teaching of the independent regions of flash memory that are independent of other flash memory zones renders the claimed invention obvious. Moreover, it is obvious to a person of ordinary skill in the art that the different memory spaces/peripheral devices can be implemented in either a single memory module or separate memory module corresponds to either the different modules of NAND flash memory within a solid state memory storage, or within separate solid state memory storage devices in prior art at paragraphs 39 and 53-54 because doing so would be an engineering choice and obvious choice to take advantage of separate modules of flash memories. Thus, for the above reasons, applicant’s arguments are without merit.
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 CFR 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 CFR 1.17(a)) pursuant to 37 CFR 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.
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KEVIN X LU whose telephone number is (571)270-1233. The examiner can normally be reached M-F 10am-6pm.
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 can be reached on 5712723759. 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.
/KEVIN X LU/Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199