DETAILED ACTION
This office action is responsive to the above identified application filed 04/08/2025. The application contains claims 1-20, all examined and rejected.
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 .
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.
Claim(s) 1-11 and 18 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.
Claim(S) 1 and 18 reciting, “in the event that there have been no further modifications,” is indefinite. The limitation is missing a reference point or limit that bounds the evaluation of whether there are any “further” modifications. Does “no further modifications” mean: no modifications during synchronization until synchronization is complete? no modifications for a threshold period of time? no modifications after the determined modification in step (a)? Further clarification is required.
Claims 2-10 are rejected based on being dependent on claim 1.
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.
Claim(s) 1-15 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Parkison et al. (US 20150370827 A1) in view of Neff et al. (US 20090232220 A1) and Matters (US 20200272603 A1).
Regarding claim 1, Parkison discloses:
A method of synchronizing a media file between two computing devices, at least by (paragraph [0007, 0110] “techniques for synchronizing file updates between two cloud controllers of a distributed filesystem… cloud controller sends a synchronization update request for the file to a second cloud controller and in response receives a synchronization update for the file from the second cloud controller”… paragraph [0048] “A request server 304 in cloud controller 300 may receive file requests from either local processes or via a network from a client 306.”)
said media file including: a file header, at least by (paragraph [0030] “meta-data typically appears at the beginning of streaming files as a file header section.”)
314 in metadata 310 include pointer fields that indicate the location of the file data in a disk block 316”)
said synchronizing of the media file occurring between a first copy of the media file stored at the first computing device, and a second copy of the media file stored on the second computing device, at least by [0076] first copy of file z at cloud control 704 and a second copy of file z at cloud controller 706 and synchronizing updated between them)
at least by (paragraph [0076] describes updates/synchronization happening after the write/close not before finalization of the first copy of the media file
wherein said method comprises, at the first computing device:(a) determining a modification to a descriptor portion of the first copy of the media file, at least by (paragraph [0010, 0112] determines “specific changes to the file's metadata (“deltas”) that allow the target cloud controller to update the target file to the most recent version”)
(b) determining media elements to send to the second computing device for addition to the second copy of the media file, at least by (paragraph [0113] “the deltas included in a synchronization update may include both metadata and data updates for the target file. For instance, in the example of FIG. 11, client 1106's changes to file Z typically may involve both updated metadata as well as some new, additional (and/or modified) file data.” Where the identified data updates and additional data are media elements to send to the second computing device for addition to the second copy of the media file)
and(c) in the event that there have been no further modifications to the descriptor portion of the first copy of the media file, sending synchronization data to the second computing device to enable updating of the second copy of the media file, at least by (paragraph [0116] “cloud controllers sending a request for a write lock to the owning cloud controller for a file may be configured to always include version identification information for the requested file to ensure that they have the most recent metadata for the requested file. The owning cloud controller can determine whether the requestor has a current version, and if not, send a synchronization update along with the write lock.” Where the write lock release would indicate “no further modifications to the descriptor portion of the first copy”)
Parkison fails to specifically describe:
(a) said media file including: a file header
(b) at least one descriptor portion enabling reading of media elements in the body portion
(c) wherein the file header includes an indication of a location of the at least one descriptor portion within the file,
(d) wherein synchronization of the second copy of the media file with the first copy of the media file commences before finalization of the first copy of the media file and continues at least while one or more media elements are being written to a file body of the first copy of the media file at the first computing device,
However, Neff teaches the above limitation (a) at least by (paragraph [0068, 0070] “file type atom, ‘ftyp’” and “Movie Header atom… ‘mvhd’”.
Neff teaches the above limitation (b) at least by (paragraph [0061] “’movie atom’… metadata describe the audio data and or the video data”; paragraph [0068] “track atoms…. give information about the media data”)
Neff teaches the above limitation (c) at least by (paragraph [0061] location of the metadata in the file may precede a location of the audio data and/or the video data”; paragraph [0072] “byte offset… indicate a location of each ‘Chunk’… with the file (‘stco’)”)
Neff teaches the above limitation (d) at least by (paragraph [0058] “reformatting digital broadcast multimedia for a mobile device may reformat incoming mobile broadcast audiovisual content into 3GPP Progressive Download format in real time while simultaneously delivering a resulting 3GPP Progressive Download file to the mobile device for rendering.” Which describes the ability to transfer the media to a second device while reformatting… audiovisual content (e.g. before finalization of the first copy of the media file and continues at least while one or more media elements are being written to a file body of the first copy of the media file at the first computing device)
Matters further describes (d) at least by (paragraph [0086] “continuously sync operations such that as the data changes…. are written…. the same data stream is sent”; paragraph [0088] snapshot generated … “while the changes…are sent” )
Therefore, before the effective filing date of the invention it would have been obvious to one of ordinary skill in the art to combine the system of Parkison with Neff and Matters to provide real time downloaded access to media while the media file is being updated to a supported format (Neff, 0017), and to also track, merge and queue changes in an atomic operation in an intermediate device to enable faster synchronization (Matters, para. 0103).
As per claim 2, claim 1 is incorporated and Parkison further discloses:
storing a last-updated version of the descriptor portion of the first copy of the media file to enable step (a), at least by (paragraph [0112] “existing version of a file to the most recent version of the file that was recently written to the cloud controller that sent the update. The cloud controller with the most recent version of a file can use version information from the target cloud controller to craft a set of specific changes to the file's metadata (“deltas”) that allow the target cloud controller to update the target file to the most recent version”)
As per claim 3, claim 1 is incorporated and Parkison further discloses:
wherein step (a) comprises any one or more of: receiving a notification of a modification from another process or application; polling the first copy of the media file to detect a detect a modification thereto; or determining a change in either or both of, a location or content of the descriptor portion of the first copy of the media file, at least by (paragraph [0111] “cloud controller 1104 determines that (based on a recent registration notification message) cloud controller 1100 is registered to receive changes for file Z and sends a change notification for file Z to cloud controller… request for an updated version of file Z to cloud controller 1104… synchronization update includes what is essentially an incremental metadata snapshot that only includes changes for file Z and an updated file version identifier for file Z”)
As per claim 4, claim 2 is incorporated and Parkison further discloses:
wherein in the event that there have been further modifications to the media file's descriptor portion in the first copy of the media file while performing (b), returning to step (a), at least by (paragraph [0077-0080] describes detecting changes while the the registration notification has not expired and renewing the registration to capture more updates)
As per claim 5, claim 1 is incorporated and Parkison further discloses:
wherein step (b) comprises: comparing the last-updated version of the descriptor portion of the first copy of the media file to a current descriptor portion of the first copy of the media file; and determining one or more media elements written to the file body since the storage of the last- updated version of the media file's descriptor portion, at least by (paragraph [0113] “changes to file Z typically may involve both updated metadata as well as some new, additional (and/or modified) file data….data changes for file Z to cloud storage system 302 via an incremental data snapshot.. the synchronization update may also include an incremental data snapshot that includes any file data that has changed for (or been added to) file Z subsequent to the metadata version send by cloud controller 1100.”)
As per claim 6, claim 1 is incorporated and Parkison further discloses:
wherein the synchronization data comprises: a current file header; a current descriptor portion of the first copy of the media file; and those media elements written to the file body of the first version of the media file between the storage of the last-updated version of the media file's descriptor portion and the time at which (a) was performed, at least by (paragraph [0113] “changes to file Z typically may involve both updated metadata as well as some new, additional (and/or modified) file data….data changes for file Z to cloud storage system 302 via an incremental data snapshot.. the synchronization update may also include an incremental data snapshot that includes any file data that has changed for (or been added to) file Z subsequent to the metadata version send by cloud controller 1100.” Where, paragraph [0030] “meta-data typically appears at the beginning of streaming files as a file header section.”)
As per claim 7, claim 6 is incorporated and Parkison further discloses:
wherein step (a) includes: storing a separate copy of the current version of the descriptor portion and file header of the first copy of the media file; wherein in step (c) the synchronization data is derived from said separate copy of the current version of the descriptor portion and file header of the first copy of the media file, at least by (paragraph [0112] “recent version of a file can use version information from the target cloud controller to craft a set of specific changes to the file's metadata (“deltas”) that allow the target cloud controller to update the target file to the most recent version” said metadata delta is a separate copy)
and media elements written to the file body of the first version of the media file since the storage of the last-updated version of the descriptor portion of the first copy of the media file and the time at which said separate copies of the current version of the descriptor portion and file header of the first copy of the media file were made, at least by (paragraph [0113] “changes to file Z typically may involve both updated metadata as well as some new, additional (and/or modified) file data….data changes for file Z to cloud storage system 302 via an incremental data snapshot.. the synchronization update may also include an incremental data snapshot that includes any file data that has changed for (or been added to) file Z subsequent to the metadata version send by cloud controller 1100.”)
As per claim 8, claim 7 is incorporated and Parkison further discloses:
which upon synchronization of the second copy of the file, the method comprises: updating the last-updated version of the descriptor portion of the first copy of the media file using the current version of the descriptor portion used in the last synchronization event and returning to step (a) to enable a subsequent synchronization, at least by (paragraph [0112] “recent version of a file can use version information from the target cloud controller to craft a set of specific changes to the file's metadata (“deltas”) that allow the target cloud controller to update the target file to the most recent version” said metadata delta is a separate copy)
As per claim 9, claim 1 is incorporated and Parkison further discloses:
which is performed by a synchronization process or application that is separate from a process or application causing the first copy of the media file to be written at the first computing device, at least by (paragraph [0109] “a synchronization operation” which is separate from paragraph [0096] the writing and locking process that “causing the first copy of the media file to be written at the first computing device)
As per claim 10, claim 1 is incorporated and Parkison further discloses:
wherein the process or application causing the first copy of the media file to be written at the first computing device indicates to the synchronization process the finalization of writing the first copy of the media file, at least by paragraph [0096-0097] which describes the writing completed and lock released triggering notification of a change to the synchronizing operation)
Regarding claim 11, Parkison discloses:
a method of synchronizing a media file between two computing devices, at least by (paragraph [0007, 0110] “techniques for synchronizing file updates between two cloud controllers of a distributed filesystem… cloud controller sends a synchronization update request for the file to a second cloud controller and in response receives a synchronization update for the file from the second cloud controller”… paragraph [0048] “A request server 304 in cloud controller 300 may receive file requests from either local processes or via a network from a client 306.”)
said media file including: a file header, at least by (paragraph [0030] “meta-data typically appears at the beginning of streaming files as a file header section.”)
314 in metadata 310 include pointer fields that indicate the location of the file data in a disk block 316”)
said synchronizing of the media file occurring between a first copy of the media file stored at the first computing device, and a second copy of the media file stored on the second computing device, at least by [0076] first copy of file z at cloud control 704 and a second copy of file z at cloud controller 706 and synchronizing updated between them)
at least by (paragraph [0076] describes updates/synchronization happening after the write/close not before finalization of the first copy of the media file
wherein said method comprises, at the second computing device: receiving the synchronization data to enable updating of the second copy of the media file, at least by (paragraph [0076] “Cloud controller 706 receives the change notification, and can then immediately retrieve the latest metadata and data for file Z from cloud controller 704)
and updating the second copy of the media file by writing updated data relating to least one of the file header, descriptor portion, or file body of the second copy of the media file, at least by (paragraph [0113] “After processing the synchronization update, the receiving cloud controller logically has the entire copy of the modified file, even if only a small amount of new data and metadata were included in the synchronization update”)
Parkison fails to specifically describe:
(a) said media file including: a file header
(b) at least one descriptor portion enabling reading of media elements in the body portion
(c) wherein the file header includes an indication of a location of the at least one descriptor portion within the file,
(d) wherein synchronization of the second copy of the media file with the first copy of the media file commences before finalization of the first copy of the media file and continues at least while one or more media elements are being written to a file body of the first copy of the media file at the first computing device,
However, Neff teaches the above limitation (a) at least by (paragraph [0068, 0070] “file type atom, ‘ftyp’” and “Movie Header atom… ‘mvhd’”.
Neff teaches the above limitation (b) at least by (paragraph [0061] “’movie atom’… metadata describe the audio data and or the video data”; paragraph [0068] “track atoms…. give information about the media data”)
Neff teaches the above limitation (c) at least by (paragraph [0061] location of the metadata in the file may precede a location of the audio data and/or the video data”; paragraph [0072] “byte offset… indicate a location of each ‘Chunk’… with the file (‘stco’)”)
Neff teaches the above limitation (d) at least by (paragraph [0058] “reformatting digital broadcast multimedia for a mobile device may reformat incoming mobile broadcast audiovisual content into 3GPP Progressive Download format in real time while simultaneously delivering a resulting 3GPP Progressive Download file to the mobile device for rendering.” Which describes the ability to transfer the media to a second device while reformatting… audiovisual content (e.g. before finalization of the first copy of the media file and continues at least while one or more media elements are being written to a file body of the first copy of the media file at the first computing device)
Matters further describes (d) at least by (paragraph [0086] “continuously sync operations such that as the data changes…. are written…. the same data stream is sent”; paragraph [0088] snapshot generated … “while the changes…are sent” )
Therefore, before the effective filing date of the invention it would have been obvious to one of ordinary skill in the art to combine the system of Parkison with Neff and Matters to provide real time downloaded access to media while the media file is being updated to a supported format (Neff, 0017), and to also track, merge and queue changes in an atomic operation in an intermediate device to enable faster synchronization (Matters, para. 0103).
As per claim 12, claim 11 is incorporated and Parkison further discloses:
which comprises creating a new version of the second copy of the media file, at least by (paragraph [0113] “the synchronization update allows cloud controller 1100 to present the new version of file Z to client 1102”)
As per claim 13, claim 12 is incorporated and Parkison further discloses:
wherein creating a new version of the second copy of the media file comprises appending a patch to current version of the second copy of the media, said patch containing said updated data, at least by (paragraph [0113] “some file changes only a small amount of (or even no) data may need to be sent; at the other extreme, if a new file is being created and written all of the file data for the new file may need to be sent. Sending updated file data for file Z directly to cloud controller 1100 as part of the synchronization update allows cloud controller 1100 to present the new version of file Z to client 1102”)
As per claim 14, claim 13 is incorporated and Parkison further discloses:
which includes preventing reading of said patch of the new version of the second copy of the media file until the writing of the updated data is complete, such that a client computing device can only read the current version of the second copy of the second media file during synchronization, at least by (paragraph [0143] “ensure that data written to this file does indeed remain consistent by rapidly migrating an exclusive byte-range write lock that locks beyond the end of the file throughout the system to each cloud controller that receives an actual write from a client for that file. Note that the cloud controllers simultaneously grant shared read-only byte-range locks for the rest of the shared status log file, thereby ensuring that the work-sharing monitor applications can read previously written data safely (and also ensuring that no clients can perform non-appending writes to the file).”)
As per claim 15, claim 11 is incorporated and Parkison further discloses:
at the second computing device, updating the second copy of the media file by: writing the current version of the descriptor portion and file header of the first copy of the media file to the second copy of the media file; and writing the media elements contained in the synchronization data to the to the second copy of the media file, at least by (paragraph [0113] “Cloud controller 1104 will eventually (lazily) write the file data changes for file Z to cloud storage system 302 via an incremental data snapshot, …the synchronization update may also include an incremental data snapshot that includes any file data that has changed for (or been added to) file Z subsequent to the metadata version send by cloud controller 1100.… Sending updated file data for file Z directly to cloud controller 1100 as part of the synchronization update allows cloud controller 1100 to present the new version of file Z to client 1102… After processing the synchronization update, the receiving cloud controller logically has the entire copy of the modified file”)
Regarding claim 18, Parkison discloses:
a method of synchronizing a media file between two computing devices, comprising a first computing device and a second computing device that are in data communication with each other via a communications network, at least by (paragraph [0007, 0110] “techniques for synchronizing file updates between two cloud controllers of a distributed filesystem… cloud controller sends a synchronization update request for the file to a second cloud controller and in response receives a synchronization update for the file from the second cloud controller”… paragraph [0048] “A request server 304 in cloud controller 300 may receive file requests from either local processes or via a network from a client 306.”)
said media file including: a file header, at least by (paragraph [0030] “meta-data typically appears at the beginning of streaming files as a file header section.”)
314 in metadata 310 include pointer fields that indicate the location of the file data in a disk block 316”)
said synchronizing of the media file occurring between a first copy of the media file stored at the first computing device, and a second copy of the media file stored on the second computing device, at least by [0076] first copy of file z at cloud control 704 and a second copy of file z at cloud controller 706 and synchronizing updated between them)
at least by (paragraph [0076] describes updates/synchronization happening after the write/close not before finalization of the first copy of the media file
wherein said method comprises, at the first computing device:(a) determining a modification to a descriptor portion of the first copy of the media file, at least by (paragraph [0010, 0112] determines “specific changes to the file's metadata (“deltas”) that allow the target cloud controller to update the target file to the most recent version”)
(b) determining media elements to send to the second computing device for addition to the second copy of the media file, at least by (paragraph [0113] “ the deltas included in a synchronization update may include both metadata and data updates for the target file. For instance, in the example of FIG. 11, client 1106's changes to file Z typically may involve both updated metadata as well as some new, additional (and/or modified) file data.” Where the identified data updates and additional data are media elements to send to the second computing device for addition to the second copy of the media file)
and(c) in the event that there have been no further modifications to the descriptor portion of the first copy of the media file, sending synchronization data to the second computing device to enable updating of the second copy of the media file, at least by (paragraph [0116] “cloud controllers sending a request for a write lock to the owning cloud controller for a file may be configured to always include version identification information for the requested file to ensure that they have the most recent metadata for the requested file. The owning cloud controller can determine whether the requestor has a current version, and if not, send a synchronization update along with the write lock.” Where the write lock release would indicate “no further modifications to the descriptor portion of the first copy”)
and wherein said method comprises, at the second computing device: receiving the synchronization data to enable updating of the second copy of the media file, at least by (paragraph [0076] “Cloud controller 706 receives the change notification, and can then immediately retrieve the latest metadata and data for file Z from cloud controller 704)
and updating the second copy of the media file by writing updated data relating to least one of the file header, descriptor portion, or file body of the second copy of the media file, at least by (paragraph [0113] “After processing the synchronization update, the receiving cloud controller logically has the entire copy of the modified file, even if only a small amount of new data and metadata were included in the synchronization update”)
Parkison fails to specifically describe:
(a) said media file including: a file header
(b) at least one descriptor portion enabling reading of media elements in the body portion
(c) wherein the file header includes an indication of a location of the at least one descriptor portion within the file,
(d) wherein synchronization of the second copy of the media file with the first copy of the media file commences before finalization of the first copy of the media file and continues at least while one or more media elements are being written to a file body of the first copy of the media file at the first computing device,
However, Neff teaches the above limitation (a) at least by (paragraph [0068, 0070] “file type atom, ‘ftyp’” and “Movie Header atom… ‘mvhd’”.
Neff teaches the above limitation (b) at least by (paragraph [0061] “’movie atom’… metadata describe the audio data and or the video data”; paragraph [0068] “track atoms…. give information about the media data”)
Neff teaches the above limitation (c) at least by (paragraph [0061] location of the metadata in the file may precede a location of the audio data and/or the video data”; paragraph [0072] “byte offset… indicate a location of each ‘Chunk’… with the file (‘stco’)”)
Neff teaches the above limitation (d) at least by (paragraph [0058] “reformatting digital broadcast multimedia for a mobile device may reformat incoming mobile broadcast audiovisual content into 3GPP Progressive Download format in real time while simultaneously delivering a resulting 3GPP Progressive Download file to the mobile device for rendering.” Which describes the ability to transfer the media to a second device while reformatting… audiovisual content (e.g. before finalization of the first copy of the media file and continues at least while one or more media elements are being written to a file body of the first copy of the media file at the first computing device)
Matters further describes (d) at least by (paragraph [0086] “continuously sync operations such that as the data changes…. are written…. the same data stream is sent”; paragraph [0088] snapshot generated … “while the changes…are sent” )
Therefore, before the effective filing date of the invention it would have been obvious to one of ordinary skill in the art to combine the system of Parkison with Neff and Matters to provide real time downloaded access to media while the media file is being updated to a supported format (Neff, 0017), and to also track, merge and queue changes in an atomic operation in an intermediate device to enable faster synchronization (Matters, para. 0103).
Claim(s) 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Parkison, Neff and Matters in view of Wyatt et al. (US 20060149704 A1).
As per claim 17, claim 16 is incorporated and Parkison fails to disclose:
truncating the second copy of the media file to delete the last updated descriptor portion from the second copy of the media file, after synchronization.
But Wyatt describes the above limitation at least by (paragraph [0031] “reconciles the metadata read from the alternate stream and the metadata read from the media file at 314. After reconciling the metadata in memory at 314, the invention attempts to update the media file at 316 with the reconciled metadata.” Paragraph [0033] “ attempt to write the reconciled metadata to the media file is successful at 406, the invention deletes the alternate stream “ where the paragraph [0026] “updates to the metadata in an update data store (e.g., an alternate data stream))
Therefore, before the effective filing date of the invention it would have been obvious to one of ordinary skill in the art to combine the system of Parkison, Neff and Matters with Wyatt to “enable[s] a user to edit metadata associated with a media file”, “improve[ing] latent write systems by storing the edits or updates to the metadata when the file is in a read-only state and attempting to write the edits or updates to the media file when the media file becomes writeable” (Wyatt, para. 0019).
Allowable Subject Matter
Claim 16 reciting: wherein in the event that writing the media elements contained in the synchronization data to the to the second copy of the media file would overwrite the copy of the last updated descriptor portion in the second copy of the media file; the method further includes: prior to overwriting the last updated descriptor portion of the second copy of the media file with new media elements, writing a copy of the last-updated version of the descriptor portion at a location past the current version of the descriptor portion; and modifying the file header to indicate the location of the at last updated descriptor portion within the second copy of the media file to enable temporary reading of the second copy of the media file during synchronization; and once all media elements contained in the synchronization data are written to the second copy of the media file, modifying the file header to indicate the location of the at current descriptor portion within the file to enable full reading of the second copy of media file; is 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.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Myllyla et al. (US 7725431 B2): Claim 6.
Aksu et. al. (US 20030061369 A1): Abstract, Para. 0031.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DENNIS TRUONG whose telephone number is (571)270-3157. The examiner can normally be reached Monday - Friday 7:00 am - 3:30 pm PT.
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, Neveen Abel-Jail can be reached at 571-270-0474. 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.
/DENNIS TRUONG/Primary Examiner, Art Unit 2152 3/18/2026