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 .
Double Patenting
Claims 1-2, 4-6, 8-9, 11-13, 15-16 and 18 of the instant application (19/028,035) are provisionally rejected under the judicially created doctrine of nonstatutory obviousness-type double patenting as being unpatentable over claims 1-3, 7-9, 14-15 of co-pending Application No. 19/096,829 (Pre-Grant Publication No. US 2025/0316031 A1) ("the '031 application"). Although the conflicting claims are not identical, they are not patentably distinct from each other for at least the reasons set forth below.
The '031 application is directed to the same subject matter as the instant application — a method for signaling AR device capabilities (including audio and video encoder/decoder capabilities) to a network so that AR content can be delivered, encoded, and decoded in a manner compatible with the requesting device. Claim 1 of the '031 application recites every limitation of claim 1 of the instant application, and further narrows those limitations by additional recitations directed to a 5G session-negotiation context (e.g., a "device type indication and a media capabilities indication," a "session negotiation between a first 5G endpoint and a second 5G endpoint," and the AR device "being controlled by one of the first 5G endpoint and the second 5G endpoint"). Because practicing claim 1 of the '031 application necessarily practices claim 1 of the instant application, claim 1 of the instant application is anticipated by, and in any event would have been an obvious variant of, claim 1 of the '031 application to a person having ordinary skill in the art. A side-by-side comparison of claim 1 of each application is provided below.
Application 19/028,035, Claim 1
Application 19/096,829 (US 2025/0316031 A1), Claim 1
Claim 1: "A method for video decoding, the method performed by at least one processor and comprising:"
Claim 1: "A method for video decoding, the method performed by at least one processor and comprising:"
"determining capabilities of an augmented reality (AR) device, the capabilities indicating any of an audio encoder or decoder of the AR device and a video encoder or decoder of the AR device;"
"determining, based on at least one of a device type indication and a media capabilities indication, capabilities of an augmented reality (AR) device, the capabilities indicating any of an audio encoder or decoder of the AR device and a video encoder or decoder of the AR device, the at least one of the device type indication and the media capabilities indication being an indication that is both of any of video codec capabilities, audio codec capabilities, and scene processing capabilities and is also of a provision transmitted during a session negotiation between a first 5G endpoint and a second 5G endpoint, the AR device being controlled by one of the first 5G endpoint and the second 5G endpoint;"
"obtaining AR data comprising a media component of at least one of audio and video based on a request signaling the capabilities of the AR device to a server providing the AR data; and"
"obtaining AR data including a media component of at least one of audio and video based on the capabilities, determined based on at least one of a device type indication and a media capabilities indication, of the AR device; and"
"decoding the AR data based on the capabilities of the AR device signaled to the server."
"decoding the AR data based on the capabilities of the AR device."
As shown above, every limitation of instant claim 1 is recited, in at least equally specific if not narrower form, by claim 1 of the '031 application. The '031 application's claim 1 additionally requires that the capabilities be determined "based on at least one of a device type indication and a media capabilities indication" and that the request occur "during a session negotiation between a first 5G endpoint and a second 5G endpoint," neither of which is precluded by, and both of which fall within the scope of, instant claim 1's broader "request signaling the capabilities of the AR device to a server." Accordingly, instant claim 1 is not patentably distinct from claim 1 of the '031 application.
The remaining claims of the instant application are similarly not patentably distinct from the correspondingly listed claims of the '031 application identified in the table below. In the interest of compact prosecution, a detailed limitation-by-limitation analysis is provided above only for claim 1; the claim correspondence for the remaining claims is summarized as follows, and a like rationale (i.e., that the identified claim(s) of the '031 application recite the same or narrower subject matter than the corresponding instant claim) applies to each pairing.
Application 19/028,035, Claim No.
Application 19/096,829 (US 2025/0316031 A1), Corresponding Claim No.
1
1
2
2 (device type/media capabilities indication in the form of a URI)
4
1 (URI-based indication of codec-type capabilities)
5
3, 7 (aggregated device-type capabilities; concurrent instances of decoder/encoder)
6
2 (“devicetype” URI syntax)
8
8
9
9
11
8
12
14
13
9
15
15
16
16
18
15
This is a provisional double patenting rejection because the conflicting claims have not in fact been patented. A rejection based on nonstatutory double patenting may be obviated by filing a terminal disclaimer in accordance with 37 CFR 1.321(c) or 1.321(d), disclaiming the terminal part of the statutory term of any patent granted on the instant application that would extend beyond the expiration date of any patent granted on the '031 application, and further requiring that any patent so granted be enforceable only for and during such period that the instant application and the '031 application are commonly owned. The requirement is met when both applications are shown to be commonly owned, or subject to a joint research agreement, in accordance with 37 CFR 1.130(b).
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.
Claim(s) 1, 4, 8, 11 and 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Yip et al. (U.S. Patent Application Publication No. 2022/0028172; "Yip" hereinafter), in view of Stockhammer et al. (U.S. Patent Application Publication No. 2019/0238950; “Stockhammer” hereinafter).
Regarding claim 1, Yip discloses a method for video decoding performed by at least one processor (see FIG. 10 and accompanying description, disclosing a UE comprising a processor 1010, transceiver 1020, and memory 1030) and comprising:
determining capabilities of an augmented reality (AR) device, the capabilities indicating any of an encoder or decoder functions of the AR device (see FIG. 5, operations 501 and 505, disclosing a UE receiving an initial capability report and a device status report, including hardware capability information, from at least one component device, e.g. XR glasses. Pars. 126 and 128 disclose: “In operation 505, the corresponding component device may transmit a device status report to the UE. For example, the device status report may include the following device status information or device capability information… Hardware capabilities of the device (e.g., for a camera, a RGB resolution, a depth resolution, and an FOV; for XR glasses, encoder and decoder functions, a 3D modeling function, a display resolution, a display FOV, etc.”); and
obtaining AR data comprising a media component of at least one of audio and video based on a request signaling the capabilities of the AR device to a server providing the AR data (see FIG. 5, operations 507-508, disclosing the UE transmitting a device capability report to an XR service provider (i.e. a server), the XR service provider responding with device configuration information and a service entry point, and the UE establishing an XR service session through which media data, including audio and video, is exchanged. Par. 129 further discloses: “In operation 506, the UE may select at least one XR service from the XR service list based on initial capability reports received in operation 501, the XR service list received in operation 503, and device status reports received in operation 505. The UE may collect device status reports received from the one or more component devices in operation 505, and select, from the XR service list, an XR service having capability requirements that match a status or capability of each component device”. Par. 124 discloses that the XR services may include an XR conference, an AR conference, a video call, etc.).
However, Yip does not explicitly disclose that the capabilities indicate any of an audio encoder or decoder of the AR device and a video encoder or decoder of the AR device, nor decoding the AR data based on the capabilities of the AR device signaled to the server.
In the same field of endeavor, Stockhammer discloses a client device that determines its own audio and video decoding capabilities via its own audio decoder and video decoder (see FIG. 1, audio decoder 46 and video decoder 48) and signals information representing those capabilities to a server, such that "ad server 284 may have sufficient information regarding capabilities (e.g., decoding and/or rendering capabilities) of constrained device 288... [to] properly prepare and provide the content" (see ¶¶ 198 and 247), and that thereafter selects and requests content matched to those self-signaled decoding capabilities, disclosing that "Retrieval unit 52 may then determine main content to retrieve (352). For example, retrieval unit 52 may determine coding and rendering capabilities of video decoder 48, audio decoder 46, video output 44, and audio output 42, as well as user preferences (such as language preferences), then select appropriate adaptation sets according to these capabilities and preferences" (see ¶ 255), and that subsequently decodes the retrieved content using its own audio and video decoders based on the previously self-signaled capabilities (see FIG. 9, operations 352-366, disclosing that the client device determines main content to retrieve based on the decoding and rendering capabilities of its own decoders, requests segments of that content, and decodes the retrieved data).
Therefore, it would have been obvious to a person having ordinary skill in the art (PHOSITA) before the effective filing date of the invention to incorporate Stockhammer's audio/video decoder capability signaling and capability-based decoding into the device capability report and AR data retrieval process of Yip, in order to ensure that a server delivers, and the requesting AR device decodes, AR content in a format compatible with the specific decoder hardware and software resources that were already confirmed as available on that device, as expressly motivated in Stockhammer.
Regarding claim 4, the combination of Yip and Stockhammer discloses the method of claim 1, wherein the request signaling the capabilities of the AR device comprises a list of at least some of the capabilities of the AR device, and the at least some of the capabilities of the AR device indicating optional codecs of the AR device (Stockhammer further discloses selecting and requesting content based on "codecs supported by decoders of constrained device 288" (¶ 247), i.e., a list of the device's supported/optional codecs).
Regarding claim 8, Yip discloses a method for video encoding substantially as discussed above with respect to claim 1, including determining capabilities of an AR device (Yip, FIG. 5, operations 501 and 505; FIG. 12, operation 1210) and obtaining AR data comprising a media component of at least one of audio and video based on a request signaling the capabilities of the AR device to a server providing the AR data (Yip, FIG. 5, operations 507-508), and further discloses encoding AR data based on the capabilities of the AR device signaled to the server, performed by the same terminal that identified and signaled those capabilities (see FIG. 12, operations 1220-1240, disclosing that the first terminal establishes a session, performs pre-processing including format conversion on the 3D media data, and encodes the pre-processed 3D media data before transmission to the second terminal).
However, Yip does not explicitly disclose that the capabilities indicate any of an audio encoder or decoder of the AR device and a video encoder or decoder of the AR device.
As discussed above with respect to claim 1, Stockhammer discloses that a client device's capabilities are represented, in part, by its audio decoder and video decoder (FIG. 1, audio decoder 46 and video decoder 48), and that content is selected based on "codecs supported by decoders of constrained device 288... audio codec and rendering capabilities" (¶ 255) — a disclosure of an audio and video decoder that satisfies the claimed "audio encoder or decoder" and "video encoder or decoder" in the alternative. Therefore, for the same reasons discussed above with respect to claim 1, it would have been obvious to a PHOSITA to incorporate Stockhammer's audio/video decoder capability information into the device capability report of Yip, so that the encoding terminal can select an encoding format compatible with the decoder capabilities signaled to, and confirmed by, the server.
Regarding claim 11, this claim recites limitations substantially identical to those of claim 4, differing only in that it depends from claim 8 (a video encoding method) rather than claim 1 (a video decoding method). The combination of Yip and Stockhammer discloses each of these limitations, and is combinable to arrive at each of these limitations, for the same reasons discussed above with respect to claim 4, which discussion is incorporated herein by reference.
Regarding claim 15, Yip discloses a method for processing visual media data, performed by at least one processor (see FIGS. 10-11), comprising performing a conversion between a visual media file and a bitstream of visual media data according to a format rule (see FIG. 12, operations 1201-1207, disclosing that a format associated with the 3D media data is determined based on the capabilities of the first terminal, and that the pre-processed 3D media data is encoded before being transmitted to the second terminal, i.e., converted between a file format and an encoded bitstream according to the determined format rule), the format rule indicating to: determine capabilities of an augmented reality (AR) device (Yip, FIG. 5, operations 501 and 505; FIG. 12, operation 1210); obtain AR data comprising a media component of at least one of audio and video based on a request signaling the capabilities of the AR device to a server providing the AR data (Yip, FIG. 5, operations 507-508); and process the AR data based on the capabilities of the AR device signaled to the server, performed by the same first terminal that identified its capabilities and obtained the AR data (Yip, FIG. 12, operations 1220-1240, disclosing that the first terminal pre-processes and formats the 3D media data according to the format determined for the established session).
However, Yip does not explicitly disclose that the capabilities indicate any of an audio encoder or decoder of the AR device and a video encoder or decoder of the AR device.
As discussed above with respect to claim 1, Stockhammer discloses a client device whose capabilities are represented, in part, by its own audio decoder and video decoder (FIG. 1, audio decoder 46 and video decoder 48), with content selected based on "codecs supported by decoders of constrained device 288... audio codec and rendering capabilities" (¶ 255). Therefore, for the same reasons discussed above with respect to claim 1, it would have been obvious to a PHOSITA to incorporate Stockhammer's audio/video decoder capability information into the format rule/device capability report of Yip, in order to ensure that the format rule governing the file-to-bitstream conversion is compatible with the codec capabilities of the specific requesting AR device.
Claim(s) 2-3, 5-7, 9-10, 12-14 and 16-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Yip, in view of Stockhammer, and further in view of 3GPP Technical Report TR 26.998, "Support of 5G glass-type Augmented Reality/Mixed Reality (AR/MR) devices," published as ETSI TR 126 998 V17.1.0 (2022-10) ("TR 26.998" hereinafter).
Regarding claim 2, Yip in view of Stockhammer discloses the method of claim 1, and further discloses that a device may be specified using a syntax or identifier associated with the UE (see FIG. 4 and par. 116, disclosing device identifiers such as "UE1:camera1:vision" and "UE1:phone:rendering," and disclosing that a service entry point transmitted to the UE may include identification information, e.g., an address, of a data network accessible by the UE).
In the same field of endeavor, TR 26.998 further discloses that AR devices are classified into distinct device types, including a "5G Standalone AR (STAR) UE," a "5G EDGe-Dependent AR (EDGAR) UE," a "5G WireLess Tethered AR UE (WLAR)," and a "5G Wired Tethered AR UE (WTAR)" (see clause 4.2.2.1 and Table 4.2.2.1-1, "5G Augmented Reality device types," listing a "Device Type Name" column), and discloses that a session may be initialized using an entry point that "may for example be a URL to a scene description" (see clause 4.3.1, operation 2a).
Therefore, it would have been obvious to a PHOSITA to combine the URL/URI-based entry-point identifier of Yip with the device-type classification of TR 26.998, to form a URI-based profile identifier comprising a "deviceType" syntax, in order to allow the server to efficiently identify the general capability class of the requesting AR device without individually parsing a full capability list, consistent with TR 26.998's express goal of creating a higher degree of interoperability between application providers, content creators, and manufacturers by consolidating the media capabilities of AR-capable devices into a handful of well-defined device categories.
Regarding claim 3, the combination of Yip, Stockhammer, and TR 26.998 discloses the method of claim 2. TR 26.998 further discloses that the device-type classification directly reflects, for each device type, the placement and capability of the AR Runtime and the Scene Manager (see clause 4.2.2.1 and Table 4.2.2.1-1, listing "AR Runtime" and "Scene Manager" columns for each device type, e.g., disclosing that a STAR UE has both the AR Runtime and the Scene Manager located on the glass, whereas an EDGAR UE has a split Scene Manager), and further discloses that the AR Runtime performs system capability discovery while the Scene Manager "is able to understand the capabilities of the underlying hardware and system, to appropriately adjust the scene complexity and rendering process" (see clause 4.2.4, 3rd paragraph).
Therefore, for the same reasons discussed above with respect to claim 2, it would have been obvious to a PHOSITA to configure the deviceType profile identifier to indicate XR runtime and scene manager capabilities, since TR 26.998 defines each device type precisely in terms of the placement and capability of these two components.
Regarding claim 5, the combination of Yip and Stockhammer discloses the method of claim 4, but does not disclose wherein the at least some of the capabilities of the AR device further indicating a number of instances of and interfaces of the optional codecs of the AR device, extended reality (XR) runtime profiles, optional extensions, a scene description format, and a profile supported by the scene description format.
TR 26.998 further discloses that multiple instances of a codec, and their interfaces, may be needed and coordinated on a single device (see clause 4.2.6, "In several cases, not only a single instance of a codec per media type is needed, but multiple ones," and clause 4.4.2, referencing the MPEG-I Video Decoding Interface, ISO/IEC 23090-13, for coordinating multiple media decoder instances), and further discloses that AR content is described using a scene description format, specifically glTF 2.0 or its extension, the MPEG Scene Description (ISO/IEC 23090-14), which is itself an extension, i.e., a profile, of the base glTF 2.0 format (see clause 4.4.2, "MPEG Scene description is an extension of glTF2.0.... MPEG_media and MPEG_scene_description are the major changes to provide support of media access link including manifest, and temporal update of the scene description itself").
Therefore, it would have been obvious to a PHOSITA to further include, within the capability list of claim 4, the number of codec instances and interfaces, together with an indication of the supported scene description format and its supported profile, as taught by TR 26.998, for the same reasons discussed above with respect to claim 4, namely, so that the server can select content that is properly formatted and structured for decoding and rendering on the specific requesting device.
Regarding claim 6, the combination of Yip, Stockhammer, and TR 26.998 discloses the method of claim 5. As discussed above with respect to claim 2, the combination discloses a URI-based profile identifier comprising a "deviceType" syntax. Yip further discloses that structured capability data is represented using descriptive, camel-case syntax labels for each parameter group (see FIG. 6 and accompanying description, disclosing syntax labels such as "SpaceSetSizeStruct()," "VisionSubSpaceStruct()," and "CaptureSubSpaceStruct()" for representing structured capability-related parameter groups). Therefore, it would have been obvious to a PHOSITA, as a matter of routine design choice consistent with the labeling conventions already used in Yip, to designate the list of optional codecs, codec instances/interfaces, XR runtime profiles, extensions, and scene description format/profile of claim 5 using a descriptive syntax label such as "deviceDetailedCapabilities," since selecting a particular, functionally arbitrary name for an otherwise-taught data structure would have been well within the level of ordinary skill and does not patentably distinguish the claimed data structure from that taught by the combination of Yip, Stockhammer, and TR 26.998.
Regarding claim 7, the combination of Yip, Stockhammer, and TR 26.998 discloses the method of claim 6. As discussed above with respect to claim 3, TR 26.998 discloses that the deviceType profile identifier itself indicates XR runtime and scene manager capabilities (e.g., via Table 4.2.2.1-1's "AR Runtime" and "Scene Manager" columns), which is distinct from, and does not duplicate, the more granular codec- and format-level capability list of claim 6 (e.g., the codec, codec instance/interface, XR runtime profile, extension, and scene description format/profile information of clause 4.2.6 and clause 4.4.2). Therefore, for the reasons discussed above with respect to claims 3 and 6, it would have been obvious to a PHOSITA to configure the profile identifier to indicate XR runtime and scene manager capabilities other than the detailed capabilities separately reported in the "deviceDetailedCapabilities" list, consistent with TR 26.998's two-tier disclosure of a general, device-type-level indication of AR Runtime/Scene Manager placement, together with a separate, more granular reporting of codec- and format-level capabilities.
Regarding claims 9-10 and 12-14, these claims recite limitations substantially identical to those of claims 2-3 and 5-7, respectively, differing only in that they depend from claim 8 (a video encoding method) rather than claim 1 (a video decoding method). The combination of Yip, Stockhammer, and TR 26.998 discloses each of these limitations, and is combinable to arrive at each of these limitations, for the same reasons discussed above with respect to claims 2-3 and 5-7, respectively, which discussion is incorporated herein by reference.
Regarding claim 16, the combination of Yip, Stockhammer, and TR 26.998 discloses the method of claim 15. For the same reasons discussed above with respect to claim 2, it would have been obvious to a PHOSITA to configure the request signaling the capabilities of the AR device to comprise a profile identifier in the form of a URI comprising a syntax of "deviceType," in view of Yip's disclosure of URL/URI-based service entry points (FIG. 4; FIG. 5, operation 508) combined with TR 26.998's disclosure of device-type classifications (clause 4.2.2.1 and Table 4.2.2.1-1) and TR 26.998's express motivation of consolidating AR device capabilities into well-defined device categories for interoperability.
Regarding claim 17, the combination of Yip, Stockhammer, and TR 26.998 discloses the method of claim 16. For the same reasons discussed above with respect to claim 3, TR 26.998's device-type classification directly reflects the placement and capability of the AR Runtime and the Scene Manager for each device type (clause 4.2.2.1 and Table 4.2.2.1-1; clause 4.2.3; clause 4.2.4), rendering it obvious to a PHOSITA to configure the profile identifier to indicate XR runtime and scene manager capabilities.
Regarding claim 18, the combination of Yip, Stockhammer, and TR 26.998 discloses the method of claim 17. For the same reasons discussed above with respect to claim 4, it would have been obvious to a PHOSITA to configure the request signaling the capabilities of the AR device to further comprise a list of at least some of the capabilities of the AR device indicating optional codecs of the AR device, in view of Stockhammer's disclosure of content selection based on "codecs supported by decoders of constrained device 288" (¶ 255) and TR 26.998's disclosure that the Media Access Function's codecs may include multiple, optionally required instances depending on device type and use case (clause 4.2.6).
Regarding claim 19, the combination of Yip, Stockhammer, and TR 26.998 discloses the method of claim 15. For the same reasons discussed above with respect to claim 5, it would have been obvious to a PHOSITA to configure the at least some of the capabilities of the AR device to further indicate a number of instances of and interfaces of the optional codecs of the AR device, extended reality (XR) runtime profiles, optional extensions, a scene description format, and a profile supported by the scene description format, in view of TR 26.998's disclosure of multiple, coordinated codec instances (clause 4.2.6 and clause 4.4.2, citing the MPEG-I Video Decoding Interface, ISO/IEC 23090-13) and its disclosure of the glTF 2.0 scene description format and its MPEG Scene Description (ISO/IEC 23090-14) extension/profile (clause 4.4.2).
Regarding claim 20, the combination of Yip, Stockhammer, and TR 26.998 discloses the method of claim 19. For the same reasons discussed above with respect to claims 6 and 7, it would have been obvious to a PHOSITA to further configure the request signaling the capabilities of the AR device to comprise a profile identifier in the form of a URI comprising a syntax of "deviceType," and a syntax indicating the list of the at least some of the capabilities is "deviceDetailedCapabilities," and to configure the profile identifier to indicate XR runtime and scene manager capabilities other than the at least some of the capabilities of the AR device, in view of the combined teachings of Yip (FIG. 4; FIG. 6 syntax-labeling conventions) and TR 26.998 (Table 4.2.2.1-1's device-type-level AR Runtime/Scene Manager indication, separate from the more granular codec/scene-description capability list of clause 4.2.6 and clause 4.4.2), for the reasons discussed above.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to PHONG X NGUYEN whose telephone number is (571)270-1591. The examiner can normally be reached Mon-Fri 8am - 5pm EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, King Poon can be reached at (571)272-7440. 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.
/PHONG X NGUYEN/ Primary Patent Examiner, Art Unit 2617
Prosecution Insights