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 .
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.
Response to Arguments
Applicant’s arguments with respect to the newly added limitations “determining a random access point for each of the one or more additional channels” 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.
Applicant's arguments filed 07/23/25, regarding the rejections under 35 USC 122, have been fully considered but they are not persuasive.
On page 11, of applicant’s response, applicant repeatedly argues that “Therefore, in the context of the present claims, the term "Android operating system," does indeed identify a specific product and technology, i.e., the Android operating system, and there is no other generic way of referring to this specific operating system.”
In response, it is noted that the claims do not recite the term “Android operating system”, and instead merely recite a “set-top box with Android”. While the examiner agrees that the term “Android operating system” would successfully identify the specific technology, this is not currently claimed.
As seen in applicant’s own specification and claim 16, the general term “Android” is used in reference to a plurality of different elements within the system, Android TV, Android TV Input Framework, Android services, Android TV Manager, Android platform, Android application (see applicant’s originally filed specification at paragraph 26-28, claim 16).
In response to applicant’s arguments on pages 12-13, of applicant’s response, it is noted that none of the cited portions of the specification disclose that the prefetching includes “setting up a decoding path for each of the one or more additional channels”, “performing basic time stamp management on each of the one or more additional channels” and “determining a random access point for each of the one or more additional channels” as now claimed.
While the specification discloses that these steps are performed during “pretuning”, it is noted that pretuning is disclosed within the specification as separate from the “prefetching”.
Applicant points to paragraphs 30-31, of the PGPub of the application as support, however, these paragraphs (corresponding to Fig. 3) do not include any reference to “prefetching” or any suggestion that the functionality would be performed by “prefetching”.
This is further shown in paragraph 48 of the PGPub of the application which explicitly discloses performing pretuning on already prefetched channels, the pretuning including the steps of
“setting up a decoding path for each of the one or more additional channels”,
“performing basic time stamp management on each of the one or more additional channels” and
“determining a random access point for each of the one or more additional channels” as now claimed.
Paragraph 32 of the application describes the “sendAppPrivateCommand” being used to initiate prefetch and pre-tuning.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claims 1, 10, 16, recite “wherein the prefetching the one or more additional channels includes setting up a decoding path for each of the one or more additional channels; and performing basic time stamp management on each of the one or more additional channels; and determining a random access point for each of the one or more additional channels”, which is not supported by applicant’s specification as originally filed.
While the specification describes “prefetching” and “pretuning” the claimed steps are described as being performed as part of a “pretuning” functionality which is performed on already prefetched channels (see paragraph 48 of the PGPub of the application and paragraph 46 of the application as filed).
There is no specific disclosure of the “prefetching” also including the steps of the pretuning, as claimed, as these functions are described as being performed on prefetched channels.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-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 applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 1 and 16, line 1, and claim 10, line 3, contain the trademark/trade name “Android”. Where a trademark or trade name is used in a claim as a limitation to identify or describe a particular material or product, the claim does not comply with the requirements of 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph. See Ex parte Simpson, 218 USPQ 1020 (Bd. App. 1982). The claim scope is uncertain since the trademark or trade name cannot be used properly to identify any particular material or product. A trademark or trade name is used to identify a source of goods, and not the goods themselves. Thus, a trademark or trade name does not identify or describe the goods associated with the trademark or trade name. In the present case, the trademark/trade name is used to identify/describe a software operating system and, accordingly, the identification/description is indefinite.
In response to applicant’s arguments regarding “prefetching” and dropping channels within Braness,
Braness discloses determining a plurality of secondary channels and then receiving those determined channels as streams (Fig 8, 825-830; paragraph 81-82). These meets the claim limitation of “prefetching” as the secondary programs channels are “prefetched” before ever being explicitly requested by the viewer.
Similarly, the determined secondary channels are “dropped” whenever a new primary channel is selected, as new secondary programs replace the previous secondary channels when the primary program is changed (see paragraph 83-86).
In response to applicant’s arguments regarding the “prefetching” not including streaming , e.g. decoding,
It is noted that “streaming” and “decoding” are not the same action as applicant appears to suggest. Adaptive streaming within Braness is the transmission of the broadcast content stream from the server to the client device. Decoding is the process that later occurs at the client device to process the received stream for display (paragraph 63-64, 67-75).
The “prefetching” is met by Braness performing all the claimed limitations required in regards to “prefetching”, as he “prefetches” the secondary content by requesting it before it is required, and then performs the claimed processing.
Claim Rejections - 35 USC § 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.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Braness et al. (Braness) (US 2014/0006635) (of record) in view of Android Developers (https: //developer.android.com/) (via web.archive.org) (2020) (of record) and Ogle et al. (Ogle) (US 2016/0029078).
As to claim 1, while Braness discloses a method for channel change on a set-top box (Fig. 1, paragraph 27, 39, 125), the method comprising:
playing, on the set-top box, a first channel with a content request command (paragraph 44, 77-80);
prefetching and dropping, from a memory of the set-top box, one or more additional channels with a prefetching command with parameters (selective buffering of specific secondary programs/channels and streaming rates; paragraph 65-66, 81, 85-86, 102-103), wherein the prefetching the one or more additional channels including:
setting up of a decode path for each of the one or more additional channels (Fig. 7; paragraph 65-75);
performing basic time stamp management on each of the one or more additional channels (time code synchronization of received streams; see Braness at paragraph 64-65),
Braness fails to specifically disclose a stb with Android and the commands of android.media.tv.tvView.tune and appPrivateCommand with bundle parameters, and determining a random access point for each of the one or more additional channels.
In an analogous art, Android Developers discloses providing TV services via an android device(see Android TV overview, pages 1-2 and Build TV input Services pages 3-4), playing a first content channel with android.media.tv.tvView.tune (see TvView, pages 5-6) and appPrivateCommand with bundle parameters (see InputMethod, pages 7-8, 10-12) so as to provide common software standard and commands to implement television functionality utilizing the same architecture already existing in known phones and tablets (see Android TV overview, pages 1-2).
Additionally, in an analogous art, Ogle discloses a system for providing fast channel changes (see Fig. 3-4B; paragraph 17-18, 24-25) which will prefetch one or more additional channels (paragraph 21-24) including setting up of a decode path for each of the one or more additional channels (Fig. 7; paragraph 21) and determining a random access point for each of the one or more additional channels (access points for each channel to begin tuning; see Fig. 5, paragraph 26-34) so as to track and identify locations where the content signal can be properly accessed (paragraph 21, 26-28).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Braness’ system to include a stb with Android and the commands of android.media.tv.tvView.tune and appPrivateCommand with bundle parameters, as taught in combination with Android Developers, for the typical benefit of conforming to a known software architecture which was already existing and in use (see Android TV overview, pages 1-2) through the application of a known technique to a known device ready for improvement to yield predictable results.
Additionally, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Braness and Android Developers to include determining a random access point for each of the one or more additional channels, as taught in combination with Ogle, for the typical benefit of tracking and identifying locations where the content signal can be properly accessed (paragraph 21).
As to claim 2, Braness, Android Developers and Ogle disclose wherein the bundle parameters include a play channel uniform resource identifier ("playchannelUri"), a next channel uniform resource identifier ("nextChannelUri"), and a dropped channel uniform resource identifier ("droppedChannelUri") (see Android Developers at InputMethod, pages 7-8, 10-12 for AppPrivateCommand command formatting and Braness at paragraph 77, 81, 86, 101-103, for the selection of program channels being prefetched, next channels to prefetch and channels which are “dropped” and no longer prefetched based upon user selections).
As to claim 3, Braness, Android Developers and Ogle disclose pretuning, on the set-top box, each of the one or more additional prefetched channels (each newly prefetched secondary channel may be received, buffered and decoded while awaiting selection; see Braness at Fig. 7, paragraph 65-71, 75).
As to claim 4, Braness, Android Developers and Ogle disclose selecting each of the one or more additional prefetched channels based on the channel playing on the set-top box (see Braness at paragraph 42, 44, 65, 103).
As to claim 5, Braness, Android Developers and Ogle disclose uploading, on the set-top box, a user guide, the user guide providing a list of channels available to the set-top box (see Braness at Fig. 3, paragraph 39, 42, 65); and
selecting, on the set-top box, the each of the one or more additional prefetched channels based on the channel playing on the set-top box and the user guide, the selected each of the one or more additional prefetched channels being channels adjacent to the channel playing on the set-top box from the list of channels available from the user guide (secondary channels adjacent to the current watched channel are selected for buffering; see Braness at paragraph 42, 44, 65, 103).
As to claim 6, Braness, Android Developers and Ogle disclose dropping, from the memory of the set-top box, one or more of the additional prefetched channels upon selection of a second channel for playback on the set-top box (selection of new group of secondary channels to replace previous channels based upon currently viewed program; see Braness at Fig. 8, 825-840, paragraph 81-86, 102-103).
As to claim 7, Braness, Android Developers and Ogle disclose pretuning, on the set-top box, each of the one or more additional prefetched channels if one of the one or more additional prefetched channels is selected for playback (each newly prefetched secondary channel may be received, buffered and decoded while awaiting selection; see Braness at Fig. 7, paragraph 65-75, 83-86).
As to claim 8, Braness, Android Developers and Ogle disclose wherein the pretuning of each of the one or more prefetched channels comprises:
decoding video content for each of the one or more prefetched channels (see Braness at Fig. 7, 714; paragraph 65-75 and Ogle at paragraph 21, 34).
As to claim 9, Braness, Android Developers and Ogle disclose wherein the first channel is a broadcast media with input in a motion picture experts group - transport stream (MPEG-TS) format (see Braness at paragraph 55).
As to claim 10, while Braness discloses a non-transitory computer readable medium storing computer readable program code that, when executed by a processor, causes the processor to channel a change on a set-top box (Fig. 1, 14; client device stb with processor 1404 running software from memory 1405; paragraph 27, 39, 115-125), the program code comprising instructions for:
playing, on the set-top box, a first channel with a content request command (paragraph 44, 77-80);
prefetching and dropping, from a memory of the set-top box, one or more additional channels with a prefetching command with parameters (selective buffering of specific secondary programs/channels and streaming rates; paragraph 65-66, 81, 85-86, 102-103),
wherein the prefetching the one or more additional channels including:
setting up of a decode path for each of the one or more additional channels (Fig. 7; paragraph 65-75);
performing basic time stamp management on each of the one or more additional channels (time code synchronization of received streams; see Braness at paragraph 64-65),
Braness fails to specifically disclose a stb with Android and the commands of android.media.tv.tvView.tune and appPrivateCommand with bundle parameters, and determining a random access point for each of the one or more additional channels.
In an analogous art, Android Developers discloses providing TV services via an android device(see Android TV overview, pages 1-2 and Build TV input Services pages 3-4), playing a first content channel with android.media.tv.tvView.tune (see TvView, pages 5-6) and appPrivateCommand with bundle parameters (see InputMethod, pages 7-8, 10-12) so as to provide common software standard and commands to implement television functionality utilizing the same architecture already existing in known phones and tablets (see Android TV overview, pages 1-2).
Additionally, in an analogous art, Ogle discloses a system for providing fast channel changes (see Fig. 3-4B; paragraph 17-18, 24-25) which will prefetch one or more additional channels (paragraph 21-24) including setting up of a decode path for each of the one or more additional channels (Fig. 7; paragraph 21) and determining a random access point for each of the one or more additional channels (access points for each channel to begin tuning; see Fig. 5, paragraph 26-34) so as to track and identify locations where the content signal can be properly accessed (paragraph 21, 26-28).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Braness’ system to include a stb with Android and the commands of android.media.tv.tvView.tune and appPrivateCommand with bundle parameters, as taught in combination with Android Developers, for the typical benefit of conforming to a known software architecture which was already existing and in use (see Android TV overview, pages 1-2) through the application of a known technique to a known device ready for improvement to yield predictable results.
Additionally, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Braness and Android Developers to include determining a random access point for each of the one or more additional channels, as taught in combination with Ogle, for the typical benefit of tracking and identifying locations where the content signal can be properly accessed (paragraph 21).
As to claim 11, Braness, Android Developers and Ogle disclose wherein the bundle parameters include a play channel uniform resource identifier ("playchannelUri"), a next channel uniform resource identifier ("nextChannelUri"), and a dropped channel uniform resource identifier ("droppedChannelUri") (see Android Developers at InputMethod, pages 7-8, 10-12 for AppPrivateCommand command formatting and Braness at paragraph 77, 81, 86, 101-103, for the selection of program channels being prefetched, next channels to prefetch and channels which are “dropped” and no longer prefetched based upon user selections).
As to claim 12, Braness, Android Developers and Ogle disclose pretuning, on the set-top box, each of the one or more additional prefetched channels (each newly prefetched secondary channel may be received, buffered and decoded while awaiting selection; see Braness at Fig. 7, paragraph 65-71, 75); and
selecting each of the one or more additional prefetched channels based on the channel playing on the set-top box (channels adjacent to the current channel; see Braness at paragraph 42, 44, 65, 103).
As to claim 13, Braness, Android Developers and Ogle disclose uploading, on the set-top box, a user guide, the user guide providing a list of channels available to the set-top box (see Braness at Fig. 3, paragraph 39, 42, 65); and
selecting, on the set-top box, the each of the one or more additional prefetched channels based on the channel playing on the set-top box and the user guide, the selected each of the one or more additional prefetched channels being channels adjacent to the channel playing on the set-top box from the list of channels available from the user guide (secondary channels adjacent to the current watched channel are selected for buffering; see Braness at paragraph 42, 44, 65, 103).
As to claim 14, Braness, Android Developers and Ogle disclose dropping, from the memory of the set-top box, one or more of the additional prefetched channels upon selection of a second channel for playback on the set-top box (selection of new group of secondary channels to replace previous channels based upon currently viewed program; see Braness at Fig. 8, 825-840, paragraph 81-86, 102-103).
As to claim 15, Braness, Android Developers and Ogle disclose pretuning, on the set-top box, each of the one or more additional prefetched channels if one of the one or more additional prefetched channels is selected for playback (each newly prefetched secondary channel may be received, buffered and decoded while awaiting selection; see Braness at Fig. 7, paragraph 65-75, 83-86); and
wherein the pretuning of each of the one or more prefetched channels comprises:
decoding video content for each of the one or more prefetched channels (see Braness at Fig. 7, 714; paragraph 65-75 and Ogle at paragraph 21, 34).
As to claim 16, while Braness discloses a set-top box comprising a set-top box platform (Fig. 1, 14; client device stb with processor 1404 running software from memory 1405; paragraph 27, 39, 115-125), configured to:
play, on the set-top box, a first channel with a content request command (paragraph 44, 77-80);
prefetch and drop, from a memory of the set-top box, one or more additional channels with a prefetching command with parameters (selective buffering of specific secondary programs/channels and streaming rates; paragraph 65-66, 81, 85-86, 102-103),
wherein the prefetching the one or more additional channels including:
setting up of a decode path for each of the one or more additional channels (Fig. 7; paragraph 65-75);
performing basic time stamp management on each of the one or more additional channels (time code synchronization of received streams; see Braness at paragraph 64-65),
Braness fails to specifically disclose a set-top box middleware and a set-top box platform driver interface, an Android service, the Android service including an Android TV manager and a TV provider, the Android TV manager and the TV provider comprising a TV Input Framework, and the commands of android.media.tv.tvView.tune and appPrivateCommand with bundle parameters and determining a random access point for each of the one or more additional channels.
In an analogous art, Android Developers discloses providing TV services via an android device (see Android TV overview, pages 1-2 and Build TV input Services pages 3-4), comprising a middleware and a platform driver interface, an Android service, the Android service including an Android TV manager and a TV provider, the Android TV manager and the TV provider comprising a TV Input Framework (see Build TV Input Services, pages 3-4 and Figure 1, indicating Android TV Input Framework, Manager and Provider), playing a first content channel with android.media.tv.tvView.tune (see TvView, pages 5-6) and appPrivateCommand with bundle parameters (see InputMethod, pages 7-8, 10-12) so as to provide common software standard and commands to implement television functionality utilizing the same architecture already existing in known phones and tablets (see Android TV overview, pages 1-2).
Additionally, in an analogous art, Ogle discloses a system for providing fast channel changes (see Fig. 3-4B; paragraph 17-18, 24-25) which will prefetch one or more additional channels (paragraph 21-24) including setting up of a decode path for each of the one or more additional channels (Fig. 7; paragraph 21) and determining a random access point for each of the one or more additional channels (access points for each channel to begin tuning; see Fig. 5, paragraph 26-34) so as to track and identify locations where the content signal can be properly accessed (paragraph 21, 26-28).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Braness’ system to include a set-top box middleware and a set-top box platform driver interface, an Android service, the Android service including an Android TV manager and a TV provider, the Android TV manager and the TV provider comprising a TV Input Framework, and the commands of android.media.tv.tvView.tune and appPrivateCommand with bundle parameters, as taught in combination with Android Developers, for the typical benefit of conforming to a known software architecture which was already existing and in use (see Android TV overview, pages 1-2) through the application of a known technique to a known device ready for improvement to yield predictable results.
Additionally, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Braness and Android Developers to include determining a random access point for each of the one or more additional channels, as taught in combination with Ogle, for the typical benefit of tracking and identifying locations where the content signal can be properly accessed (paragraph 21).
As to claim 17, Braness, Android Developers and Ogle disclose wherein the bundle parameters include a play channel uniform resource identifier ("playchannelUri"), a next channel uniform resource identifier ("nextChannelUri"), and a dropped channel uniform resource identifier ("droppedChannelUri") (see Android Developers at InputMethod, pages 7-8, 10-12 for AppPrivateCommand command formatting and Braness at paragraph 77, 81, 86, 101-103, for the selection of program channels being prefetched, next channels to prefetch and channels which are “dropped” and no longer prefetched based upon user selections).
As to claim 18, Braness, Android Developers and Ogle disclose wherein the TV Input Framework is further configured to: pretune, on the set-top box, each of the one or more additional prefetched channels (each newly prefetched secondary channel may be received, buffered and decoded while awaiting selection; see Braness at Fig. 7, paragraph 65-71, 75);
select each of the one or more additional prefetched channels based on the channel playing on the set-top box (see Braness at paragraph 42, 44, 65, 103).
As to claim 19, Braness, Android Developers and Ogle disclose wherein the TV Input Framework is further configured to:
upload, on the set-top box, a user guide, the user guide providing a list of channels available to the set-top box (see Braness at Fig. 3, paragraph 39, 42, 65); and
select, on the set-top box, the each of the one or more additional prefetched channels based on the channel playing on the set-top box and the user guide, the selected each of the one or more additional prefetched channels being channels adjacent to the channel playing on the set-top box from the list of channels available from the user guide (secondary channels adjacent to the current watched channel are selected for buffering; see Braness at paragraph 42, 44, 65, 103).
As to claim 20, Braness, Android Developers and Ogle disclose wherein the TV Input Framework is further configured to
drop, from the memory of the set-top box, one or more of the additional prefetched channels upon selection of a second channel for playback on the set-top box (selection of new group of secondary channels to replace previous channels based upon currently viewed program; see Braness at Fig. 8, 825-840, paragraph 81-86, 102-103);
pretune, on the set-top box, each of the one or more additional prefetched channels if one of the one or more additional prefetched channels is selected for playback (each newly prefetched secondary channel may be received, buffered and decoded while awaiting selection; see Braness at Fig. 7, paragraph 65-75, 83-86); and
wherein the pretuning of each of the one or more prefetched channels comprises:
decoding video content for each of the one or more prefetched channels (see Braness at Fig. 7, 714; paragraph 65-75 and Ogle at paragraph 21, 34).
Conclusion
THIS ACTION IS MADE FINAL. 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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to James R Sheleheda whose telephone number is (571)272-7357. The examiner can normally be reached M-F 8 am-5 pm CST.
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, Benjamin Bruckart can be reached at (571) 272-3982. 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.
/James R Sheleheda/Primary Examiner, Art Unit 2424