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 action is in response to Applicant’s communication filed on 05/18/2026. Claims 7-31 have been examined. Claim 1-6 are cancelled.
Response to Arguments
Applicant’s arguments with respect to claims 7,21,31 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.
With regards to claim objection , Applicant’s amendment overcome the objection. Therefore, the objection is withdrawn.
With regards to 112 2nd rejection , Applicant’s amendment overcome the rejection. Therefore, the rejection is withdrawn.
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 7,8,21,22,31 are rejected under 35 U.S.C. 103 as being unpatentable over Keranen et al. RFC 8445”Interactive Connectivity Establishment (ICE) : A Protocol for Network Address Translator (NAT) Traversal (Keranen hereinafter) in view of Stoica et al. Publication No.US 2024/088609 A1 ( Stoica hereinafter)
Regarding claim 7,
Keranen teaches a method of exchanging media data via a network, the method comprising:
receiving, by a first client device, first data representing a global Internet protocol (IP) address and a local IP address type for a second client device ( Fig.1, Section 2 - each agent has a variety of candidate TRANSPORT ADDRESSES (combination of IP address and port for a particular transport protocol, which is always UDP in this specification) it could use to communicate with the other agent. These might include: A transport address on a directly attached network interface, A translated transport address on the public side of a NAT (a "server reflexive" address) A transport address allocated from a TURN server (a "relayed address") – Section 2.1 - In order to execute ICE, an agent has to identify all of its address candidates. A candidate has a transport address -- a combination of IP address and port for a particular transport protocol (with only UDP specified here). There are different types of candidates; some are derived from physical or logical network interfaces, and others are discoverable via STUN and TURN.- the agent uses STUN or TURN to obtain additional candidates. These come in two flavors: translated addresses on the public side of a NAT (server-reflexive candidates) and addresses on TURN servers (relayed candidates). When TURN servers are utilized, both types of candidates are obtained from the TURN server – Section 4 - Candidate, Candidate Information: A transport address that is a potential point of contact for receipt of data. Candidates also have properties -- their type (server reflexive, relayed, or host), priority, foundation, and base. Note: examiner interprets the local address type as the candidate type which an attribute that tell what type of IP address is and how it was obtained -see Also Section 7.2.5.3.1).
sending, by the first client device, second data representing the global IP address and the local IP address type for the second client device to an intermediate network device between the first client device [..] and the second client device, the second data being sent to the intermediate network device as a destination for the second data, and the second data representing the local IP address type being different than a local IP address of the second client device specified according to the local IP address type (Fig.1 – Section 2 - In addition to the agents, a signaling server and NATs, ICE is typically used in concert with STUN or TURN servers in the network Each agent can have its own STUN or TURN server, or they can be the same – each agent has a variety of candidate transport addresses (combination of IP address and port for a particular transport protocol, which is always UDP in this specification) it could use to communicate with the other agent. These might include: A transport address on a directly attached network interface A translated transport address on the public side of a NAT (a "server-reflexive" address) A transport address allocated from a TURN server (a "relayed address") Potentially, any of L's candidate transport addresses can be used to communicate with any of R's candidate transport addresses - Section 2.1 - The TURN server acts as a packet relay, forwarding traffic between L and R. In order to send traffic to L, R sends traffic to the TURN server at Y:y, and the TURN server forwards that to X1':x1', which passes through the NAT where it is mapped to X:x and delivered to L –– Note: the ICE separate the candidate type from the client internal host interface IP address , When the second data is transmitted to the TURN server , the candidate type represents whether the IP address reflects an internal interface, external Public NAT translation rather than being the address itself) .
receiving, by the first client device, a packet including media data from the second client device via the intermediate network device (Section 2 - Agents L and R are capable of engaging in an candidate exchange process, whose purpose is to set up a data session between L and R –ICE allows the agents to discover enough information about their topologies to potentially find one or more paths by which they can establish a data session. Section 5.3 - Once an agent has sent its candidate information, it MUST be prepared to receive both STUN and data packets on each candidate. As discussed in Section 12.1, data packets can be sent to a candidate prior to its appearance as the default destination for data - Section 12.2- when ICE is used, such changes will sometimes occur as the data streams switch between candidates. An agent will be able to determine that a data stream is from the same peer as a consequence of the STUN exchange that proceeds media data transmission. Thus, if there is a change in the source transport address, but the media data packets come from the same peer agent. –See also Section 17.2.2).
However, Keranen does not explicitly teach
cause the intermediate network device to adjust a protocol data unit (PDU) set size based on the local IP address type
Stoica teaches
cause the intermediate network device to adjust a protocol data unit (PDU) set size based on the local IP address type (Para 0007- receive a first configuration for processing traffic of a media session, the media session being configured with protocol data unit (PDU) set marking including PD U set size information, wherein the first configuration comprises a first indication of an origin internet protocol (IP) version used by a second apparatus to encapsulate the traffic for transport, in the media session, over the wireless communication network; receive a plurality of PDUs of a PDU set of the traffic; compare the received plurality of PDUs to the first configuration, to determine whether the first indication of the origin IP version matches an IP version of the received plurality of PDUs; process the PDU set size information that is available for the plurality of PDUs of the PDU set based on a second configuration, by correcting the PDU set size information and/ or skipping the PD U set size information, if the comparison determines a mismatch between the origin IP version and the IP version of the received plurality of PDUs);
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Keranen to include the teachings of Stoica. The motivation for doing so is to allow the system to potentially correct up to its specific procedures any IP mismatch offsets in the PDU Set Size while translating the PDU Set information to the NG-RAN 5 over GTP-U headers (¶ 0131 – Stoica).
Regarding claim 8,
Keranen in view of Stoica further teaches
wherein the local IP address type comprises one of IP version4 ( IPv4) or IP version 6 (IPv6) (Stoica – Para 0003 - As such, it may well be the case that a sender supporting only IPv4 (or IPv6) calculates the PDU Set Size based on the latter, yet during transport the IP NAT translation leads the 3GPP core network to ingest at the PDU Session Anchor (PSA) user-plane function (UPF) a PDU Set encapsulated with a mismatched IP version, i.e., IPv6 (or Ipv4), respectively).
Regarding claim 21,
Keranen teaches A first client device for exchanging media data via a network, the first client device, the method comprising:
a memory; and a processing system implemented in circuitry and in communication with the memory, the processing system being configured to receive first data representing a global Internet protocol (IP) address and a local IP address type for a second client device ( Fig.1, Section 2 - each agent has a variety of candidate TRANSPORT ADDRESSES (combination of IP address and port for a particular transport protocol, which is always UDP in this specification) it could use to communicate with the other agent. These might include: A transport address on a directly attached network interface, A translated transport address on the public side of a NAT (a "server reflexive" address) A transport address allocated from a TURN server (a "relayed address") – Section 2.1 - In order to execute ICE, an agent has to identify all of its address candidates. A candidate has a transport address -- a combination of IP address and port for a particular transport protocol (with only UDP specified here). There are different types of candidates; some are derived from physical or logical network interfaces, and others are discoverable via STUN and TURN.- the agent uses STUN or TURN to obtain additional candidates. These come in two flavors: translated addresses on the public side of a NAT (server-reflexive candidates) and addresses on TURN servers (relayed candidates). When TURN servers are utilized, both types of candidates are obtained from the TURN server – Section 4 - Candidate, Candidate Information: A transport address that is a potential point of contact for receipt of data. Candidates also have properties -- their type (server reflexive, relayed, or host), priority, foundation, and base. Note: examiner interprets the local address type as the candidate type which an attribute that tell what type of IP address is and how it was obtained -see Also Section 7.2.5.3.1).
send second data representing the global IP address and the local IP address type for the second client device to an intermediate network device between the first client device and the second client device [..], the second data being sent to the intermediate network device as a destination for the second data, and the second data representing the local IP address type being different than a local IP address of the second client device specified according to the local IP address type (Fig.1 – Section 2 - In addition to the agents, a signaling server and NATs, ICE is typically used in concert with STUN or TURN servers in the network Each agent can have its own STUN or TURN server, or they can be the same – each agent has a variety of candidate transport addresses (combination of IP address and port for a particular transport protocol, which is always UDP in this specification) it could use to communicate with the other agent. These might include: A transport address on a directly attached network interface A translated transport address on the public side of a NAT (a "server-reflexive" address) A transport address allocated from a TURN server (a "relayed address") Potentially, any of L's candidate transport addresses can be used to communicate with any of R's candidate transport addresses - Section 2.1 - The TURN server acts as a packet relay, forwarding traffic between L and R. In order to send traffic to L, R sends traffic to the TURN server at Y:y, and the TURN server forwards that to X1':x1', which passes through the NAT where it is mapped to X:x and delivered to L –– Note: the ICE separate the candidate type from the client internal host interface IP address , When the second data is transmitted to the TURN server , the candidate type represents whether the IP address reflects an internal interface, external Public NAT translation rather than being the address itself) .
receive a packet including media data from the second client device via the intermediate network device (Section 2 - Agents L and R are capable of engaging in an candidate exchange process, whose purpose is to set up a data session between L and R –ICE allows the agents to discover enough information about their topologies to potentially find one or more paths by which they can establish a data session. Section 5.3 - Once an agent has sent its candidate information, it MUST be prepared to receive both STUN and data packets on each candidate. As discussed in Section 12.1, data packets can be sent to a candidate prior to its appearance as the default destination for data - Section 12.2- when ICE is used, such changes will sometimes occur as the data streams switch between candidates. An agent will be able to determine that a data stream is from the same peer as a consequence of the STUN exchange that proceeds media data transmission. Thus, if there is a change in the source transport address, but the media data packets come from the same peer agent. –See also Section 17.2.2).
However, Keranen does not explicitly teach
cause the intermediate network device to adjust a protocol data unit (PDU) set size based on the local IP address type
Stoica teaches
cause the intermediate network device to adjust a protocol data unit (PDU) set size based on the local IP address type (Para 0007- receive a first configuration for processing traffic of a media session, the media session being configured with protocol data unit (PDU) set marking including PDU set size information, wherein the first configuration comprises a first indication of an origin internet protocol (IP) version used by a second apparatus to encapsulate the traffic for transport, in the media session, over the wireless communication network; receive a plurality of PDUs of a PDU set of the traffic; compare the received plurality of PDUs to the first configuration, to determine whether the first indication of the origin IP version matches an IP version of the received plurality of PDUs; process the PDU set size information that is available for the plurality of PDUs of the PDU set based on a second configuration, by correcting the PDU set size information and/ or skipping the PD U set size information, if the comparison determines a mismatch between the origin IP version and the IP version of the received plurality of PDUs);
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Keranen to include the teachings of Stoica. The motivation for doing so is to allow the system to potentially correct up to its specific procedures any IP mismatch offsets in the PDU Set Size while translating the PDU Set information to the NG-RAN 5 over GTP-U headers (¶ 0131 – Stoica).
Regarding claim 22,
Keranen in view of Stoica further teaches
wherein the local IP address type comprises one of IP version 4 ( IPv4) or IP version 6 ( IPv6) (Stoica – Para 0003 - As such, it may well be the case that a sender supporting only IPv4 (or IPv6) calculates the PDU Set Size based on the latter, yet during transport the IP NAT translation leads the 3GPP core network to ingest at the PDU Session Anchor (PSA) user-plane function (UPF) a PDU Set encapsulated with a mismatched IP version, i.e., IPv6 (or Ipv4), respectively).
Regarding claim 31,
Keranen teaches a computer-readable storage medium having stored thereon instructions that, when executed, cause a processing system of a first client device to:
receive first data representing a global Internet protocol (IP) address and a local IP address type for a second client device ( Fig.1, Section 2 - each agent has a variety of candidate TRANSPORT ADDRESSES (combination of IP address and port for a particular transport protocol, which is always UDP in this specification) it could use to communicate with the other agent. These might include: A transport address on a directly attached network interface, A translated transport address on the public side of a NAT (a "server reflexive" address) A transport address allocated from a TURN server (a "relayed address") – Section 2.1 - In order to execute ICE, an agent has to identify all of its address candidates. A candidate has a transport address -- a combination of IP address and port for a particular transport protocol (with only UDP specified here). There are different types of candidates; some are derived from physical or logical network interfaces, and others are discoverable via STUN and TURN.- the agent uses STUN or TURN to obtain additional candidates. These come in two flavors: translated addresses on the public side of a NAT (server-reflexive candidates) and addresses on TURN servers (relayed candidates). When TURN servers are utilized, both types of candidates are obtained from the TURN server – Section 4 - Candidate, Candidate Information: A transport address that is a potential point of contact for receipt of data. Candidates also have properties -- their type (server reflexive, relayed, or host), priority, foundation, and base. Note: examiner interprets the local address type as the candidate type which an attribute that tell what type of IP address is and how it was obtained -see Also Section 7.2.5.3.1).
send second data representing the global IP address and the local IP address type for the second client device to an intermediate network device between the first client device and the second client device [..], the second data being sent to the intermediate network device as a destination for the second data, and the second data representing the local IP address type being different than a local IP address of the second client device specified according to the local IP address type (Fig.1 – Section 2 - In addition to the agents, a signaling server and NATs, ICE is typically used in concert with STUN or TURN servers in the network Each agent can have its own STUN or TURN server, or they can be the same – each agent has a variety of candidate transport addresses (combination of IP address and port for a particular transport protocol, which is always UDP in this specification) it could use to communicate with the other agent. These might include: A transport address on a directly attached network interface A translated transport address on the public side of a NAT (a "server-reflexive" address) A transport address allocated from a TURN server (a "relayed address") Potentially, any of L's candidate transport addresses can be used to communicate with any of R's candidate transport addresses - Section 2.1 - The TURN server acts as a packet relay, forwarding traffic between L and R. In order to send traffic to L, R sends traffic to the TURN server at Y:y, and the TURN server forwards that to X1':x1', which passes through the NAT where it is mapped to X:x and delivered to L –– Note: the ICE separate the candidate type from the client internal host interface IP address , When the second data is transmitted to the TURN server , the candidate type represents whether the IP address reflects an internal interface, external Public NAT translation rather than being the address itself) .
receive a packet including media data from the second client device via the intermediate network device (Section 2 - Agents L and R are capable of engaging in an candidate exchange process, whose purpose is to set up a data session between L and R –ICE allows the agents to discover enough information about their topologies to potentially find one or more paths by which they can establish a data session. Section 5.3 - Once an agent has sent its candidate information, it MUST be prepared to receive both STUN and data packets on each candidate. As discussed in Section 12.1, data packets can be sent to a candidate prior to its appearance as the default destination for data - Section 12.2- when ICE is used, such changes will sometimes occur as the data streams switch between candidates. An agent will be able to determine that a data stream is from the same peer as a consequence of the STUN exchange that proceeds media data transmission. Thus, if there is a change in the source transport address, but the media data packets come from the same peer agent. –See also Section 17.2.2).
However, Keranen does not explicitly teach
cause the intermediate network device to adjust a protocol data unit (PDU) set size based on the local IP address type
Stoica teaches
cause the intermediate network device to adjust a protocol data unit (PDU) set size based on the local IP address type (Para 0007- receive a first configuration for processing traffic of a media session, the media session being configured with protocol data unit (PDU) set marking including PD U set size information, wherein the first configuration comprises a first indication of an origin internet protocol (IP) version used by a second apparatus to encapsulate the traffic for transport, in the media session, over the wireless communication network; receive a plurality of PDUs of a PDU set of the traffic; compare the received plurality of PDUs to the first configuration, to determine whether the first indication of the origin IP version matches an IP version of the received plurality of PDUs; process the PDU set size information that is available for the plurality of PDUs of the PDU set based on a second configuration, by correcting the PDU set size information and/ or skipping the PD U set size information, if the comparison determines a mismatch between the origin IP version and the IP version of the received plurality of PDUs);
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Keranen to include the teachings of Stoica. The motivation for doing so is to allow the system to potentially correct up to its specific procedures any IP mismatch offsets in the PDU Set Size while translating the PDU Set information to the NG-RAN 5 over GTP-U headers (¶ 0131 – Stoica).
Claims 9,10 are rejected under 35 U.S.C. 103 as being unpatentable over Keranen in view of Stoica further in view of Cagenius et al. Publication No. US 2009/0083426 A1 (Cagenius hereinafter) .
Regarding claim 9,
Keranen further teaches
wherein the second data representing the local IP address type [..] for a media communication session between the first client device and the second client device (Section 2, Section 12.2, Section 5.3 )
However, Keranen does not explicitly teach that the second data includes session information
Cagenius teaches
the data includes session information( ¶0029 - Session specific information may be stored in a session mapping table, which can be used for further signaling related to the session. The session specific information may include a Call ID defining the session, a local IP address and selected port of said at least one device, a reserved port of a residential gateway of the private network, and an IP address of a remote party- ¶0036 -The session specific information may include a Call ID defining the session, a local IP address and selected port of said at least one device, a reserved port of a residential gate way of the private network, and an IP address of a remote party. – See Also ¶0058).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Keranen to include the teachings of Cagenius. The motivation for doing so is to allow the system to enable multimedia communication by means of a multimedia gateway connected to a multimedia service network (¶ 0001 – Cagenius).
Regarding claim 10,
Keranen does not explicitly teach wherein the session information comprises a session identifier.
However, Cagenius teaches
wherein the session information comprises a session identifier (¶ 0029 - Session specific information may be stored in a session mapping table, which can be used for further signaling related to the session. The session specific information may include a Call ID defining the session, a local IP address and selected port of said at least one device, a reserved port of a residential gateway of the private network, and an IP address of a remote party- ¶0036 -The session specific information may include a Call ID defining the session, a local IP address and selected port of said at least one device, a reserved port of a residential gate way of the private network, and an IP address of a remote party. – See Also ¶0058).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Keranen to include the teachings of Cagenius. The motivation for doing so is to allow the system to enable multimedia communication by means of a multimedia gateway connected to a multimedia service network (¶ 0001 – Cagenius).
Claims 11,12,14-17,24-27 are rejected under 35 U.S.C. 103 as being unpatentable over Keranen in view of Stoica in view of Handley et al. “SDP: Session Description Protocol” RFC 4566 – July 2006 (Handley hereinafter)
Regarding claim 11,
Keranen further teaches
wherein the second data representing the local IP address type [..] for a network connecting the first client device and the second client device. (Section 2, Section 12.2, Section 5.3 )
However, Keranen does not explicitly teach that the data representing the local IP address type includes a network type for a network
Handley teaches
data representing the local IP address type includes a network type for a network ( Introduction - When initiating multimedia teleconferences, voice-over-IP calls, streaming video, or other sessions, there is a requirement to convey media details, transport addresses, and other session description metadata to the participants -Section 5.2 - o=<username> <sess-id> <sess-version> <nettype> <addrtype> <unicast-address. <nettype> is a text string giving the type of network. Initially "IN" is defined to have the meaning "Internet", but other values MAY be registered in the future (see Section 8) – Section 4.7 - . Connection Data ("c=")
c=<nettype> <addrtype> <connection-address. The first sub-field ("<nettype>") is the network type, which is a text string giving the type of network. Initially, "IN" is defined to have the meaning "Internet" – Page 10 shows an example of SDP description that include local IP address type (IPv4), and network type ( IN) ).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Keranen to include the teachings of Handley. The motivation for doing so is to allow the system to identify the underlying network environment during the transition between different IP infrastructures.
Regarding claim 12,
Keranen does not explicitly teach wherein the network type comprises one of Internet or Ethernet
However, Handley teaches
wherein the network type comprises one of Internet or Ethernet ( Introduction - When initiating multimedia teleconferences, voice-over-IP calls, streaming video, or other sessions, there is a requirement to convey media details, transport addresses, and other session description metadata to the participants -Section 5.2 - o=<username> <sess-id> <sess-version> <nettype> <addrtype> <unicast-address. <nettype> is a text string giving the type of network. Initially "IN" is defined to have the meaning "Internet", but other values MAY be registered in the future (see Section 8) – Section 4.7 - . Connection Data ("c=") c=<nettype> <addrtype> <connection-address. The first sub-field ("<nettype>") is the network type, which is a text string giving the type of network. Initially, "IN" is defined to have the meaning "Internet" – Page 10 shows an example of SDP description that include local IP address type (IPv4), and network type ( IN) ).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Keranen to include the teachings of Handley. The motivation for doing so is to allow the system to identify the underlying network environment during the transition between different IP infrastructures.
Regarding claim 14,
Keranen further teaches
wherein receiving the first data representing the local IP address type comprises receiving one or more [..] attributes representing the local IP address type (Section 2, Section 12.2, Section 5.3 )
However, Keranen does not explicitly teach the one or more attributes are one or more SDP attributes, each of the SDP attributes being in the format "a=<attribute>:<value>."
Handley teaches
one or more SDP attributes, each of the SDP attributes being in the format "a=<attribute>:<value>." (Page 9 - a=* (zero or more session attribute lines) – Section 5.13 - Attributes ("a=") a=<attribute> a=<attribute>:<value> Attributes are the primary means for extending SDP. Attributes may be defined to be used as "session-level" attributes, "media-level" attributes, or both. media description may have any number of attributes ("a=" fields) that are media specific. These are referred to as "media-level" attributes and add information about the media stream. Attribute fields can also be added before the first media field; these "session-level" attributes convey additional information that applies to the conference as a whole rather than to individual media).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Keranen to include the teachings of Handley. The motivation for doing so is to allow the system to extend SDP and tailoring it to particular applications or media (Handley – Page 9).
Regarding claim 15,
Keranen further teaches
wherein receiving the first data representing the local IP address type includes receiving [..] attributes specifying the local IP address type, and a local IP address (Section 2, Section 12.2, Section 5.3 )).
However, Keranen does not explicitly teach that the attributes are an SDP attribute specifying each of a session identifier, a network type, the local IP address type, and a local IP address
Handley teaches
SDP attribute specifying each of a session identifier, a network type, the local IP address type, and a local IP address( Introduction - When initiating multimedia teleconferences, voice-over-IP calls, streaming video, or other sessions, there is a requirement to convey media details, transport addresses, and other session description metadata to the participants -Section 5.2 - o=<username> <sess-id> <sess-version> <nettype> <addrtype> <unicast-address. <nettype> is a text string giving the type of network. Initially "IN" is defined to have the meaning "Internet", but other values MAY be registered in the future (see Section 8) – Section 4.7 - . Connection Data ("c=") c=<nettype> <addrtype> <connection-address. The first sub-field ("<nettype>") is the network type, which is a text string giving the type of network. Initially, "IN" is defined to have the meaning "Internet" – Page 10 shows an example of SDP description that include local IP address type (IPv4), and network type ( IN) ).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Keranen to include the teachings of Handley. The motivation for doing so is to allow the system to identify the underlying network environment during the transition between different IP infrastructures.
Regarding claim 16,
Keranen further teaches
wherein receiving the first data representing the local IP address type includes receiving an [..] attribute (Section 2, Section 12.2, Section 5.3 ).
However, Keranen does not explicitly teach
an SDP attribute of the form "a=localAddr: <sess-id><nettype><addrtype><address>," wherein <sess-id> represents a unique identifier for a session between the first client device and the second client device, <nettype> represents a network type for a network connecting the first client device and the second client device, <addrtype> represents the local IP address type, and <address> represents a local IP address.
Handley teaches
an SDP attribute of the form "a=localAddr: <sess-id><nettype><addrtype><address>," wherein <sess-id> represents a unique identifier for a session between the first client device and the second client device, <nettype> represents a network type for a network connecting the first client device and the second client device, <addrtype> represents the local IP address type, and <address> represents a local IP address ( Introduction - When initiating multimedia teleconferences, voice-over-IP calls, streaming video, or other sessions, there is a requirement to convey media details, transport addresses, and other session description metadata to the participants -Section 5.2 - o=<username> <sess-id> <sess-version> <nettype> <addrtype> <unicast-address. <nettype> is a text string giving the type of network. Initially "IN" is defined to have the meaning "Internet", but other values MAY be registered in the future (see Section 8) – Section 4.7 - . Connection Data ("c=") c=<nettype> <addrtype> <connection-address. The first sub-field ("<nettype>") is the network type, which is a text string giving the type of network. Initially, "IN" is defined to have the meaning "Internet" – Section 5.13 -attributes (“a=” ) - Attributes are the primary means for extending SDP. Attributes may be defined to be used as "session-level" attributes, "media-level" attributes, or both. A media description may have any number of attributes ("a=" fields) that are media specific. These are referred to as "media-level" attributes and add information about the media stream. Attribute fields can also be added before the first media field; these "session-level" attributes convey additional information that applies to the conference as a whole rather than to individual media).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Keranen to include the teachings of Handley. The motivation for doing so is to allow the system to identify the underlying network environment during the transition between different IP infrastructures.
Since Handley teaches the “a=” attributes is defined to be used as session level attributes and media level attributes. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Keranen in view of Handley to include an SDP attribute of the form "a=” instead of “o=” The motivation for doing so is to allow the system to add custom parameters without breaking older implementation.
Regarding claim 17,
Keranen further teaches
wherein receiving the first data representing the local IP address type includes (Section 2, Section 12.2, Section 5.3 )
However, Keranen does not explicitly teach
receiving a line of the SDP message is in the form of "l = <sesid> <nettype> <addrtype> <address>," wherein <sess-id> represents a unique identifier for a session between the first client device and the second client device, <nettype> represents a network type for a network connecting the first client device and the second client device, <addrtype> represents the local IP address type, and <address> represents a local IP address
Handley teaches
receiving a line of the SDP message is in the form of "l = <sesid> <nettype> <addrtype> <address>," wherein <sess-id> represents a unique identifier for a session between the first client device and the second client device, <nettype> represents a network type for a network connecting the first client device and the second client device, <addrtype> represents the local IP address type, and <address> represents a local IP address ( Introduction - When initiating multimedia teleconferences, voice-over-IP calls, streaming video, or other sessions, there is a requirement to convey media details, transport addresses, and other session description metadata to the participants -Section 5.2 - o=<username> <sess-id> <sess-version> <nettype> <addrtype> <unicast-address. <nettype> is a text string giving the type of network. Initially "IN" is defined to have the meaning "Internet", but other values MAY be registered in the future (see Section 8) – Section 4.7 - . Connection Data ("c=") c=<nettype> <addrtype> <connection-address. The first sub-field ("<nettype>") is the network type, which is a text string giving the type of network. Initially, "IN" is defined to have the meaning "Internet" –Section 5.4 - The "i=" field provides textual information about the session. There MUST be at most one session-level "i=" field per session description, and at most one "i=" field per media. If the "a=charset" attribute is present, The "i=" field is intended to provide a free-form human-readable description of the session or the purpose of a media stream ).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Keranen to include the teachings of Handley. The motivation for doing so is to allow the system to identify the underlying network environment during the transition between different IP infrastructures.
Since Handley teaches the “I=” provides textual information about the session. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Keranen in view of Handley to include "I =” instead of “o=” The motivation for doing so is to allow the system to provide free human-readable description of the session (Handley – Section 5.4).
Regarding claim 24,
Keranen further teaches
wherein receiving the first data representing the local IP address type comprises receiving one or more [..] attributes representing the local IP address type (Section 2, Section 12.2, Section 5.3 ).
However, Keranen does not explicitly teach the one or more SDP attributes, each of the SDP attributes being in the format "a=<attribute>:<value>."
Handley teaches
one or more SDP attributes, each of the SDP attributes being in the format "a=<attribute>:<value>." (Page 9 - a=* (zero or more session attribute lines) – Section 5.13 - Attributes ("a=") a=<attribute> a=<attribute>:<value> Attributes are the primary means for extending SDP. Attributes may be defined to be used as "session-level" attributes, "media-level" attributes, or both. media description may have any number of attributes ("a=" fields) that are media specific. These are referred to as "media-level" attributes and add information about the media stream. Attribute fields can also be added before the first media field; these "session-level" attributes convey additional information that applies to the conference as a whole rather than to individual media).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Keranen to include the teachings of Handley. The motivation for doing so is to allow the system to extend SDP and tailoring it to particular applications or media (Handley – Page 9).
Regarding claim 25,
Keranen further teaches
wherein receiving the first data representing the local IP address type includes receiving an SDP attributes specifying the local IP address type, and a local IP address (Section 2, Section 12.2, Section 5.3 )
However, Keranen does not explicitly teach SDP attribute specifying each of a session identifier, a network type, the local IP address type, and a local IP address
Handley teaches
SDP attribute specifying each of a session identifier, a network type, the local IP address type, and a local IP address( Introduction - When initiating multimedia teleconferences, voice-over-IP calls, streaming video, or other sessions, there is a requirement to convey media details, transport addresses, and other session description metadata to the participants -Section 5.2 - o=<username> <sess-id> <sess-version> <nettype> <addrtype> <unicast-address. <nettype> is a text string giving the type of network. Initially "IN" is defined to have the meaning "Internet", but other values MAY be registered in the future (see Section 8) – Section 4.7 - . Connection Data ("c=") c=<nettype> <addrtype> <connection-address. The first sub-field ("<nettype>") is the network type, which is a text string giving the type of network. Initially, "IN" is defined to have the meaning "Internet" – Page 10 shows an example of SDP description that include local IP address type (IPv4), and network type ( IN) ).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Keranen to include the teachings of Handley. The motivation for doing so is to allow the system to identify the underlying network environment during the transition between different IP infrastructures.
Regarding claim 26,
Keranen further teaches
wherein to receive the first data representing the local IP address type, the processing system is configured to receive an [..] attribute (Section 2, Section 12.2, Section 5.3 )
However, Keranen does not explicitly teach
an SDP attribute of the form "a=localAddr: <sess-id><nettype><addrtype><address>," wherein <sess-id> represents a unique identifier for a session between the first client device and the second client device, <nettype> represents a network type for a network connecting the first client device and the second client device, <addrtype> represents the local IP address type, and <address> represents a local IP address.
Handley teaches
an SDP attribute of the form "a=localAddr: <sess-id><nettype><addrtype><address>," wherein <sess-id> represents a unique identifier for a session between the first client device and the second client device, <nettype> represents a network type for a network connecting the first client device and the second client device, <addrtype> represents the local IP address type, and <address> represents a local IP address ( Introduction - When initiating multimedia teleconferences, voice-over-IP calls, streaming video, or other sessions, there is a requirement to convey media details, transport addresses, and other session description metadata to the participants -Section 5.2 - o=<username> <sess-id> <sess-version> <nettype> <addrtype> <unicast-address. <nettype> is a text string giving the type of network. Initially "IN" is defined to have the meaning "Internet", but other values MAY be registered in the future (see Section 8) – Section 4.7 - . Connection Data ("c=") c=<nettype> <addrtype> <connection-address. The first sub-field ("<nettype>") is the network type, which is a text string giving the type of network. Initially, "IN" is defined to have the meaning "Internet" – Section 5.13 -attributes (“a=” ) - Attributes are the primary means for extending SDP. Attributes may be defined to be used as "session-level" attributes, "media-level" attributes, or both. A media description may have any number of attributes ("a=" fields) that are media specific. These are referred to as "media-level" attributes and add information about the media stream. Attribute fields can also be added before the first media field; these "session-level" attributes convey additional information that applies to the conference as a whole rather than to individual media).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Keranen to include the teachings of Handley. The motivation for doing so is to allow the system to identify the underlying network environment during the transition between different IP infrastructures.
Since Handley teaches that the “a=” attributes is defined to be used as session level attributes and media level attributes. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Keranen in view of Handley to include an SDP attribute of the form "a=” instead of “o=” The motivation for doing so is to allow the system to add custom parameters without breaking older implementation.
Regarding claim 27,
Keranen further teaches
Wherein to receive the first data representing the local IP address type the processing system is configured to (Section 2, Section 12.2, Section 5.3 )
However, Keranen does not explicitly teach
receiving line of the SDP message is in the form of "l = <sesid> <nettype> <addrtype> <address>," wherein <sess-id> represents a unique identifier for a session between the first client device and the second client device, <nettype> represents a network type for a network connecting the first client device and the second client device, <addrtype> represents the local IP address type, and <address> represents a local IP address
Handley teaches
receiving line of the SDP message is in the form of "l = <sesid> <nettype> <addrtype> <address>," wherein <sess-id> represents a unique identifier for a session between the first client device and the second client device, <nettype> represents a network type for a network connecting the first client device and the second client device, <addrtype> represents the local IP address type, and <address> represents a local IP address ( Introduction - When initiating multimedia teleconferences, voice-over-IP calls, streaming video, or other sessions, there is a requirement to convey media details, transport addresses, and other session description metadata to the participants -Section 5.2 - o=<username> <sess-id> <sess-version> <nettype> <addrtype> <unicast-address. <nettype> is a text string giving the type of network. Initially "IN" is defined to have the meaning "Internet", but other values MAY be registered in the future (see Section 8) – Section 4.7 - . Connection Data ("c=") c=<nettype> <addrtype> <connection-address. The first sub-field ("<nettype>") is the network type, which is a text string giving the type of network. Initially, "IN" is defined to have the meaning "Internet" –Section 5.4 - The "i=" field provides textual information about the session. There MUST be at most one session-level "i=" field per session description, and at most one "i=" field per media. If the "a=charset" attribute is present, The "i=" field is intended to provide a free-form human-readable description of the session or the purpose of a media stream ).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Keranen to include the teachings of Handley. The motivation for doing so is to allow the system to identify the underlying network environment during the transition between different IP infrastructures.
Since Handley teaches the “I=” provides textual information about the session. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Keranen in view of Handley to include "I =” instead of “o=”. The motivation for doing so is to allow the system to provide free human -readable description of the session (Handley – Section 5.4).
Claims 13,23 are rejected under 35 U.S.C. 103 as being unpatentable over Keranen in view of Stoica in view of Yoshiuchi et al. Publication No. CN 101047548 A ( Yoshiuchi hereinafter)
Regarding claim 13,
Keranen further teaches
wherein the second data representing the local IP address type (Section 2, Section 12.2, Section 5.3 )
However, Keranen does not explicitly teach data representing the local IP address type further includes at least one of an Ethernet address or a media access control (MAC) address for the second client device
Yoshiuchi teaches
data representing the local IP address type further includes at least one of an Ethernet address or a media access control (MAC) address for the second client device (Page 6 -VoIP client 1 uses SDP extension in INVITE message body, which contains MAC address and private IP address. The INVITE message is forwarded to the proxy server – Page 7 - . By detecting the MAC address encapsulated in the INVITE message body of the VoIP client. the VoIP client checks whether the VoIP client exists in the private network . The detection process can use technologies. In the case where there is a third-layer switch or router in the private network, the detection process can use the ARP proxy technology).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Keranen to include the teachings of Yoshiuchi. The motivation for doing so is to allow the system to uniquely identify devices in local area networks .
Regarding claim 23,
Keranen further teaches
wherein the second data representing the local IP address type (Section 2, Section 12.2, Section 5.3 )
However, Keranen does not explicitly teach data representing the local IP address type further includes at least one of an Ethernet address or a media access control (MAC) address for the second client device
Yoshiuchi teaches
data representing the local IP address type further includes at least one of an Ethernet address or a media access control (MAC) address for the second client device (Page 6 -VoIP client 1 uses SDP extension in INVITE message body, which contains MAC address and private IP address. The INVITE message is forwarded to the proxy server – Page 7 - . By detecting the MAC address encapsulated in the INVITE message body of the VoIP client. the VoIP client checks whether the VoIP client exists in the private network . The detection process can use technologies. In the case where there is a third-layer switch or router in the private network, the detection process can use the ARP proxy technology).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Keranen to include the teachings of Yoshiuchi. The motivation for doing so is to allow the system to uniquely identify devices in local area networks .
Claims 18,28 are rejected under 35 U.S.C. 103 as being unpatentable over Keranen in view of Stoica further in view of Camarillo et al. “The Alternative Network Address Types (ANAT) Semantics for the Session Description Protocol (SDP) Grouping Framework” RFC 4091 -June 2005 (Camarillo hereinafter)
Regarding claim 18,
Keranen does not explicitly teach
determining whether the local IP address type applies to an entire session or a media stream of the session, including: when the local IP address type is specified before an "m=" line of a session description protocol (SDP) message, determining that the local IP address type applies to the entire session; or when the local IP address type is specified after the "m=" line of the SDP message, determining that the local IP address type applies to the media stream of the session.
However, Camarillo teaches
determining whether the local IP address type applies to an entire session or a media stream of the session, including: when the local IP address type is specified before an "m=" line of a session description protocol (SDP) message, determining that the local IP address type applies to the entire session; or when the local IP address type is specified after the "m=" line of the SDP message, determining that the local IP address type applies to the media stream of the session ( Section 1 - For a particular media stream, an SDP session description contains, among other parameters, the network addresses and the codec to be used in transferring media. SDP allows for a set of codecs per media stream, but only one network address – The ANAT semantics allow for the expression of alternative network addresses (e.g., different IP versions) for a particular media stream - Section 1.1 - We have chosen to group ’m’ lines with different IP versions at the ’m’ level (ANAT semantics) his yields a syntax much closer to vanilla SDP, where IPv6 addresses are defined in their own ’m’ line, rather than in parameters belonging to a different ’m’ line – Section 3 - Media lines grouped using ANAT semantics provide alternative network addresses of different types for a single logical media stream – Section 6 provide SDP example that shows how IP addresses are associated with media streams. The connection information (c=) containing the local IP address type is placed after the media (m=) line to specify that the address for that particular stream).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Keranen to include the teachings of Camarillo. The motivation for doing so is to allow the system to provide alternative network addresses of different types for a single logical media stream (Camarillo – Section 3).
Regarding claim 28,
Keranen does not explicitly teach
wherein the processing system is further configured to determine whether the local IP address type applies to an entire session or a media stream of the session, including: when the local IP address type is specified before an "m=" line of a session description protocol (SDP) message, determining that the local IP address type applies to the entire session; or when the local IP address type is specified after the "m=" line of the SDP message, determining that the local IP address type applies to the media stream of the session.
However, Camarillo teaches
wherein the processing system is further configured to determine whether the local IP address type applies to an entire session or a media stream of the session, including: when the local IP address type is specified before an "m=" line of a session description protocol (SDP) message, determining that the local IP address type applies to the entire session; or when the local IP address type is specified after the "m=" line of the SDP message, determining that the local IP address type applies to the media stream of the session ( Section 1 - For a particular media stream, an SDP session description contains, among other parameters, the network addresses and the codec to be used in transferring media. SDP allows for a set of codecs per media stream, but only one network address – The ANAT semantics allow for the expression of alternative network addresses (e.g., different IP versions) for a particular media stream - Section 1.1 - We have chosen to group ’m’ lines with different IP versions at the ’m’ level (ANAT semantics) his yields a syntax much closer to vanilla SDP, where IPv6 addresses are defined in their own ’m’ line, rather than in parameters belonging to a different ’m’ line – Section 3 - Media lines grouped using ANAT semantics provide alternative network addresses of different types for a single logical media stream – Section 6 provide SDP example that shows how IP addresses are associated with media streams. The connection information (c=) containing the local IP address type is placed after the media (m=) line to specify that the address for that particular stream).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Keranen to include the teachings of Camarillo. The motivation for doing so is to allow the system to provide alternative network addresses of different types for a single logical media stream (Camarillo – Section 3).
Claims 19,29 are rejected under 35 U.S.C. 103 as being unpatentable over Keranen in view of Stoica further in view of Perumal et al. Publication No. US 2010/0293297 A1 ( Perumal hereinafter)
Regarding claim 19,
Keranen further teaches
wherein receiving the first data representing the local IP address type comprises receiving the first data representing the local IP address type (Section 2, Section 12.2, Section 5.3 )
.
However, Keranen does not explicitly teach data representing the local IP address type in at least one of a session description protocol (SDP) Offer message or an SDP Answer message.
Perumal teaches
data representing the local IP address type in at least one of a session description protocol (SDP) Offer message or an SDP Answer message ( ¶ 0034 - The ANAT endpoint 110 may be operable to communicate with the session border controller 130. Communication may include transmitting and/or receiving an ANAT message. The ANAT message may be an offer message, request message, or an answer message. ¶0035 - The ANAT endpoint 110 may include all, some, or none of the network address descriptions A1, A2 in a session description of the ANAT message. As a result, the ANAT message may include a list of the network addresses 210, IP versions 220, priority identifiers 230, or any combination thereof. The session description may describe multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation or multimedia session establishment).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Keranen to include the teachings of Perumal. The motivation for doing so is to allow the system to negotiate a media stream path between endpoints ( Perumal – ¶0001).
Regarding claim 29,
Keranen further teaches
wherein receiving the first data representing the local IP address type, the processing system is configured to receive the first data representing the local IP address type (Section 2, Section 12.2, Section 5.3 )
However, Keranen does not explicitly teach data representing the local IP address type in at least one of a session description protocol (SDP) Offer message or an SDP Answer message.
Perumal teaches
data representing the local IP address type in at least one of a session description protocol (SDP) Offer message or an SDP Answer message ( ¶ 0034 - The ANAT endpoint 110 may be operable to communicate with the session border controller 130. Communication may include transmitting and/or receiving an ANAT message. The ANAT message may be an offer message, request message, or an answer message. ¶0035 - The ANAT endpoint 110 may include all, some, or none of the network address descriptions A1, A2 in a session description of the ANAT message. As a result, the ANAT message may include a list of the network addresses 210, IP versions 220, priority identifiers 230, or any combination thereof. The session description may describe multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation or multimedia session establishment).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Keranen to include the teachings of Perumal. The motivation for doing so is to allow the system to negotiate a media stream path between endpoints ( Perumal – ¶0001).
Claims 20,30 are rejected under 35 U.S.C. 103 as being unpatentable over Keranen in view of Stoica further in view of Liu et al. Publication No. US 2024/0276183 A1 ( Liu hereinafter)
Regarding claim 20,
Keranen further teaches wherein the intermediate network device comprises a device [..] Fig1, Section 2). However, Keranen does not explicitly teach
a device that provides a cellular network Application Function (AF).
Liu teaches
a device that provides a cellular network Application Function (AF) (¶0009 - FIG. 2 further comprises an Application Function (AF) 220 that interacts with the 3GPP Core Network in order to provide services, for example to support interactions between the 5GC and an Internet Protocol (IP) Multimedia Subsystem or IP Multimedia Core Network Subsystem (IMS). Thus, the AF 220 may support IP-based multimedia services for the UE 12). .
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Keranen to include the teachings of Liu. The motivation for doing so is to allow the system to utilize the AF in order to enable, control and optimize services through direct interaction with the 5G core network.
Regarding claim 30,
Keranen further teaches wherein the intermediate network device comprises a device [..] (Fig.1, Section 2).
However, Keranen does not explicitly teach
a device that provides a cellular network Application Function (AF).
Liu teaches
a device that provides a cellular network Application Function (AF) (¶0009 - FIG. 2 further comprises an Application Function (AF) 220 that interacts with the 3GPP Core Network in order to provide services, for example to support interactions between the 5GC and an Internet Protocol (IP) Multimedia Subsystem or IP Multimedia Core Network Subsystem (IMS). Thus, the AF 220 may support IP-based multimedia services for the UE 12). .
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Keranen to include the teachings of Liu. The motivation for doing so is to allow the system to utilize the AF in order to enable, control and optimize services through direct interaction with the 5G core network.
Conclusion
Applicant's amendment 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 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 YOUNES NAJI whose telephone number is (571)272-2659. The examiner can normally be reached Monday - Friday 8:30 AM -5:30 PM.
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, Oscar A Louie can be reached at (571) 270-1684. 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.
/YOUNES NAJI/Primary Examiner, Art Unit 2445
Prosecution Insights