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 .
Response to Arguments
Applicant’s arguments with respect to claims 1-3, 5, 8-12 and 14-24 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Claims 1, 5, 8, 12, 14-15 and 19 have been amended. Claims 4, 6-7 and 13 have been canceled and claims 21-24 have been newly added.
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.
Claims 19-20 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 19 recites the limitation "transmits the enriched video stream to a private network on a dedicated physical connection to the guard”. There is insufficient antecedent basis for this limitation in the claim.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-3, 5, 8, 10, 12, 14-18 and 23 are rejected under 35 U.S.C. 103 as being unpatentable over Mraz (US 2012/0151075) in view of Levi (US 2022/0131826).
Regarding claim 1, Mraz discloses a method for routing video streams, the method comprising:
receiving, by a source video broker in a source computing environment, a plurality of video streams from source addresses (receiving by node 613 data streams from source platforms 601-606; see at least Fig. 6 and paragraphs 0039 and 0045, wherein the data streams can be audio/video; see at least paragraphs 0030-0031 and source platforms have IP address; see at least paragraphs 0042 and 0049); and
based on the video streams source addresses, identifying for each video stream, by the
source video broker, a unique identifier for the video stream (assigning unique channel ID numbers to correspond the IP address of the source platforms; see at least paragraphs 0049-0050);
generating for each of the video streams, by the source video broker, enhanced datagrams including video packets of the video stream and routing metadata including the unique identifier, wherein the enhanced datagrams form an enriched video stream (for TCP packets or files, TCP ports may be defined in a configuration file. Each of the listed TCP ports may be associated with a unique channel ID number and for each entry in the configuration file, there is an entry which defines the destination TCP ports and provide the address information for downstream routing; see at least paragraphs 0042-0043 and the same for the UDP datagrams; see at least paragraphs 0032-0036);
multiplexing the enriched video streams (by multiplexer 508 and multiplexing application 614; see at least paragraphs 0033-0034, 0047 and 0051);
transmitting the multiplexed enriched video streams through a one-way transfer system to a destination computing environment (transferring UDP datagram and TCP streams through a single one way data link 514 and 623 to a number of destination platforms; see at least Figs. 5 and 6 and paragraphs 0033 and 0045-0046),
receiving, by a destination video broker in the destination computing environment, the enriched video streams (by the receiving node; see at least paragraphs 0036, 0043 and 0046);
extracting, by the destination video broker, the unique identifiers from the routing metadata of the enhanced datagrams of the enriched video streams (demultplexer that routes datagrams to their intended destination. The demultiplexer may use the configuration file to establish routing configuration for routing the datagrams to proper destination; see at least paragraphs 0036, 0043, 0048 and 0051);
based on the extracted unique identifiers, identifying, by the destination video broker, one or more destination address for the video streams, wherein the destination addresses correspond to one or more destination (destination platforms; see at least paragraphs 0036, 0043, 0048 and 0051);
transmitting, by the destination video broker, the enriched video streams to the one or more destination having the respective destination addresses (routing the datagrams to their intended UDB destinations; see at least paragraphs 0036, 0043, 0048 and 0051).
Mraz discloses the unique identifier, the routing metadata, the enhanced datagrams, the enriched video stream and the or more destination, but is not clear about that the destination corresponds to one or more video relays that control access to one or more networks, extracting, by the one or more video relays, a unique identifiers from routing metadata, based on the extracted identifiers, identifying, by the video relays, one or more destination addresses, wherein the destination address corresponds to one or more devices in the one or more networks and transmitting, by the video relays, a video stream to the one or more devices in the one or more networks.
Levi discloses the above missing limitation; routers forward packets on the bases of their layer-3 destination address (i.e. DGID), wherein the DGID is extracted from the packet; see at least paragraphs 0024, 0040, 0047, 0052 and 0065.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to modify Mraz by the teachings of Levi by having the above limitations so to be able to use address mapping to route packets across multiple subnetworks; see at least the Abstract.
Regarding claim 2, Mraz in view of Levi disclose the method of claim 1, wherein the multiplexed enriched video streams are transmitted on a single User Datagram Protocol (UDP) port (Mraz; see at least paragraphs 0030-0031 and 0035).
Regarding claim 3, Mraz in view of Levi disclose the method of claim 1, wherein the source video broker receives the plurality of video streams via multicast transmissions, and the transmission of the multiplexed enriched video streams is a unicast transmission (Mraz; see at least paragraphs 0034-0036).
Regarding claim 5, Mraz in view of Levi disclose the method of claim 1, wherein identifying, by the destination video broker, the destination address comprises:
accessing a routing table that stores corresponding destination addresses for multiple
unique identifiers (Mraz; from the configuration file; see at least paragraphs 0036 and 0041-0043);
querying the routing table with the unique identifier (Mraz; see at least paragraphs 0029, 0036 and 0041-0043); and
receiving, in response to the query, the destination address (Mraz; see at least paragraphs 0029, 0036 and 0041-0043).
Regarding claim 8, Mraz in view of Levi disclose the method of claim 1, wherein transmitting the received one or more enriched video streams is performed as a multicast transmission (Mraz; see at least paragraphs 0033-0034, 0047 and 0051).
Regarding claim 10, Mraz in view of Levi disclose the method of claim 1, wherein the source computing environment is a low-trust environment and destination computing environment is a high-trust computing environment (Mraz; from unsecured network to a secure network; see at least paragraph 0005).
Regarding claim 12, Mraz discloses most of the claim as in the rejection of claims 1, but is not clear about that the destination corresponds to a video relay that control access to a network, extracting, by the video relay, a unique identifiers from routing metadata, based on the extracted identifiers, identifying, by the video relay, a destination address, wherein the destination address corresponds to device in the networks and transmitting, by the video relays, a video stream to the one or more devices in the one or more networks.
Levi discloses the above missing limitation; routers forward packets on the bases of their layer-3 destination address (i.e. DGID), wherein the DGID is extracted from the packet; see at least paragraphs 0024, 0040, 0047, 0052 and 0065.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to modify Mraz by the teachings of Levi by having the above limitations so to be able to use address mapping to route packets across multiple subnetworks; see at least the Abstract.
Regarding claim 14, Mraz in view of Levi disclose the method of claim 12, wherein the enriched video stream is transmitted to the device in the network as a multicast transmission (Mraz; see at least paragraphs 0033-0034, 0047 and 0051).
Regarding claim 15, Mraz in view of Levi disclose the method of claim 12, wherein the network is a first network and the video relay is a first video relay, and the device in the first network is a second video relay that controls access to a second network (Levi; see at least the rejection of claim 12).
Regarding claim 16, Mraz in view of Levi disclose the method of claim 15, further comprising:
extracting, by the second video relay, the unique identifier from the routing metadata of
the enhanced datagrams of the enriched video stream (he combination of Mraz’s extraction, the unique identifier, the routing metadata and Levi’s video relay; see at least the rejection of claim 1);
based on the extracted unique identifier, identifying, by the second video relay, a destination address for the video stream, wherein the destination address corresponds to device in the second network (the combination of Mraz’s extraction, the unique identifier, the destination address and Levi’s video relay; see at least the rejection of claim 1); and
transmitting, by the second video relay, the video stream to the device in the second network (the combination of Mraz’s transmission, the enriched video streams and Levi’s video relay; see at least the rejection of claim 1).
Regarding claim 17, Mraz in view of Levi disclose the method of claim 12, wherein the enriched video stream is generated by a source video broker, in a source computing environment, that receives a video stream having a source address, and the source video broker identifies the unique identifier by:
accessing a mapping table storing unique identifiers for video streams based on the source addresses of the video streams (Mraz; from the configuration file; see at least paragraphs 0036 and 0041-0043); and
identifying the unique identifier for the video stream based on the source address for the video stream (Mraz; from the configuration file; see at least paragraphs 0036 and 0041-0043).
Regarding claim 18, Mraz in view of Levi disclose the method of claim 12, wherein the video stream is transmitted from the destination video broker to the video relay through a data diode that prevents data transmission from the video relay to the destination video broker (Mraz; one way data link; see at least paragraphs 0005, 0023, 0028, 0031 and 0033).
Regarding claim 23, Mraz in view of Levi disclose the method of claim 12, wherein the video relay identifies the destination address for the video stream based on a locally stored lookup table (Levi; forwarding/routing tables; see at least paragraphs 0025, 0031 and 0064-0065).
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Mraz in view of Levi and further in view of Trayanov (US 2021/0377330).
Regarding claim 9, Mraz in view of Levi disclose the method of claim 1, and disclose the enriched video streams, header and the unique identifier for the respective video stream; from the TCP and the UDP protocols; as above, but are not clear about encapsulating video streams in a Secure Reliable Transport (SRT).
Trayanov discloses the above missing limitation; a video stream is received, segmented into segments, encoded into a packetized elementary stream, multiplexed into a TS stream and packetized into a plurality of SRT packets and transmitted over a network; see at least paragraphs 0008, 0028, 0031 and 0045.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to modify Mraz in view of Levi by the teachings of Trayanov by having the above limitations so to be able to provide a system for low latency, real-time streaming by backhauling multimedia content via the Internet using SRT connection-oriented protocols; see at least the Abstract.
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Mraz in view of Levi and further in view of Clarke (US 2014/0139737).
Regarding claim 11, Mraz in view of Levi disclose the method of claim 1, and disclose the enhanced datagram, a routing packet including the routing metadata; as above, but are not clear about a datagram comprises up to seven transport stream (TS) packets.
Clarke discloses the above missing limitation; a UDP packet comprises a number (seven) of TS packets; see at least paragraph 0033. And 0035.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to modify Mraz in view of Levi by the teachings of Clarke by having the above limitations so to be able to filter a digital signal transmitted in a protocol featuring multi-level packetization from a first server to a second server; see at least the Abstract.
Claims 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Mraz in view of Levi and further in view of West (US 2024/0405864).
Regarding claim 19, Mraz in view of Levi disclose most of claim as in the rejection of claims 1 including the ingress IP address; see at least Levi; paragraph 0063, and the guard as being a data link that protects a destination computing environment and transmits the video stream to the destination computing environment; Mraz; one-way data link; see at least Fig. 5 and paragraph 0036, but are not clear about that the guard being a device that transcodes the video stream.
West discloses the above missing limitation; a guard that transcode a video stream; see at least paragraph 0043.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to modify Mraz in view of Levi by the teachings of West by having the above limitations for the purpose of transferring data through a one-way transfer system using a fault-tolerant data diode; see at least the Abstract.
Regarding claim 20, Mraz in view of Levi and further in view of West disclose the system of claim 19, further comprising a data diode between the destination video broker and the video relay, wherein the data diode prevents data transmission from the video relay to the destination video broker (Mraz; one way data link; see at least paragraphs 0005, 0023, 0028, 0031 and 0033 and the diode of West; see at least paragraphs 0011 and 0065).
Claim 21 is rejected under 35 U.S.C. 103 as being unpatentable over Mraz in view of Levi and further in view of Bertram (US 2008/0013536).
Regarding claim 21, Mraz in view of Levi disclose the method of claim 1, and storing the routing metadata; as above, but are not clear about a modified null packet.
Bertram discloses the above missing limitation; detecting NULL packet ad replacing some or all with asset packets; see at least paragraphs 0035, 0045 and 0062.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to modify Mraz in view of Levi by the teachings of Bertram by having the above limitations so to inject assets into a content stream; see at least paragraph 0003.
Claims 22 and 24 are rejected under 35 U.S.C. 103 as being unpatentable over Mraz in view of Levi and further in view of Salmon-Legagneur (US 2024/0165508).
Regarding claim 22, Mraz in view of Levi disclose the method of claim 1 and disclose the unique identifier, but are not clear about a destination socket ID field of an SRT header.
Salmon-Legagneur discloses that a SRT packet may include a SRT header, which may include information indicating any of a packet number, a message number, time stamp, a destination socket ID, etc.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to modify Mraz in view of Levi by the teachings of Salmon-Legagneur by having the above limitations for the purpose of quality of experience improvement in a cloud gaming; see at least the Abstract.
Claim 24 is rejected on the same grounds as claim 22.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to YASSIN ALATA whose telephone number is (571)270-5683. The examiner can normally be reached Mon-Fri 7-4 ET.
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, Nasser Goodarzi can be reached at 571-272-4195. 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.
/YASSIN ALATA/Primary Examiner, Art Unit 2426
Prosecution Insights