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 .
Continued Examination under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 05/26/2026 has been entered.
Response to Amendment
This communication is considered fully responsive to the amendment filed on 4/21/2026.
Claims 1, 12, and 20 have been amended.
Claims 1-20 are pending in this application.
Response to Arguments
Applicant’s arguments with respect to claims 1-20 filed on 4/21/2026 have been considered but are moot because the arguments related solely to newly added limitations addressed in the instant Office Action with previously identified prior art, Sodagar (U.S. Patent Application Publication No. 20220182435, which incorporates 3GPP TS 26.238 V16.2.0 (2019-09), “3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Uplink Streaming (Release 16)” by reference in its entirety, hereinafter collectively referred to as ”Sodagar”) by mapping the relevant teachings for more clarification thereof that read on said added feature are moot.
With regard to Claim 1, amended claim 1 recites the limitation of “receiving, by one or more network devices, a request from a user equipment (UE) device to register a remote camera device with a core network, wherein the remote camera device is independent of the UE device, the remote camera device having a connection to the core network that is separate from the UE device”.
Applicant argues that Sodagar (U.S. Patent Application Publication No. 20220182435, hereinafter “Sodagar”) merely discloses a remote camera connected to a UE, wherein the UE acts as a conduit to the core network, and thus fails to teach “the remote camera device having a connection to the core network that is separate from the UE device.”
While Applicant’s characterization of Sodagar is noted, Applicant’s interpretation overlooks the explicit incorporation by reference within the Sodagar reference itself. Specifically, paragraph [0027] of Sodagar expressly states: “3GPP has also developed a standard specifying a framework for live uplink streaming (FLUS): 3GPP TS 26.238, Uplink Streaming (version 16.2.0, Release 16). This FLUS standard is incorporated by reference herein in its entirety. The FLUS provides an uplink streaming in a 5G network for multimedia telephony service for IP multimedia subsystem (MIST) and non-MISI terminals.” Under MPEP 2127, material incorporated by reference is considered part of the host document. Therefore, the disclosures of 3GPP TS 26.238 V16.2.0 (2019-09) are legally considered part of the teaching of Sodagar.
Looking at the incorporated 3GPP TS 26.238 document, it explicitly discloses a deployment architecture where a Control Source (‘controlling UE’) and a Media Source (‘the remote camera device’) are deployed on separate, stand-alone devices. Crucially, TS 26.238 teaches an architecture where the network connections for session control and media streaming are physically and logically separated into distinct devices. Specifically, Annex A.1.3 of 3GPP TS 26.238, titled “Deployment with non-colocated Control Source and Media Source,” describes a scenario where the Control Source and the Media Source are “implemented in different functional entities” and can be “remotely located” from each other. In this non-colocated architecture, the controlling UE device (referred to in 3GPP TS 26.238 as the “CTRL entity”) manages the control plane (F-C) connection to establish and terminate the FLUS session. Meanwhile, the independent remote camera device (i.e., the capture device containing the Media Source) maintains its own distinct user plane (F-U) connection directly to the FLUS sink. (See page 40 of 3GPP TS 26.238 and Figure A.1.3-1: Deployment with minimal FLUS sub-functions.) Figure A.1.3-1 of 3GPP TS 26.238 is reproduced herein below.
PNG
media_image1.png
526
1357
media_image1.png
Greyscale
3GPP TS 26.238 establishes that the FLUS sink is located at the SGi reference point for EPS and at the N6 reference point for 5GS. Because the SGi and N6 reference points serve as the gateways into the core network, the remote Media Source necessarily streams its uplink media data directly to the core network. Therefore, by separating the F-C and F-U connections across different functional entities, 3GPP TS 26.238 explicitly establishes that the remote camera maintains a connection to the core network (via F-U) that is entirely separate from the UE device (which operates via F-C). (See pages 10-11 of 3GPP TS 26.238: Uplink streaming for PSS-based distribution.).
Therefore, Sodagar-by way of its explicit incorporation of 3GPP TS 26.238 in its entirety-expressly point to and incorporates a remote camera device that is both independent of the UE and possesses an uplink connection to the core network that is entirely separate from the UE device. As articulated in the rejection above, an ordinary skill artisan would have been highly motivated to apply this non-colocated, stand-alone architecture of 3GPP TS 26.238, as explicitly suggested by Sodagar itself, to enable autonomous, direct-to-network streaming from remote cameras, thereby avoiding the need to tether heavy video data through a local user equipment device.
Regarding “registering, by the one or more network devices, the remote camera device with the core network;” and “assigning, by the one or more network devices, the remote camera device to a subscription of the UE device registered with the core network such that the remote camera device shares the subscription of the UE device”, Sodagar teaches that the 5GMS architecture supports Mobile Network Operator (MNO) services, which implies an underlying UE network subscription (see para [0005] of Sodagar). In Sodagar, Sodagar discloses that:
[0005] The 3rd Generation Partnership Project (3GPP) has developed standards for a 5G media streaming (5GMS) architecture. The 5GMS architecture can support services that include mobile network operator (MNO) and third-party downlink and uplink media streaming services. The 5GMS architecture provides related network and user equipment (UE) functions and APIs.
[0160] In another example, the 5GMS AF provides an address of the FLUS source and an NBMP WDD corresponding to the network-based media processing to the FLUS sink. ...
[0162] a 5GMS aware application at a UE can request for instantiation of an NBMP workflow for the network-based media processing through FLUS source…
[170] At (S910), a configuration for network-based media processing can be received at the FLUS sink from the 5GMS AF.
As reproduced above, Sodagar teaches the one or more network device (e.g., 5GMS AF) configuring the core network by providing an address of the FLUS source to the FLUS sink and configuring the FLUS sink for media processing (Sodagar, paras [0160], [0170]). Sodagar explicitly teaches that a “5GMS aware application at a UE can request for instantiation of an NBMP workflow for the network-based media processing through FLUS source” (see para [0162] of Sodagar).
FIG. 3 of Sodagar shows an example of a 5GMS system (300). The system (300) includes a user equipment (UE) (301) and data network (DN) (302) (see Fig. 3 and para [0063]). In Fig. 3 and paragraphs [0065-0079], Sodagar discloses that “M5 (Media Session Handling API): APIs exposed by the 5GMS AF (340) to the media session handler (321) for media session handling, control and assistance that also include appropriate security mechanisms (e.g. authorization and authentication (interpreted as “subscription of the UE”), and QoE metrics reporting).
Further, the incorporated 3GPP TS 26.238 explicitly teaches that the FLUS source (remote camera) proceeds to register with the network-side control function (see 3GPP TS 26.238: 4.5.6 Media production FLUS source system). Clause 4.5.6. of 3GPP TS 26.238 is reproduced herein below.
4.5.6 Media production FLUS source system
In the media production use case for FLUS, typically it is the media production centre that controls the FLUS source devices that deliver media streams for the media production process. The media production centre typically is located "behind" the FLUS sink, on the network side and not shown in the system architecture. The FLUS sink acts as a Media Gateway Function. The Remote Controller function acts as proxy of the media production centre for the control of the FLUS source devices.
When a FLUS source is set up and prepared for an event, it proceeds, either by manual trigger or autonomously, to register with the Remote Controller function and the media production centre. Once a FLUS source is known to the media production center, the media production centre can take full control of that device and the FLUS sessions. This includes the initiation, adaptation and termination of FLUS sessions.
(pages 18-19 of 3GPP TS 26.238)
Under the Broadest Reasonable Interpretation (BRI), because the application on the registered UE dictates and requests the network-based media processing for the separate FLUS source (remote camera), the network device (e.g., 5GMS AF) effectively associates and assigns the remote camera’s media session to the UE’s authorized service profile/subscription. By allowing the remote camera to stream media under the authorization and workflow requested by the UE device’s application, the network assigns the remote camera device to the UE’s subscription such tat the remote camera shares the UE’s authorized subscription context for the media session.
Thus, the combination of Sodagar and 3GPP TS 26.238 explicitly teaches “registering, by the one or more network devices, the remote camera device with the core network;” and “assigning, by the one or more network devices, the remote camera device to a subscription of the UE device registered with the core network such that the remote camera device shares the subscription of the UE device”.
With regard to Claim 7, Applicant’s arguments regarding Yuan have been fully considered and are persuasive. Consequently, the reliance on Yuan for this limitation has been withdrawn. However, the rejection of claim 7 is maintained because the limitation of claim 7 are expressly taught by Sodagar in view of its incorporated reference, 3GPP TS 26.238.
Claim 7 requires the destination device to include a video management system that receives an instruction from the UE device to perform a control action for a video stream associated with the data flow from the remote camera device, and performs the control action.
Sodagar, incorporating 3GPP TS 26.238 by reference in its entirely, explicitly teaches a destination device (i.e., the FLUS sink) acting as a video management system. Specifically, 3GPP TS 26.238, Clause 4.2.1, discloses that when the FLUS sink is located in the network, it may forward media content to processing sub-functions and “act as a Media Gateway Function (MGW) and/or an Application Function (AF)” (see page 8 of 3GPP TS 26.238, 4.2.1 General). This network-based processing entity corresponds to the claimed “video management system.”
Furthermore, the combination explicitly teaches the video management system receiving an instruction from the UE device to perform a control action for the video streams. 3GPP TS 26.238 defines a control Source (located at the UE/CTRL entity) that communicates with a Control Sink (at the FLUS sink) via the F-C (FLUS Control) interface. Clause 4.2.1 of 3GPP TS 26.238 teaches that “F-C represents the interactions associated with the creation and modification of the configuration of the FLUS sink” and allows the UE’s Control Source to “discover, select and configure the processing and distribution sub-functions”. Annex A.1.3 of 3GPP TS 26.238 further confirms that a human operator using the UE device (CTRL entity) “causes the Control Source function to establish and control the FLUS session” via these explicit control instructions (see page 40 of 3GPP TS 26.238, A.1.3 Deployment with non-colocated Control Source and Media Source).
In addition, Sodagar explicitly provides an example of this UE-issued control instruction. Sodagar, in para [0162], discloses that a “5GMS aware application at a UE can request for instantiation of an NBMP workflow for the network-based media processing through FLUS source.” Sodagar further teaches that, in response to receiving this explicit request (instruction) from the UE, the FLUS sink (video management system) “can instantiate the NBMP workflow” to process the received media components (performing the control action). See page 40 of 3GPP TS 26.238 and Figure A.1.3-1: Deployment with minimal FLUS sub-functions.) Figure A.1.3-1 of 3GPP TS 26.238 is reproduced herein below.
PNG
media_image1.png
526
1357
media_image1.png
Greyscale
Therefore, Sodagar, through its own disclosures and its explicit incorporation of 3GPP TS 26.238, clearly teaches “receiving, by the video management system, an instruction from the UE device to perform a control action for a video stream associated with the data flow from the remote camera device; and performing, by the video management system, the control action” as recited in claim 7
Accordingly, the rejection of claim 7 is maintained under 35 U.S.C. 103 over Sodagar (which incorporates 3GPP TS 26.238 by reference in its entirety) in view of Kamdar.
With regard to Claim 8, Applicant’s arguments regarding Yuan have been fully considered and are persuasive. Consequently, the reliance on Yuan for this limitation has been withdrawn. However, the rejection of claim 8 is maintained because the limitation of claim 8 are expressly taught by Sodagar in view of its incorporated reference, 3GPP TS 26.238.
Claim 7 requires that performing the control action includes combining a plurality of uplink video streams associated with a plurality of camera devices into a combined video stream.
3GPP TS 26.238, which is incorporated by reference in its entirety by Sodagar, explicitly discloses media processing capabilities at the destination device (FLUS sink) that includes the combination of multiple media streams into a single combined stream. Specifically, Clause 4.4.4 of 3GPP TS 26.238 discloses that “Combination of input media streams, e.g. network based stitching, mixing” (see page 13 of 3GPP TS 26.238, 4.4.4. FLUS sink capability discovery).
Therefore, Sodagar, through its own disclosures and its explicit incorporation of 3GPP TS 26.238, clearly teaches “combining a plurality of uplink video streams associated with a plurality of remote camera devices into a combined video stream” as recited in claim 8.
Accordingly, the rejection of claim 8 is maintained under 35 U.S.C. 103 over Sodagar in view 3GPP TS 26.238 and Kamdar.
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, 2-4, 6-8, 12-18, and 20 rejected under 35 U.S.C. 103 as being unpatentable over Sodagar (U.S. Patent Application Publication No. 20220182435, which incorporates 3GPP TS 26.238 V16.2.0 (2019-09), “3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Uplink Streaming (Release 16)” by reference in its entirety, hereinafter collectively referred to as ”Sodagar”) in view of Kamdar et al. (U.S. Patent Application Publication No. 20120099428, hereinafter “Kamdar”).
Examiner’s note: in what follows, references are drawn to Sodagar unless otherwise mentioned.
With respect to independent claims:
Regarding claim 1, A method comprising:
receiving, by one or more network devices, a request from a user equipment (UE) device to register a remote camera device with a core network(para [0111]: In an example, the FLUS source (410) receives media content from one or more capture devices (460). The capture devices (460) can be parts of the UE (401) or connected to the UE (401).) (Fig. 7 and para [0161]: At (S740), a FLUS session can be established by the FLUS source with the FLUS sink. In an example, a 5GMS aware application at a UE can request for instantiation of an NBMP workflow for the network-based media processing through FLUS source (the FLUS source is interpreted as “a remote camera”).), wherein the remote camera device is independent of the UE device, (para [0108]: A FLUS source entity and a FLUS sink entity can support the point-to-point transmission of speech/audio, video, and text by media handling (e.g., signaling, transport, packet-loss handling, and adaptation). FLUS can provide a reliable and interoperable service with a predictable media quality while allowing for flexibility in the service offerings. A FLUS source entity, (interpreted as “a remote camera”) which may be embedded in a single UE, or distributed among a UE and separate audio-visual capture devices (interpreted as “the remote camera device is independent of the UE device”), may support all or a subset of the features specified in this document.),
the remote camera device having a connection to the core network that is separate from the UE device; Looking at the incorporated 3GPP TS 26.238 document (hereafter “3GPP TS 26.238), it explicitly discloses a deployment architecture where a Control Source (‘controlling UE’) and a Media Source (‘the remote camera device’) are deployed on separate, stand-alone devices. Crucially, TS 26.238 teaches an architecture where the network connections for session control and media streaming are physically and logically separated into distinct devices. Specifically, Annex A.1.3 of 3GPP TS 26.238, titled “Deployment with non-colocated Control Source and Media Source,” describes a scenario where the Control Source and the Media Source are “implemented in different functional entities” and can be “remotely located” from each other. In this non-colocated architecture, the controlling UE device (referred to in 3GPP TS 26.238 as the “CTRL entity”) manages the control plane (F-C) connection to establish and terminate the FLUS session. Meanwhile, the independent remote camera device (i.e., the capture device containing the Media Source) maintains its own distinct user plane (F-U) connection directly to the FLUS sink. (See page 40 of 3GPP TS 26.238 and Figure A.1.3-1: Deployment with minimal FLUS sub-functions.) Figure A.1.3-1 of 3GPP TS 26.238 is reproduced herein below.
PNG
media_image1.png
526
1357
media_image1.png
Greyscale
Furthermore, 3GPP TS 26.238 establishes that the FLUS sink is located at the SGi reference point for EPS and at the N6 reference point for 5GS. Because the SGi and N6 reference points serve as the gateways into the core network, the remote Media Source necessarily streams its uplink media data directly to the core network. Therefore, by separating the F-C and F-U connections across different functional entities, 3GPP TS 26.238 explicitly establishes that the remote camera maintains a connection to the core network (via F-U) that is entirely separate from the UE device (which operates via F-C). (See pages 10-11 of 3GPP TS 26.238: Uplink streaming for PSS-based distribution.)
registering, by one or more network devices, the remote camera device with the core network; (para [0005]: The 3rd Generation Partnership Project (3GPP) has developed standards for a 5G media streaming (5GMS) architecture. The 5GMS architecture can support services that include mobile network operator (MNO) and third-party downlink and uplink media streaming services. The 5GMS architecture provides related network and user equipment (UE) functions and APIs.) (para [0160]: the 5GMS AF (interpreted as “one or more network devices”) provides an address of the FLUS source and an NBMP WDD corresponding to the network-based media processing to the FLUS sink. However, no instantiation of an NBMP workflow for the network-based media processing is performed at the FLUS sink.) (para [0162]: At (S740), a FLUS session can be established by the FLUS source with the FLUS sink. In an example, a 5GMS aware application at a UE can request for instantiation of an NBMP workflow for the network-based media processing through FLUS source. In response to receiving the request from the FLUS source, the FLUS sink can instantiate the NBMP workflow based on the NBMP WDD (interpreted as “registering, by one or more network devices, the remote camera device with the core network”).);
assigning, by the one or more network devices, the remote camera device to a subscription of the UE device registered with the core network such that the remote camera device share the subscription of the UE device;
Sodagar teaches that the 5GMS architecture supports Mobile Network Operator (MNO) services, which implies an underlying UE network subscription (see para [0005] of Sodagar). In Sodagar, Sodagar discloses that:
[0005] The 3rd Generation Partnership Project (3GPP) has developed standards for a 5G media streaming (5GMS) architecture. The 5GMS architecture can support services that include mobile network operator (MNO) and third-party downlink and uplink media streaming services. The 5GMS architecture provides related network and user equipment (UE) functions and APIs.
[0160] In another example, the 5GMS AF provides an address of the FLUS source and an NBMP WDD corresponding to the network-based media processing to the FLUS sink. ...
[0162] a 5GMS aware application at a UE can request for instantiation of an NBMP workflow for the network-based media processing through FLUS source…
[170] At (S910), a configuration for network-based media processing can be received at the FLUS sink from the 5GMS AF.
As reproduced above, Sodagar teaches the one or more network device (e.g., 5GMS AF) configuring the core network by providing an address of the FLUS source to the FLUS sink and configuring the FLUS sink for media processing (Sodagar, paras [0160], [0170]). Sodagar explicitly teaches that a “5GMS aware application at a UE can request for instantiation of an NBMP workflow for the network-based media processing through FLUS source” (see para [0162] of Sodagar).
FIG. 3 of Sodagar shows an example of a 5GMS system (300). The system (300) includes a user equipment (UE) (301) and data network (DN) (302) (see Fig. 3 and para [0063]). In Fig. 3 and paragraphs [0065-0079], Sodagar discloses that “M5 (Media Session Handling API): APIs exposed by the 5GMS AF (340) to the media session handler (321) for media session handling, control and assistance that also include appropriate security mechanisms (e.g. authorization and authentication (interpreted as “subscription of the UE”), and QoE metrics reporting).
Further, the incorporated 3GPP TS 26.238 explicitly teaches that the FLUS source (remote camera) proceeds to register with the network-side control function (see 3GPP TS 26.238: 4.5.6 Media production FLUS source system). Clause 4.5.6. of 3GPP TS 26.238 is reproduced herein below.
4.5.6 Media production FLUS source system
In the media production use case for FLUS, typically it is the media production centre that controls the FLUS source devices that deliver media streams for the media production process. The media production centre typically is located "behind" the FLUS sink, on the network side and not shown in the system architecture. The FLUS sink acts as a Media Gateway Function. The Remote Controller function acts as proxy of the media production centre for the control of the FLUS source devices.
When a FLUS source is set up and prepared for an event, it proceeds, either by manual trigger or autonomously, to register with the Remote Controller function and the media production centre. Once a FLUS source is known to the media production center, the media production centre can take full control of that device and the FLUS sessions. This includes the initiation, adaptation and termination of FLUS sessions.
(pages 18-19 of 3GPP TS 26.238)
Under the Broadest Reasonable Interpretation (BRI), because the application on the registered UE dictates and requests the network-based media processing for the separate FLUS source (remote camera), the network device (e.g., 5GMS AF) effectively associates and assigns the remote camera’s media session to the UE’s authorized service profile/subscription. By allowing the remote camera to stream media under the authorization and workflow requested by the UE device’s application, the network assigns the remote camera device to the UE’s subscription such that the remote camera shares the UE’s authorized subscription context for the media session.
Thus, the combination of Sodagar and 3GPP TS 26.238 explicitly teaches “registering, by the one or more network devices, the remote camera device with the core network;” and “assigning, by the one or more network devices, the remote camera device to a subscription of the UE device registered with the core network such that the remote camera device shares the subscription of the UE device”.
assigning, by the one or more network devices, the remote camera device to an uplink streaming network slice (para [0151]: In a second scenario corresponding to the second case at (S620), the FLUS sink (604) is configured, and resources for media processing has been assigned. However, no NBMP workflow is instantiated. In this scenario, while establishing the session with the FLUS sink (604), the FLUS source (602) may request for instantiation of an NBMP workflow. AN NBMP WDD can be included in the request. In response, the FLUS sink (604) may instantiate the NBMP workflow based on the received NBMP WDD (interpreted as “assigning, by the one or more network devices, the remote camera device to an uplink streaming network slice”, the instantiation of an NBMP workflow is interpreted as “an uplink streaming network slice” ) in response to receiving a request from the FLUS source.).);
assigning, by the one or more network devices, an uplink streaming video Quality of Service (QOS) class to a data flow sent from the remote camera device to the core network (para [0101]: The 5GMS AF (340) (interpreted as “one or more network devices”) can coordinate the media processing and ensures that the appropriate QoS and traffic handling for the session are provided (interpreted as “an uplink streaming video Quality of Service (QOS) class to a data flow sent from the remote camera device to the core network”).), wherein the uplink streaming video QoS class is configured to provide a guarantee for at least one video streaming QoS parameter (Examiner’s note: the missing/crossed out limitations will be discussed in view of Kamdar); and.
establishing, by the one or more network devices, the data flow from the remote camera device to a destination device via the uplink streaming network slice based on the uplink streaming video QoS class (para [0171]: At (S920), a FLUS session can be established between a FLUS source at a UE and the FLUS sink in response to receiving a request from the FLUS source.)(para [0063]: For uplink streaming, the UE (301) is an origin of the media, and the DN (302) acts as the consumption entity (interpreted as “a destination device”) (para [0101]: The 5GMS AF (340) can coordinate the media processing and ensures that the appropriate QoS and traffic handling for the session are provided (interpreted as “based on the uplink streaming video QoS class”).).
Sodagar does not explicitly teach the “wherein the uplink streaming video QoS class is configured to provide a guarantee for at least one video streaming QoS parameter”.
In analogous art, Kamdar discloses that, in para [0023] of Kamdar: LTE network 130 may include a core network architecture of the Third Generation Partnership Project (3GPP) LTE wireless communication standard (e.g., an evolved packet core (EPC) network). In para [0024] of Kamdar: LTE network 130 may prioritize traffic based on LTE QoS class identifiers (QCIs). … For example, in one implementation, LTE network 130 may use 9 different QoS classes, such as a voice QoS class, a video telephony QoS class, a video streaming QoS class, a real-time gaming QoS class, an application signaling QoS class, a first third party hosted application QoS class, a second third party hosted application QoS class, a premium access Internet traffic QoS class, and a best effort Internet traffic QoS class. Each QoS class may be associated with a different priority.).
Kamdar disclose the above recited missing feature “wherein the uplink streaming video QoS class guarantees at least one video streaming QoS parameter” (para [0024] of Kamdar: For example, QoS classes associated with real-time data delivery, such as voice, video telephony, and/or video streaming may be given a higher priority (interpreted as “a guarantee at least one video streaming QoS parameter”) than QoS classes associated with data transfer, such as a premium access Internet traffic QoS class or a best effort Internet traffic QoS class (interpreted as “wherein the uplink streaming video QoS class guarantees at least one video streaming QoS parameter”).)(para [0064] of Kamdar: DSCP QoS class queues 550 may store packets that are to be sent to a particular device in customer network 110. Packets may be forwarded from a particular DSCP QoS class queue 550 based on a priority associated with the particular DSCP QoS class with which the packets are associated.).
Sodagar and Kamdar are considered analogous art as they all pertain to wireless network provisioning, media streaming, and quality of service (QoS) management. It would have been obvious to a person of ordinary skill in the art at the time the invention was made to modify the system of Sodagar (which natively includes the stand-alone remote camera architecture via its explicit incorporation of 3GPP TS 26.238) by incorporating the specific video streaming QoS guarantees of Kamdar and subscription sharing mechanism of GSMA TS.43. The motivation for this modification would be to ensure that the autonomous, direct-to-network uplink video streams established by the remote camera receive reliable, high-priority real-time QoS treatment without packet loss or jitter, thereby optimizing the network -based media processing workflows taught by Sodagar.
Regarding claim 12, it is a system claim corresponding to the method claim 1, except limitations “one or more devices” (Figures. 3-5) and is therefore rejected for the similar reasons set forth in the rejection of claim 1.
Regarding claim 20, it is a non-transitory computer-readable memory device claim corresponding to the method claim 1, except limitations “A non-transitory computer-readable memory device storing instructions executable by a processor” (para [0012]: In an aspect, a non-transitory computer-readable medium storing computer-executable instructions includes computer-executable instructions …) and is therefore rejected for the similar reasons set forth in the rejection of claim 1.
With respect to dependent claims:
Regarding claim 2, Sodagar and Kamdar teach The method of claim 1, further comprising:
Kamdar further teaches establishing, in the uplink streaming network slice, another data flow from the destination device to a downlink UE device, wherein the other data flow is assigned to a downlink streaming QoS class (para [0020] of Kamdar: Customer premises network 110 (interpreted as “destination device”) may include a combined gateway 120 and one or more devices connected to each other at a particular location serviced by combined gateway 120. Devices in customer premise network 110 may include, for example, set-top boxes (STBs), televisions, computers, voice-over-Internet-protocol (VoIP) devices, home networking equipment (e.g., routers, cables, splitters, local gateways, etc.) (interpreted as “a downlink UE device”), etc.) (para [0022] of Kamdar: Customer premises network 110 may prioritize traffic based on particular QoS classes associated with particular packets based on a type of traffic (interpreted as “assigned to a downlink streaming QoS class”)...).
Regarding claim 3, Sodagar and Kamdar teach The method of claim 1, further comprising:
Sodagar incorporating with 3GPP TS 26.238 discloses registering another remote camera device with the core network; assigning the other remote camera device to the subscription associated with the UE device; (para [0005]: The 5GMS architecture can support services that include mobile network operator (MNO) and third-party downlink and uplink media streaming services. The 5GMS architecture provides related network (interpreted as “core network”) and user equipment (UE) functions and APIs.) (para [0162]: a 5GMS aware application at a UE can request for instantiation of an NBMP workflow for the network-based media processing through FLUS source… ) (pages 18-19 of 3GPP TS 26.238: 4.5.6 Media production FLUS source system, In the media production use case for FLUS, typically it is the media production centre that controls the FLUS source devices that deliver media streams for the media production process. The media production centre typically is located "behind" the FLUS sink, on the network side and not shown in the system architecture. The FLUS sink acts as a Media Gateway Function. The Remote Controller function acts as proxy of the media production centre for the control of the FLUS source devices. When a FLUS source is set up and prepared for an event, it proceeds, either by manual trigger or autonomously, to register with the Remote Controller function and the media production centre. Once a FLUS source is known to the media production center, the media production centre can take full control of that device and the FLUS sessions. This includes the initiation, adaptation and termination of FLUS sessions.); (page 13 of 3GPP TS 26.238: 4.4.4 FLUS sink capability discovery: Combination of input media streams, e.g. network based stitching, mixing” (interpreted as “registering another remote camera device with the core network” and “assigning the other remote camera device to the subscription associated with the UE device”)
Kamdar further teaches:
establishing another data flow from the other remote camera device to the destination device via the uplink streaming network slice based on the uplink streaming video QoS class (para [0020] of Kamdar: Customer premises network 110 (interpreted as “destination device”) may include a combined gateway 120 and one or more devices connected to each other at a particular location serviced by combined gateway 120. Devices in customer premise network 110 may include, for example, set-top boxes (STBs), televisions, computers, voice-over-Internet-protocol (VoIP) devices, home networking equipment (e.g., routers, cables, splitters, local gateways, etc.) (para [0022] of Kamdar: Customer premises network 110 (interpreted as “destination device”) may prioritize traffic based on particular QoS classes associated with particular packets based on a type of traffic. In one implementation, customer premises network 110 may use a QoS mechanism based on DSCP. DSCP may include a networking architecture that provides QoS guarantees in an IP network.); and
generating a downlink data flow from the destination device to a downlink UE device (para [0022] of Kamdar: BHR 330 may include one or more devices that buffer and forward data packets toward destinations. For example, BHR 330 may receive data packets from eNodeB 140 (e.g., via LTE module 320) and forward the data packets toward user devices 270 (interpreted as “a downlink data flow from the destination device to a downlink UE device”), wherein the downlink data flow combines video data from the data flow and the other data flow, and wherein the downlink data flow is assigned to a downlink streaming QoS class (para [0055] of Kamdar: As shown in FIG. 5, BHR 330 may include a router module 510, a Subscriber Identity Module (SIM) 520, a QoS manager 530, a QoS mapping table 540, one or more DSCP QoS class queues 550 (referred to collectively as “DSCP QoS class queues 550” and individually as “DSCP class queue 550” (interpreted as “combines video data from the data flow and the other data flow, and wherein the downlink data flow is assigned to a downlink streaming QoS class”)), and one or more LTE QoS class queues 560 (referred to collectively as “LTE QoS class queues 560” and individually as “LTE class queue 560”)).
Regarding claim 4, Sodagar and Kamdar teach The method of claim 1, Sodagar further teaches wherein the uplink streaming network slice enables a plurality of uplink video streams associated with a plurality of remote camera devices to be combined into a video stream controlled by the UE device (para [0162]: a 5GMS aware application at a UE can request for instantiation of an NBMP workflow for the network-based media processing through FLUS source… ) (pages 18-19 of 3GPP TS 26.238: 4.5.6 … The FLUS sink acts as a Media Gateway Function. The Remote Controller function acts as proxy of the media production centre for the control of the FLUS source devices. When a FLUS source is set up and prepared for an event, it proceeds, either by manual trigger or autonomously, to register with the Remote Controller function and the media production centre. Once a FLUS source is known to the media production center, the media production centre can take full control of that device and the FLUS sessions. This includes the initiation, adaptation and termination of FLUS sessions.); (page 13 of 3GPP TS 26.238: 4.4.4 FLUS sink capability discovery: Combination of input media streams, e.g. network based stitching, mixing” (the input media streams are interpreted as “a plurality of uplink video streams associated with a plurality of remote camera devices”).
Regarding claim 6, Sodagar and Kamdar teach The method of claim 1, further comprising:
Kamdar teaches storing upstream video data received via the data flow from the remote camera device in a video folder associated with the subscription of the UE device (para [0017] of Kamdar: An implementation described herein may relate to configuring a broadband home router (BHR), which interfaces a fixed wireless customer premises network with an LTE network, based on a subscriber profile downloaded over the LTE network.)(para [0022] of Kamdar: customer premises network 110 may use 9 different DSCP QoS classes, such as …, a video streaming QoS class, …)(para [0055] of Kamdar: As shown in FIG. 5, BHR 330 may include a router module 510, a Subscriber Identity Module (SIM) 520, a QoS manager 530, a QoS mapping table 540, one or more DSCP QoS class queues 550 (referred to collectively as “DSCP QoS class queues 550” and individually as “DSCP class queue 550” (interpreted as “a video folder associated with the subscription of the UE device”)), and one or more LTE QoS class queues 560 (referred to collectively as “LTE QoS class queues 560” and individually as “LTE class queue 560”)).
Regarding claim 7, Yuan and Kamdar teach The method of claim 1, Sodagar further teaches wherein the destination device includes a video management system, the method further comprising:
receiving, by the video management system, an instruction from the UE device to perform a control action for a video stream associated with the data flow from the camera device; and performing, by the video management system, the control action.
Sodagar, incorporating 3GPP TS 26.238 by reference in its entirely, explicitly teaches a destination device (i.e., the FLUS sink) acting as a video management system. Specifically, 3GPP TS 26.238, Clause 4.2.1, discloses that when the FLUS sink is located in the network, it may forward media content to processing sub-functions and “act as a Media Gateway Function (MGW) and/or an Application Function (AF)” (see page 8 of 3GPP TS 26.238, 4.2.1 General). This network-based processing entity corresponds to the claimed “video management system.”
Furthermore, the combination explicitly teaches the video management system receiving an instruction from the UE device to perform a control action for the video streams. 3GPP TS 26.238 defines a control Source (located at the UE/CTRL entity) that communicates with a Control Sink (at the FLUS sink) via the F-C (FLUS Control) interface. Clause 4.2.1 of 3GPP TS 26.238 teaches that “F-C represents the interactions associated with the creation and modification of the configuration of the FLUS sink” and allows the UE’s Control Source to “discover, select and configure the processing and distribution sub-functions”. Annex A.1.3 of 3GPP TS 26.238 further confirms that a human operator using the UE device (CTRL entity) “causes the Control Source function to establish and control the FLUS session” via these explicit control instructions (see page 40 of 3GPP TS 26.238, A.1.3 Deployment with non-colocated Control Source and Media Source).
In addition, Sodagar explicitly provides an example of this UE-issued control instruction. Sodagar, in para [0162], discloses that a “5GMS aware application at a UE can request for instantiation of an NBMP workflow for the network-based media processing through FLUS source.” Sodagar further teaches that, in response to receiving this explicit request (instruction) from the UE, the FLUS sink (video management system) “can instantiate the NBMP workflow” to process the received media components (performing the control action). See page 40 of 3GPP TS 26.238 and Figure A.1.3-1: Deployment with minimal FLUS sub-functions.) Figure A.1.3-1 of 3GPP TS 26.238 is reproduced herein below.
PNG
media_image1.png
526
1357
media_image1.png
Greyscale
Therefore, Sodagar, through its own disclosures and its explicit incorporation of 3GPP TS 26.238, clearly teaches “receiving, by the video management system, an instruction from the UE device to perform a control action for a video stream associated with the data flow from the remote camera device; and performing, by the video management system, the control action” as recited in claim 7
Regarding claim 8, Sodagar and Kamdar teach The method of claim 7, Sodagar further teaches wherein performing the control action includes:
combining a plurality of uplink video streams associated with a plurality of camera devices into a combined video stream (3GPP TS 26.238, which is incorporated by reference in its entirety by Sodagar, explicitly discloses media processing capabilities at the destination device (FLUS sink) that includes the combination of multiple media streams into a single combined stream. Specifically, Clause 4.4.4 of 3GPP TS 26.238 discloses that “Combination of input media streams, e.g. network based stitching, mixing” (see page 13 of 3GPP TS 26.238, 4.4.4. FLUS sink capability discovery).
Regarding claim 13, Claim 13 has similar limitation as of Claim(s) 2, therefore it is rejected under the same reasons as Claim(s) 2.
Regarding claim 14, Claim 14 has similar limitation as of Claim(s) 3, therefore it is rejected under the same reasons as Claim(s) 3.
Regarding claim 15, Claim 15 has similar limitation as of Claim(s) 4, therefore it is rejected under the same reasons as Claim(s) 4.
Regarding claim 16, Claim 16 has similar limitation as of Claim(s) 6, therefore it is rejected under the same reasons as Claim(s) 6.
Regarding claim 17, Claim 17 has similar limitation as of Claim(s) 7, therefore it is rejected under the same reasons as Claim(s) 7.
Regarding claim 18, Claim 18 has similar limitation as of Claim(s) 8, therefore it is rejected under the same reasons as Claim(s) 8.
Claim(s) 5 rejected under 35 U.S.C. 103 as being unpatentable over Sodagar in view of Kamdar, and further in view ow CN113411777A.
Regarding claim 5, Sodagar and Kamdar teach The method of claim 1, further comprising: Sodagar and Kamdar fail to teach:
performing an over-the-air (OTA) update for the camera device, wherein the OTA update is triggered by the UE device
It, however, had been known in the art before the effective date of the instant application as shown by CN113411777A as follows;
performing an over-the-air (OTA) update for the camera device, wherein the OTA update is triggered by the UE device (para [0039-0040] of CN113411777A, translated by Google Translation: a vehicle-mounted high-definition camera OTA upgrading method and a process sequentially comprise the following steps: 1.1 the user triggers a button for updating the software of the camera)(para [0061] of CN113411777A: … a corresponding interface of the vehicle machine (interpreted as “the UE device”) can prompt a user that the new software can be updated, the user can start upgrading the camera software only by clicking an update button.)
Therefore, it would have been obvious to one of ordinary skill in the art at the time of instant application to modify a combination of Sodagar and Kamdar by using the features of CN113411777A in order to have more effective method such that the user can start upgrading the camera software only by clicking an update button.
Claim 9 rejected under 35 U.S.C. 103 as being unpatentable over Sodagar in view of Kamdar, and further in view of Scheepens et al. (U.S. Patent Application Publication No. 20160240170, hereinafter “Scheepens”).
Regarding claim 9, Sodagar and Kamdar teach The method of claim 8, wherein performing the control action further includes: Sodagar and Kamdar fails to teach:
selecting a primary stream from the plurality of uplink video streams; and increasing a size of a window for the primary stream in the combined video stream, in response selecting the primary stream.
As discussed above, 3GPP TS 26.238, which is incorporated by reference in its entirety by Sodagar, explicitly discloses media processing capabilities at the destination device (FLUS sink) that includes the combination of multiple media streams into a single combined stream(see page 13 of 3GPP TS 26.238, 4.4.4. FLUS sink capability discovery).
Scheepens teaches the above feature as follows: selecting a primary stream from the plurality of uplink video streams; and increasing a size of a window for the primary stream in the combined video stream, in response selecting the primary stream (Figs 5a-5e and para [0067] of Scheepens: FIG. 5b-5d shows an animated sequence resulting from the user selecting the visual indicator 300, the animated sequence showing the selected viewport 2E being resized to display the video data at its native resolution and the other viewports 2A-2D, 2F being resized and rearranged to free up a portion of the display area.).
Therefore, it would have been obvious to one of ordinary skill in the art at the time of instant application to modify a combination of Sodagar and Kamdar by using the features of Scheepens in order to have more effective method such that the user can increases a size of a window for the primary stream in the combined video stream by selecting the primary stream.
Claims 10 and 19 rejected under 35 U.S.C. 103 as being unpatentable over Sodagar in view of Kamdar, in view of Scheepens, and further in view of Yuan (U.S. Patent Application Publication No. 20180190091, hereinafter “Yuan”).
Regarding claim 10, Sodagar, Kamdar and Scheepens teach The method of claim 9, wherein selecting the primary stream from the plurality of uplink video streams includes: Sodagar, Kamdar and Scheepens fail to teach
monitoring user behavior based on the plurality of uplink video streams;
identifying a user trigger action in a particular stream of the plurality of uplink video streams; and
selecting the particular stream as the primary stream, in response to identifying the user trigger action.
Yuan teaches:
monitoring user behavior based on the plurality of uplink video streams (para [0075] of Yuan: Eye tracker 140 includes a sensor (e.g., a camera) that enables monitoring station 125 to determine where the eyes of operator 402 are focused.);
identifying a user trigger action in a particular stream of the plurality of uplink video streams (para [0080] of Yuan: Based on the designated gaze area, different actions may be triggered, so that the information generated by eye tracker 140 may be interpreted as a user input to the video management system. For example, if eye tracker 140-1 determines that operator 402 is viewing frame 520-1 showing the video stream from camera 110-1 (interpreted as “identifying a user trigger action in a particular stream of the plurality of uplink video streams”)) and
selecting the particular stream as the primary stream, in response to identifying the user trigger action (para [0080] of Yuan: Based on the designated gaze area, different actions may be triggered, so that the information generated by eye tracker 140 may be interpreted as a user input to the video management system. For example, if eye tracker 140-1 determines that operator 402 is viewing frame 520-1 showing the video stream from camera 110-1 (interpreted as “selecting the particular stream as the primary stream, in response to identifying the user trigger action”), then station 125-1, VMS 150, and/or camera 110-1 may reduce a bit rate for areas of the video stream associated with areas of frame 520 that are outside the operator's gaze area.).
Sodagar, Kamdar, Scheepens and Yuan are considered to be analogous to the claimed invention because they are in the same field of a video streaming communication. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Sodagar, Kamdar, and Scheepens to incorporate the teachings of Yuan and provide the monitoring user behavior based on the plurality of uplink video streams and selecting the particular stream as a primary stream.
Regarding claim 19, Claim 19 has similar limitation as of Claim(s) 10, therefore it is rejected under the same reasons as Claim(s) 10.
Claim(s) 11 rejected under 35 U.S.C. 103 as being unpatentable over Sodagar, in view of Kamdar, and further in view of Yuan.
Regarding claim 11, Sodagar and Kamdar teaches The method of claim 7, wherein performing the control action includes: Sodagar and Kamdar fails to explicitly teach: generating a highlight reel for the video stream.
In analogous art, Yuan teaches: generating a highlight reel for the video stream (para [0080] of Yuan: Based on the designated gaze area, different actions may be triggered, so that the information generated by eye tracker 140 may be interpreted as a user input to the video management system. For example, if eye tracker 140-1 determines that operator 402 is viewing frame 520-1 showing the video stream from camera 110-1, then station 125-1, VMS 150, and/or camera 110-1 may reduce a bit rate for areas of the video stream associated with areas of frame 520 that are outside the operator's gaze area (interpreted as “generating a highlight reel for the video stream”)).
Sodagar, Kamdar and Yuan are considered to be analogous to the claimed invention because they are in the same field of a video streaming communication. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Sodagar and Kamdar to incorporate the teachings of Yuan and provide an instruction to generate a highlight reel for the video stream.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
GSMA TS.43-Service Entitlement Configuration discloses The device services covered in this document are Voice-over-Wi-Fi (VoWiFi), Voice-over-Cellular (4G VoLTE and 5G VoNR), SMS over IP (SMSoIP) and On-Device Service Activation (ODSA) of Companion devices (associated with a requesting device) and Primary devices.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to WON JUN CHOI whose telephone number is (703)756-1695. The examiner can normally be reached MON-FRI 08:00 - 17:00.
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, Derrick W Ferris can be reached at 571-272-3123. 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.
/WON JUN CHOI/Examiner, Art Unit 2411
/DERRICK W FERRIS/Supervisory Patent Examiner, Art Unit 2411
Prosecution Insights