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 .
This office correspondence is in response to “Amendment and Response under 37 C.F.R. 1.111 filed on June 25, 2026 in response to a non-final office action issued on April 9, 2026.
Claims 1 – 19 are pending.
Claims 7 and 9 – 13 are amended.
Claim 19 is added.
Claims 1 – 19 are rejected.
Applicant’s arguments filed on 6/25/2026 have been fully considered:
In regard to claims 7 – 12 which were interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, the applicant has amended said claims to remove the terms “acquisition module” and “conversion module”, so that the interpretation under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph is no longer applicable to the claims.
In regard to claims 13 – 18 which were rejected under 35 USC 101 for being directed to non-statutory subject matter as the elements “first server” and “second server” can be interpreted as software per se. The applicant states:
“ . . . The Office asserted that the claimed system could be interpreted as software. Applicant respectfully disagrees. The claims recite a data processing system including a first server and a second server. A "server" is well understood in the art as a hardware-based computing system including processing and networking capabilities. The Office's conclusion that the claims could be construed as software per se is inconsistent with the plain meaning of the claim language. A system described in terms of servers that communicate with one another to process and transmit data would not be reasonably interpreted by one of ordinary skill in the art as software alone. Rather, such a system inherently recites a machine implementation, which squarely falls within a statutory category under § 101. Therefore, Applicant respectfully requests that the Examiner reconsider and withdraw the rejection of claims 13-18 under 35 U.S.C. § 101. . . .” (Applicant’s remarks pages 10 -11)
In response to the applicant’s argument:
The applicant’s argument is not persuasive. The definition of a server is a computer or computer program that manages access to a centralized resource or service on a network (see Dictionary.com). The claim recites no hardware components such as a processor, non-transitory physical memory, or physical I/O ports that would enable a prectioner of the art to discern that the first server and second server are physical devices. Therein the rejections are not withdrawn.
In regard to claims 1 – 18, the applicant argues that the prior art combination of Hinds and Moreman fails to anticipate, disclose or teach:
“A data processing method, applied to a first server using a first transmission protocol, comprising: obtaining a first data packet transmitted by a second server using a second transmission protocol, the first data packet being generated at least based on data sent by a first-type client and a second-type client, the first-type client being configured as a control end, and the second-type client being configured to interact bidirectionally with the first-type client using a first interaction content;”(as recited in claim 1 and substantially replicated in claims 7 and 13)
The applicant states:
: . . . Independent claim 1, recites a data processing method applied to "a first server" using "a first transmission protocol," comprising "obtaining a first data packet transmitted by a second server using a second transmission protocol." Hinds and Moreman, whether taken alone or in combination, fail to disclose or suggest at least these elements.
In the rejection of claim 1, the Office asserted that Hinds teaches a data processing method by mapping the server device of Hinds to the claimed "first server," and appeared to map client devices to the claimed "second server." The Office also asserted that Hinds discloses the claimed "first transmission protocol" and "second transmission protocol," referring to TT[0008] and [0086] of Hinds for support. Office Action at 7 and 8. Applicant respectfully disagrees.
Hinds fails to disclose or suggest a system involving two distinct servers as required by the claim. Rather, Hinds consistently describes a system centered around a single "server device" that communicates with client devices via different communication channels. Specifically, Hinds teaches that a server device exchanges control messages over a control plane channel using a first transport protocol, and transmits data messages over a data plane channel using a second transport protocol. See, Hinds, Abstract and [0008]. These disclosures merely describe different types of communication within a single server-client architecture, and do not involve any interaction or data exchange between two separate servers.
Moreover, the client devices in Hinds cannot reasonably be equated to the claimed "second server." The client devices in Hinds are endpoints that receive media content distributed by the server device and, at most, transmit control-related information to the server. See, Hinds, ||||0156] and [0157] and FIG. 16. They are not configured to perform server-side functions, nor do they transmit a "first data packet" generated at least based on data sent by a first-type client and a second-type client to another server using a second transmission protocol.
For at least the reasons discussed above, Hinds and Moreman both fail to disclose or suggest a data processing method applied to "a first server" using "a first transmission protocol," including "obtaining a first data packet transmitted by a second server using a second transmission protocol," as recited in claim 1.
In view of the above, the Office has neither properly determined the scope and content of the cited references nor properly ascertained the differences between the claimed invention and the cited references. Moreover, the Office has articulated no reason as to why one of ordinary skill in the art would find the claimed combination obvious in view of the references, despite these differences. For at least this reason, no prima facie case of obviousness has been established with respect to claim 1. Claim 1 is thus allowable.
Independent claim 13, although different in scope from independent claim 1, recites elements similar to those of claim 1 discussed above. Thus, for reasons similar to those discussed above, claim 13 is allowable.
Claims 2-12 and 14-18 are also allowable at least by virtue of their dependence from claims 1 and 13. . . “ (Applicant’s remarks pages 12 – 13)
In response to the applicant’s argument:
The applicant’s argument is not persuasive as Hinds teaches a multi-server platform for adapting media using a transport protocol and a bi-directional protocol (see Hinds Fig, 12 ¶ [0148]. Further, in Fig. 20 ¶ [0176], Hinds represents server device 2010 as a server farm with multiple servers, so one server in the farm can be used for exchanging control messages over a control plane channel using a first transport protocol, and a different server can be used for transmitting data messages over a data plane using a second transport protocol. There is nothing recited in the claim to prohibit communication between servers in the same farm. The applicant needs to put more detail in the claim language as to the configuration and relationship of the servers. As such, the rejections under 35 USC 103 are not withdrawn.
The examiner recommends that the applicant review the specification for disclosure that if integrated into the independent claims would distinguish the amended claims from the cited prior art. The applicant is invited to contact the examiner for an interview to discuss how to move the prosecution forward.
Authorization for Internet Communications
The examiner encourages Applicant to submit an authorization to communicate with the examiner via the Internet by making the following statement (from MPEP 502.03):
“Recognizing that Internet communications are not secure, I hereby authorize the USPTO to communicate with the undersigned and practitioners in accordance with 37 CFR 1.33 and 37 CFR 1.34 concerning any subject matter of this application by video conferencing, instant messaging, or electronic mail. I understand that a copy of these communications will be made of record in the application file.”
Please note that the above statement can only be submitted via Central Fax (not Examiner's Fax), Regular postal mail, or EFS Web using PTO/SB/439.
35 USC § 101 Analysis – Judicial Exception
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefore, subject to the conditions and requirements of this title.
The claimed invention is directed to statutory subject matter and are not rejected under 35 USC 101 because of a judicial exception. The claimed subject matter is integrated into a practical application under Prong 2 of the Step 2A analysis described in MPEP 2016.04(d). The claims are directed to non-abstract improvements in computer related technology. A claim is non-statutory when it is directed to a judicial exception (e.g. either one of mathematical concepts, mental processes, or certain methods of organizing human activity) without significantly more. The claimed invention is not directed to a judicial exception. Instead, the claimed invention is directed to a technological improvement for data processing applied to scenarios such as line streaming or online meetings wherein a first data packet transmitted by a second server using a second transmission protocol is obtained. The first data packet is generated at least based on data sent by a first-type client and a second-type client. The first-type client is configured as a control end, and the second-type client is configured to interact bidirectionally with the first-type client using a first interaction content. The second-type client can send data to the second server, and the first server can obtain data that is sent using the second transmission protocol through the second server. The data included in the first data packet can be generated based on the interaction between the first-type client 300 and the second-type client 400. The first data packet is converted into a target format to generate a second data packet. This second data packet is configured to be transmitted to a third-type client by the first server. The first transmission protocol is configured as a data transmission protocol, and the second transmission protocol is configured as a real-time communication protocol. The third-type client is configured to at least perform a single directional interaction with the first-type client with the second interaction content. The first interaction content is different from the second interaction content. The third-type user corresponding to the third-type client can be understood as a reception end, which is configured to receive the data generated by the interaction between the first-type client and the second-type client. For example, for the network live-streaming scenario, the third-type user can be a viewing user. The third-type client can only receive the second data packet sent using the first transmission protocol configured as the data transmission protocol. Thus, the third-type user can watch the interaction between the first-type user and the second-type use. The ordered steps of the claim language impose meaningful limits on the scope of the claims, and provides a useful improvement that enables the first server to transmit the data to the third client using the first transmission protocol and therein reduces the restriction on the number of the third-type client compared to transmitting the data by the second server using the second transmission protocol. That is, the restriction on the number of people watching the live streaming can be reduced. The data can be distributed to more third-type clients. Therein the claimed invention is statutory under 35 USC 101, excepting for certain claims as described in the next section.
35 USC § 101 Rejection – Software Per SE
Claims 13 – 18 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter.
In regard to claims 13, the preamble “a data processing comprising” appears to be directed to a system. However, upon review of each of the elements claimed (e.g. “a first server ”, “a second server” and the specification (“Fig. 6 Data Conversion System 700, First Server 100, Second Server 200, ¶ [0070]), the claimed invention could be reasonably interpreted by one skilled in the art as being software alone, and thus is directed to software per se, which is non-statutory. In order for such software claim to be statutory, it must be claimed in combination with an appropriate medium and/or hardware to establish a statutory category of invention and enable any functionality to be realized.
In regard to claims 14 – 18, which are dependent upon claim 13, they are rejected as incorporating and failing to resolve the deficiency of claim 12 on which they depend.
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 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 of this title, 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 - 18 are rejected under 35 U.S.C. 103 as being unpatentable over Hinds et al. (U.S. 2023/007361 A1; herein referred to as Hinds) in view of Moreman (U.S. 2012/0327780 A1; herein referred to as Moreman)
In regard to claim 1, Hinds teaches A data processing method (see abstract “ . . . Aspects of the disclosure provide methods and apparatuses for media processing. In some examples, an apparatus includes processing circuitry. The processing circuitry can exchange, with a server device, a plurality of control messages over a control plane channel that uses a first transport protocol. The plurality of control messages belongs to a control plane of a bidirectional protocol for immersive media distribution . . .”) , applied to a first server using a first transmission protocol (see ¶ [0008] “ . . . The processing circuitry can exchange, with a server device, a plurality of control messages over a control plane channel that uses a first transport protocol . . .”) , comprising:
obtaining a first data packet transmitted by a second server (see ¶ [0086] “ . . . provide a bidirectional protocol that can be used between a media distribution network (e.g., a server device in the media distribution network that interfaces the media distribution network with client devices) and client devices. In some examples, the bidirectional protocol can be used in a media distribution network that distributes immersive media. The bidirectional protocol can support a variety of diverse client devices that require asset types in various formats. In some examples, the bidirectional protocol can enable reuse of assets that have previously been adapted for use by a particular client device . . .”) using a second transmission protocol (see ¶ [0008] “ . . . The plurality of control messages belongs to a control plane of a bidirectional protocol for immersive media distribution. The processing circuitry receives, from the server device, a first plurality of data messages over a first data plane channel that uses a second transport protocol . . .”) , the first data packet being generated at least based on data sent by a first-type client and a second-type client (see Fig.1 ¶ [0092] “ . . . FIG. 1 shows a diagram of the end-to-end process (100) of timed legacy media distribution. In FIG. 1, timed audio-visual content is either captured by a camera or microphone (101A) or generated by a computer (101B), creating a sequence (102) of 2D images and associated audio that are input to a preparation module (103). The output of the preparation module (103) is edited content (e.g., for post-production including language translations, subtitles, other editing functions), referred to as a master format that is ready to be converted to a standard Mezzanine format, e.g., for on-demand media, or as a standard contribution format, e.g., for live events, by a converter module (104). In an example, the media is ingested by the commercial network service provider and an adaptation module (105) packages the media into various bitrates, temporal resolution (frame rates) or spatial resolutions (frame sizes) that are packaged into a standard distribution format. The resulting adaptations are stored onto a content distribution network (CDN) (106) from which various clients (108A)-(108C) make pull-requests (107A)-(107C) to fetch and present the media to the end user. It is important to note that the master format may consist of a hybrid of media from both (101A) or (101B), and that the format of (101A) may be obtained in real-time, e.g., such as media that is obtained from a live sporting event. Furthermore, clients (108A)-(108C) are responsible for choosing the specific adaptations that are best suited for the client's configuration and/or for the current network conditions, but it is equally possible that the network server (not shown in FIG. 1) could determine and subsequently push the appropriate content to the clients (108A)-(108C). . . .”), the first-type client being configured as a control end (see ¶ [0014] “ . . . the apparatus is a first client device, and the plurality of control messages enables the server device to share the immersive media content with a second client device. In an example, the processing circuitry provides, in response to a request from the server device, a list of types of assets that are sharable and uniform resource identifiers (URIs) for the assets that are cached in an immutable storage via the control plane channel. . . .”), and the second-type client being configured to interact bidirectionally with the first-type client using a first interaction content (see ¶ [0089] “ . .. The server devices can employ a bidirectional communication protocol (also referred to as bidirectional protocol) for the communication with the client devices, and can facilitate the adaptation of media to match requirements originating from the uniqueness of the client devices, or from the application running on the client devices. The server devices can also use the bidirectional protocol to stream assets that are either newly adapted or previously adapted and cached, to a particular client device. In some examples, the server devices can use the bidirectional protocol to support the ability for the client devices to request specific assistance from the server devices, for example, to assist with rendering of an asset in preparation for the client device to present the asset. . . .”); and
converting the first data packet into a target format to generate a second data packet (see ¶ [0053] “ . . . The process of breaking media into smaller portions, organizing them into the payload portions of consecutive network protocol packets, and distributing these protocol packets is referred to as streaming of the media whereas the process of converting the media into a format that is suitable for presentation on one of a variety of heterogenous client end-points that is operating one of a variety of heterogenous applications is referred to as adapting the media . . .”; see ¶ [0083] “ . . . a media distribution network supporting heterogeneous clients can leverage the fact that some of the assets that are adapted from an input media format to a specific target format may be reused across a set of similar display targets (client devices). For example, some assets, once converted to a format suitable for a target display may be reused across a number of such displays that have similar adaptation requirements. In some examples, the media distribution network can employ a caching mechanism to store adapted assets into a storage that is relatively immutable. . . .”)), (see ¶ [0126] “ . . the network will first query the client end-point to determine the client's capabilities, and if the client is not capable of meaningfully ingesting the media representation then the network will either remove the layers of attributes that are not supported by the client, or adapt the media from its current format into a format that is suitable for the client end-point. In one example of such adaptation, the network would convert a volumetric visual media asset into a 2D representation of the same visual asset, by use of a Network-Based Media Processing protocol . . .”)., and the second transmission protocol being configured as a real-time communication protocol (see ¶ [0138] “ . . . As depicted in FIG. 8, a client interface module (805) (e.g., referred to as server device in some examples) serves as the primary source and sink of information to execute the major tasks of the distribution network. In this particular embodiment, the client interface module (805) may be implemented in unified format with other components of the network. Nevertheless the tasks depicted by the client interface module (805) in FIG. 8 form elements of the disclosed subject matter in some examples. The client interface module (805) may further employ a bidirectional protocol for communication with the client device to facilitate all processing and distribution of the media in accordance with the characteristics of the client device. Furthermore, the bidirectional protocol may be implemented across different delivery channels, i.e., a control plane channel and a data plane channel . . .”) ,
Hinds fails to explicitly teach,
However Moreman teaches
the second data packet being configured to be transmittable to a third-type client by the first server (see Moreman ¶ [0018] “ . . . CPE devices 110 may comprise a client device 125 configured to request, receive, buffer, playback, and store, for example, content, which may be embodied in IP video packets or other data packets received either directly or indirectly from CDS 120. Client device 125 may be, but is not limited to, a set-top box, a personal computer, a mobile phone, or any other computing device capable of communicating with a conversion device 130 and CDS 120 over network 115. In various embodiments of the disclosure, client device 125 may only be configured to receive unicast transmissions of content. As such, in a multiple client network, the bandwidth necessary for server 135 to satisfy multiple requests for unicast content transmissions from multiple client devices may be too burdensome or may lead to congestion on network 115 . . .”) ,
the third-type client being configured to interact at least unidirectionally with the first-type client using a second interaction content, and the first interaction content being different from the second interaction content (see Moreman ¶ [0021] “ . . . , conversion device 130 may also store content received from CDS 120. Conversion device 130 may comprise a processing unit 210 operatively associated with a memory 215. Memory 215 may comprise a cache 220 for storing content packets, such as IP video packets, received from the CDS 120 at, for example, the multicast or unicast transmission protocol. In this way, conversion device 130 may store the IP packets associated with the received content from CDS 120 and provide, upon request from client device 125, the IP packets to client device 125 at a unicast transmission protocol. Thus, conversion device 130 may satisfy requests for content from client device 125 by ) receiving IP packets associated with the content at a multicast transmission protocol, ii) storing the IP packets in cache 220, iii) receiving a request for the IP packets from client device 125, iv) converting the IP packets for unicast protocol transmission by conversion module 225, and v) sending the IP packets to client device 125 at the unicast transmission protocol . . . “).
It would have been obvious to one skilled in the art, before the effective filing date of the applicant’s claimed invention to incorporate a method and system for converting transmission protocols including multicast packet transfer to unicast packet transfer depending upon the type of traffic being transferee and the delivery performance in a streaming scenario, as taught by Moreman, into a method and system for media processing where the processing provides an exchange, with a server device, a plurality of control messages over a control plane channel that uses a first transport protocol. The plurality of control messages belongs to a control plane of a bidirectional protocol for immersive media distribution. The processing circuitry receives, from the server device, a first plurality of data messages over a first data plane channel that uses a second transport protocol. The first plurality of data messages belongs to a data plane of the bidirectional protocol and carries immersive media content, as taught by Hind. Such incorporation provides an automatic process to convert media packets from one transmission protocol to a second transmission protocol dependent on the content of the data.
In regard to claim 2, the combination of Hind and Moreman teaches wherein: in a first target scenario, the first-type client is configured to send data to the first server or to the first server and the second server, and the second-type client is configured to send data to the second server (see Hinds ¶ ¶ [0193-0196] “ . . . In some examples, using the control messages exchanged over the control plane channels (2001), (2003) and (2005), the server device (2010) can manage the distribution of the media to the media client devices by establishing a unique session and operating context for the adaptation and distribution of the media to the media client device. In some examples, the control messages exchanged over the control plane channels (2001), (2003) and (2005), can assist the media sever device (2010) in an adaptation process of the input media to match the capabilities of the media client device.] For example, the server device (2010) can establish a first unique session (e.g., the data plane channel (2002)) with the client device (2060A) based on control messages exchanged over the control plane channel (2001). The server device (2010) can generate a first media stream that is adapted from the input media to match the capabilities of the client device (2060A). The data plane channel (2002) can provide the first media stream to the client device (2060A). The server device (2010) can establish a second unique session (e.g., the data plane channel (2004)) with the client device (2060B) based on control messages exchanged over the control plane channel (2003). The server device (2010) can generate a second media stream that is adapted from the input media to match the capabilities of the client device (2060B). The data plane channel (2004) can provide the second media stream to the client device (2060B). The server device (2010) can establish a third unique session (e.g., the data plane channel (2006)) with the client device (2060C) based on control messages exchanged over the control plane channel (2005). The server device (2010) can generate a third media stream that is adapted from the input media to match the capabilities of the client device (2060C). The data plane channel (2006) can provide the third media stream to the client device (2060C) . . . “)
In regard to claim 3, the combination of Hind and Moreman teaches wherein obtaining the first data packet transmitted by the second server using the second transmission protocol (see Hind ¶ [0008] ¶ [0086] as described for the rejection of claim 1 and is incorporated herein) , includes:
obtaining a third data packet (e.g. control message) generated from data sent by the first-type client (see Hinds ¶ [0161] “ . . . facilitate the implementation of the bidirectional protocol. For example, messages in the bidirectional protocol are separated into two categories: control messages and data messages. In some examples, the data messages include media data for delivery, and the control messages includes control information for delivering the data messages. For example, the control messages can include setup information to prepare the delivery of the data messages, the handling information during the delivery of the data messages, checking information after the delivery of the data messages and the like. . . .”) ;
converting the third data packet into the target format to generate a fourth data packet that is transmittable by the second server (see Hinds ¶ [0160] “ . . . , a specific message can cause the client device to send its processing characteristics to the server device, so that upon receiving the processing characteristic of the client device, the server device is equipped with sufficient information to meaningfully adapt the ingested media to a format suitable for the client device . . .”) ; and
generating the first data packet based on the fourth data packet (see Hinds ¶ [0164] “ . . . media data can be transmitted over the data plane channel with less delay, and control information, such as setup information, monitoring information and status notification for assisting the transmission over the data plane channel, can be transmitted over the control plane channel to ensure successfully data message transmissions or to detect errors in the transmission over the data plane channel and trigger retransmission over the data plane channel . . .”).
In regard to claim 4, the combination of Hind and Moreman teaches wherein generating the first data packet based on the fourth data packet (see Hinds ¶ [0164] as described for the rejection of claim 3 and is incorporated herein) includes:
determining a fifth data packet generated based on data sent by the second-type client to the second server (see Hinds ¶ [0165] “ . . . the bidirectional communication with separate control plane channel and data plane channel can be used to build a media distribution network that can support a variety of diverse client devices that require asset types in various formats, and that can reuse assets that have previously been adapted for use by a particular client device. With the separation of bidirectional communication over the control plane channel and the data plane channel, in some examples, a more robust and efficient media distribution network can be implemented with the data messages being carried over a transport layer that requires less latency but is less reliable, while the control messages are carried over a more reliable transport layer that is also slower to deliver messages. . . .,); and
generating the first data packet based on the fourth data packet and the fifth data packet (see Fig. 19A Hinds ¶ [0167] “ . . . the communication channel (1902) is configured to deliver control messages from the server device (1901) to the client device (1906). FIG. 19B shows a list of control messages from the bidirectional protocol in FIGS. 16A-16C that can be delivered by the communication channel (1902).
In regard to claim 5, the combination of Hind and Moreman teaches wherein converting the first data packet into the target format to generate the second data packet (see Hinds ¶ [0053], ¶ [0083] as described for the rejection of claim 1 and is incorporated herein) includes:
determining a data format of the first data packet (see Hinds ¶ [0046] “ . . . The distribution of any media over networks may employ media delivery systems and architectures that reformat the media from an input or network ingest format to a final distribution format where that distribution format is not only suitable for the targeted client device and its applications, but is also conducive to being streamed over the network. Streaming of media broadly refers to the fragmenting and packetizing of the source media so that the media can be delivered over the network in consecutive smaller-sized “chunks” logical organized and sequenced according to either or both the media's temporal or spatial structure. In such distribution architectures and systems, the media may undergo compression or layering processes so that only the most salient media information is delivered first to the client. In some cases, the client receives all of the salient media information for some portion of the media before the client is able to present any of the same media portion to the end user. . . .”) ; and
in response to the data format being the target format (see Hinds ¶ [0053] “ . . . The process of breaking media into smaller portions, organizing them into the payload portions of consecutive network protocol packets, and distributing these protocol packets is referred to as streaming of the media whereas the process of converting the media into a format that is suitable for presentation on one of a variety of heterogenous client end-points that is operating one of a variety of heterogenous applications is referred to as adapting the media. . . .”) , directly converting the first data packet into the second data packet that is transmitted based on the first transmission protocol (see Hinds ¶ [0086] “ . . . a bidirectional protocol that can be used between a media distribution network (e.g., a server device in the media distribution network that interfaces the media distribution network with client devices) and client devices. In some examples, the bidirectional protocol can be used in a media distribution network that distributes immersive media. The bidirectional protocol can support a variety of diverse client devices that require asset types in various formats. In some examples, the bidirectional protocol can enable reuse of assets that have previously been adapted for use by a particular client device. . . .”)
In regard to claim 6, the combination of Hind and Moreman teaches wherein converting the first data packet into the target format to generate the second data packet (see Hinds ¶ [0053], ¶ [0083] as described for the rejection of claim 1 and is incorporated herein) includes:
determining a data format of the first data packet (see Hinds ¶ [0046] as described for the rejection of claim 5 and is incorporated herein); and
in response to the data format being not the target format (see Moreman ¶ [0020] “ . . . conversion module 225 may convert IP video packets associated with received content from CDS 120 to a transmission protocol compatible with client device 125. With conversion module 225, conversion device 130 may receive content transmitted from CDS 120 at a first transmission type (e.g., multicast transmission) and provide the received content to client device 125 at a converted second transmission type (e.g., unicast transmission). . . .”), converting the first data packet into the target format to obtain the second data packet that is transmitted based on the first transmission protocol (see Moreman ¶ [0021] “ . . . conversion device 130 may also store content received from CDS 120. Conversion device 130 may comprise a processing unit 210 operatively associated with a memory 215. Memory 215 may comprise a cache 220 for storing content packets, such as IP video packets, received from the CDS 120 at, for example, the multicast or unicast transmission protocol. In this way, conversion device 130 may store the IP packets associated with the received content from CDS 120 and provide, upon request from client device 125, the IP packets to client device 125 at a unicast transmission protocol. Thus, conversion device 130 may satisfy requests for content from client device 125 by receiving IP packets associated with the content at a multicast transmission protocol, ii) storing the IP packets in cache 220, iii) receiving a request for the IP packets from client device 125, iv) converting the IP packets for unicast protocol transmission by conversion module 225, and v) sending the IP packets to client device 125 at the unicast transmission protocol. . . “).
The motivation to combine Moreman with Hinds is described for the rejection of claim 1 and is incorporated herein. Additionally, Moreman will provide a conversion of the data to a protocol that will transmit the content.
In regard to claim 7, Hinds teaches A data processing device (see abstract “ . . . Aspects of the disclosure provide methods and apparatuses for media processing. In some examples, an apparatus includes processing circuitry. The processing circuitry can exchange, with a server device, a plurality of control messages over a control plane channel that uses a first transport protocol. The plurality of control messages belongs to a control plane of a bidirectional protocol for immersive media distribution . . .”), applied to a first server using a first transmission protocol(see ¶ [0008] “ . . . The processing circuitry can exchange, with a server device, a plurality of control messages over a control plane channel that uses a first transport protocol . . .”) , comprising:
a processor (Fig. 23 ¶ [0237] “ . . . , the computer system having architecture (2300), and specifically the core (2340) can provide functionality as a result of processor(s) (including CPUs, GPUs, FPGA, accelerators, and the like) ;
a memory storing a computer program that when executed by the processor, causes the processor to perform the data processing method (see ¶ [0237] “ . . . executing software embodied in one or more tangible, computer-readable media. Such computer-readable media can be media associated with user-accessible mass storage as introduced above, as well as certain storage of the core (2340) that are of non-transitory nature, such as core-internal mass storage (2347) or ROM (2345). The software implementing various embodiments of the present disclosure can be stored in such devices and executed by core (2340). A computer-readable medium can include one or more memory devices or chips, according to particular needs. The software can cause the core (2340) and specifically the processors therein (including CPU, GPU, FPGA, and the like) to execute particular processes or particular parts of particular processes described herein, including defining data structures stored in RAM (2346) and modifying such data structures according to the processes defined by the software. . . .”) according to claim 1 (the combination of Hinds and Morehead as described in the rejection of claim 1 and is incorporated herein).
In regard to claim 8, the combination of Hinds and Moreman teaches wherein:
in a first target scenario, the first-type client is configured to send data to the first server or to the first server and the second server, and the second-type client is configured to send data to the second server (see Hinds ¶ ¶ [0193-0196] as described for the rejection of claim 2 and is incorporated herein).
In regard to claim 9, the combination of Hinds and Moreman teaches wherein obtaining the first data packet transmitted by the second server using the second transmission protocol includes: obtaining a third data packet (e.g. control message) generated from data sent by the first-type client (see Hinds ¶ [0161] as described for the rejection of claim 3 and is incorporated herein);
converting the third data packet into the target format to generate a fourth data packet that is transmittable by the second server (see Hinds ¶ [0160] as described for the rejection of claim 3 and is incorporated herein); and
generating the first data packet based on the fourth data packet (see Hinds ¶ [0164] as described for the rejection of claim 3 and is incorporated herein).
In regard to claim 10, the combination of Hinds and Moreman teaches wherein generating the first data packet based on the fourth data packet includes: determining a fifth data packet generated based on data sent by the second-type client to the second server (see Hinds ¶ [0165] as described for the rejection of claim 4 and is incorporated herein) ; and
generating the first data packet based on the fourth data packet and the fifth data packet (see Fig. 19A Hinds ¶ [0167] as described for the rejection of claim 4 and is incorporated herein)
In regard to claim 11, the combination of Hinds and Moreman teaches wherein converting the first data packet into the target format to generate the second data packet includes: determining a data format of the first data packet (see Hinds ¶ [0046] as described for the rejection of claim 5 and is incorporated herein) ; and
in response to the data format being the target format (see Hinds ¶ [0053] as described for the rejection of claim 5 and is incorporated herein), directly converting the first data packet into the second data packet that is transmitted based on the first transmission protocol (see Hinds ¶ [0086] as described for the rejection of claim 5 and is incorporated herein).
In regard to claim 12, the combination of Hinds and Moreman teaches wherein converting the first data packet into the target format to generate the second data packet includes: determining a data format of the first data packet (see Hinds ¶ [0046] as described for the rejection of claim 5 and is incorporated herein); and
in response to the data format being not the target format (see Moreman ¶ [0020] as described for the rejection of claim 6 and is incorporated herein) , converting the first data packet into the target format to obtain the second data packet that is transmitted based on the first transmission protocol (see Moreman ¶ [0021] as described for the rejection of claim 6 and is incorporated herein).
The motivation to combine Moreman with Hinds is described for the rejection of claim 6 and is incorporated herein.
In regard to claim 13, Hinds teaches A data processing system (see abstract “ . . . Aspects of the disclosure provide methods and apparatuses for media processing. In some examples, an apparatus includes processing circuitry. The processing circuitry can exchange, with a server device, a plurality of control messages over a control plane channel that uses a first transport protocol. The plurality of control messages belongs to a control plane of a bidirectional protocol for immersive media distribution . . .”) comprising:
a second server configured to transmit a first data packet to a first server (see ¶ [0086] as described for the rejection in claim 1 and is incorporated herein) using a second transmission protocol (see ¶ [0008] as described for the rejection in claim 1 and is incorporated herein) , the first data packet being generated at least based on data sent by a first-type client and a second-type client (see Fig.1 ¶ [0092] as described for the rejection in claim 1 and is incorporated herein) , the first-type client being configured as a control end (see ¶ [0014] as described for the rejection in claim 1 and is incorporated herein , and the second-type client being configured to interact bidirectionally with the first-type client using a first interaction content (see ¶ [0089] as described for the rejection in claim 1 and is incorporated herein); and
the first server communicatively connected to the second server, using a first transmission protocol (see ¶ [0008] as described for the rejection in claim 1 and is incorporated herein) , and configured to convert the first data packet into a target format to generate a second data packet (see ¶ [0053] ¶ [0083] as described for the rejection in claim 1 and is incorporated herein), (see ¶ [0126] as described for the rejection in claim 1 and is incorporated herein) , and the second transmission protocol being configured as a real-time communication protocol(see ¶ [0138] as described for the rejection in claim 1 and is incorporated herein) ,
Hinds fails to explicitly teach,
However Moreman teaches
the second data packet being configured to be transmittable to a third-type client by the first server (see Morehead ¶ [0018] as described for the rejection in claim 1 and is incorporated herein)
the third-type client being configured to interact at least unidirectionally with the first-type client using a second interaction content, and the first interaction content being different from the second interaction content (see Morehead ¶ [0021] as described for the rejection in claim 1 and is incorporated herein).
The motivation to combine Moreman with Hinds is described for the rejection of claim 1 and is incorporated herein.
In regard to claim 14, the combination of Hinds and Moreman teaches wherein: in a first target scenario, the first-type client is configured to send data to the first server or to the first server and the second server, and the second-type client is configured to send data to the second server (see Hinds ¶ ¶ [0193-0196] as described for the rejection of claim 2 and is incorporated herein).
In regard to claim 15, the combination of Hinds and Moreman teaches wherein: the first server is further configured to obtain a third data packet (e.g. control message) generated from data sent by the first-type client(see Hinds ¶ [0161] as described for the rejection of claim 3 and is incorporated herein) and
convert the third data packet into the target format to generate a fourth data packet that is transmittable by the second server (see Hinds ¶ [0160] as described for the rejection of claim 3 and is incorporated herein); and
the second server is further configured to generate the first data packet based on the fourth data packet (see Hinds ¶ [0164] as described for the rejection of claim 3 and is incorporated herein).
In regard to claim 16, the combination of Hinds and Moreman teaches wherein the second server is further configured to: determine a fifth data packet generated based on data sent by the second-type client to the second server (see Hinds ¶ [0165] as described for the rejection of claim 4 and is incorporated herein); and
generate the first data packet based on the fourth data packet and the fifth data packet(see Fig. 19A Hinds ¶ [0167] as described for the rejection of claim 4 and is incorporated herein)
In regard to claim 17, the combination of Hinds and Moreman teaches wherein the first server is further configured to: determine a data format of the first data packet(see Hinds ¶ [0046] as described for the rejection of claim 5 and is incorporated herein) ; and
in response to the data format being the target format (see Hinds ¶ [0053] as described for the rejection of claim 5 and is incorporated herein) , directly convert the first data packet into the second data packet that is transmitted based on the first transmission protocol (see Hinds ¶ [0086] as described for the rejection of claim 5 and is incorporated herein).
In regard to claim 18, the combination of Hinds and Moreman teaches wherein the first server is further configured to: determine a data format of the first data packet (see Hinds ¶ [0046] as described for the rejection of claim 5 and is incorporated herein) ; and
in response to the data format being not the target format (see Moreman ¶ [0020] as described for the rejection of claim 6 and is incorporated herein), convert the first data packet into the target format to obtain the second data packet that is transmitted based on the first transmission protocol (see Moreman ¶ [0021] as described for the rejection of claim 6 and is incorporated herein)
The motivation to combine Moreman with Hinds is described for the rejection of claim 6 and is incorporated herein.
Claim 19 is rejected under 35 U.S.C. 103 as being unpatentable over Hinds et al. (U.S. 2023/007361 A1; herein referred to as Hinds) in view of Moreman (U.S. 2012/0327780 A1; herein referred to as Moreman) as applied to claims 1 – 18 in further view of Mosko (U.S. 2015/0256460 A1; herein referred to as Mosko).
In regard to claim 19, Hinds teaches A data processing method (see abstract as described for the rejection of claim 1 and is incorporated herein), applied to a first server using a first transmission protocol (see ¶ [0008] as described for the rejection of claim 1 and is incorporated herein), comprising:
obtaining a first data packet transmitted by a second server (see ¶ [0086] as described for the rejection of claim 1 and is incorporated herein) using a second transmission protocol (see ¶ [0008] as described for the rejection of claim 1 and is incorporated herein), the first data packet being generated at least based on data sent by a first-type client and a second-type client (see Fig.1 ¶ [0092] as described for the rejection of claim 1 and is incorporated herein), the first-type client being configured as a control end (see ¶ [0014] as described for the rejection of claim 1 and is incorporated herein) , and the second-type client being configured to interact bidirectionally with the first-type client using a first interaction content (see ¶ [0089] as described for the rejection of claim 1 and is incorporated herein) ; and
converting the first data packet into a target format to generate a second data packet (see ¶ [0053] ¶ [0083] as described for the rejection of claim 1 and is incorporated herein), (see ¶ [0126] as described for the rejection of claim 1 and is incorporated herein), and the second transmission protocol being configured as a real-time communication protocol (see ¶ [0138] ] as described for the rejection of claim 1 and is incorporated herein),
Hinds fails to explicitly teach,
However Moreman teaches
the second data packet being configured to be transmittable to a third-type client by the first server (see Moreman ¶ [0018] as described for the rejection of claim 1 and is incorporated herein)
the third-type client being configured to interact at least unidirectionally with the first-type client using a second interaction content, and the first interaction content being different from the second interaction content (see Moreman ¶ [0021] as described for the rejection of claim 1 and is incorporated herein) ;
The motivation to combine Moreman with Hinds is described for the rejection of claim 1 and is incorporated herein.
The combination of Hinds and Moreman fails to explicitly teach,
However Mosko teaches
wherein: transmitting data using the first transmission protocol has better multi-end performance compared to transmitting data using the second transmission protocol (see ¶ ¶ [0015-0018] “ . . the virtual port group is a multi-path port group generated by a higher-level routing protocol. The system uses the higher-level routing protocol to make forwarding decisions among multiple physical ports associated with the multi-path port group. In a variation on this embodiment, the forwarding strategy specifies that the packet is to be forwarded to each and every port within the first set of physical ports and at least one port within the second set of physical ports. In a further variation, the forwarding strategy further specifies that the packet is to be forwarded to a minimum number of physical ports among ports within the port group. In a variation on this embodiment, a higher-level routing protocol may determine that a specific destination is reachable via several physical or logical ports, such that the destination is represented as a conjunctive term of a disjunction of those physical or logical ports. . . . “); and
transmitting data using the second transmission protocol has better real-time interaction performance compared to transmitting data using the first transmission protocol (see ¶ ¶ [0048-0049] “ . . . If virtual port group 1290 includes a set of ports that are grouped together by the routing protocol as a multi-path group, a different type of scheduler, such as one based on opportunistic multi-path scheduling that favors low-delay high-throughput paths, may be used to distribute the Interest among the multi-path ports. Alternatively, the scheduler may also use a round-robin fashion to distribute Interest packets among the multi-path ports. In certain scenarios, a FIB entry may include both an LAG and a multi-path group, along with one or more physical ports. For example, a FIB entry for a name prefix /def.com may list a group of ports, including ports 7, 22, 1290, and a multi-path port group that includes physical ports 72 and 81. Among them, ports 7 and 22 are physical ports, and port 1290 is a LAG, which includes physical ports 6, 22, and 130. In some embodiments, FIB 302 generates the following forwarding strategy for this name prefix using a formula in conjunctive normal form: (7)(22)(7281)(622130). Note that in this formula the LAG and the multi-path port group are treated similarly as an "OR" being performed over the physical ports within each virtual port group. Note that, even with the three different types of ports or port groups, the expression of the forwarding strategy only involves a two-step recursion, and can be relatively simple to implement. On the other hand, Interest forwarding within each virtual port group is not included in this conjunctive normal form formula. In some embodiments, A LAG scheduler can be used to distribute traffic within each LAG, and a separate scheduler (such as the one defined by the routing protocol that generates the multi-path port group) may be used to distribute traffic within each multi-path port group . . .”).
It would have been obvious to one skilled in the art, before the effective filing date of the applicant’s claimed invention to incorporate a method and system for forwarding packets to a set of port groups and choosing amongst multipath protocols, as taught by Mosko, into a method and system for media processing where the processing provides an exchange, with a server device, a plurality of control messages over a control plane channel that uses a first transport protocol. The plurality of control messages belongs to a control plane of a bidirectional protocol for immersive media distribution. The processing circuitry receives, from the server device, a first plurality of data messages over a first data plane channel that uses a second transport protocol. The first plurality of data messages belongs to a data plane of the bidirectional protocol and carries immersive media content, and the system converts transmission protocols including multicast packet transfer to unicast packet transfer depending upon the type of traffic being transferee and the delivery performance in a streaming scenario, as taught by the combination of Hinds and Morehead. Such incorporation enables choosing a best multi-path protocol for the content being transmitted.
Conclusion
There are prior art made of record which are not relied upon but are considered pertinent to applicant’s disclosure. They are listed on the PTO-892 accompanying this action
Applicant's amendment (e.g. new claim 19) necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JAMES N FIORILLO whose telephone number is (571)272-9909. The examiner can normally be reached on 7:30 - 5 PM Mon - Fri..
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, John A. Follansbee can be reached on 571-272-3964. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/JAMES N FIORILLO/Primary Examiner, Art Unit 2444
Prosecution Insights