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 01/12/2026. Claims 7-31 have been examined. Claim 1-6 are cancelled. Claim 31 is new.
With regards to Restriction, Applicant elects Group II ( claims 7-30) without traverse.
Information Disclosure Statement
The information disclosure statements (IDSs) submitted on 06/04/2025,01/24/2025.The submissions are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered by the examiner.
Examiner Note: With regards to 101 analysis for a computer readable storage medium with regards to claim 31. The examiner checked the specification in ¶0161which recites " It should be understood, however, that computer-readable storage media and data storage media do not include connections, carrier waves, signals, or other transitory media, but are instead directed to non-transitory, tangible storage media". Therefore, based on the specification, the claim 31 is directed to statutory subject matter.
Claim Objections
Claims 8, 21-22 are objected to because of the following informalities:
With regards to claims 8,22, the claim limitations contain the undefined abbreviation and/or acronym “IPv4”, “IPv6”. Abbreviation /acronym must be defined at least one in the claims.
With regards to claim 21, the claim recites “ receive, by the first client device, a packet .”. Examiner suggests amending the claim to recite “ receive a packet” since the claim is already directed to the client device.
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 9,11,13,23 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
With regards to claim 9,11,13, the claims recite “the data”. It is unclear what the data is referring to because claim 7 which claims 9,11,13 depends on recites “data” in the receiving limitation and “data” in the sending limitation. Therefore, the examine is unable to determine the metes and bounds of the claim language. With regards to claim 23, the claim recites “the data”. It is unclear what the data is referring to because claim 21 which claim 23 depends on recite “data” in the receiving limitation and “data” in the sending limitation. Therefore, the examine is unable to determine the metes and bounds of the claim language.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 7,8,21,22,31 are rejected under 35 U.S.C. 102 (a1) as being anticipated by Toebes et al. Patent No. US 7,764,686 B1 (Toebes hereinafter)
Regarding claim 7,
Toebes teaches a method of exchanging media data via a network (col. 5, lines 19-24,), the method comprising:
receiving, by a first client device, data representing a global Internet protocol (IP) address and a local IP address type for a second client device (Col. 5, lines 5 - 47 - client outside the realm seeking to resolve a name in the form LOCALDNS@REALMNAME will first send a request to its global DNS server requesting a record for REALMNAME. What will be returned will be a globally significant IP address for REALMNAME plus an address for a DNS server. The DNS server address will typically be a locally significant IPv4 address for the DNS server within the target realm. Using both addresses, the client contacts this latter DNS server to resolve LOCAL-DNS to a locally significant address. With the locally significant address and the globally significant realm address, the client has the information to populate the destination fields of packet 300.At a step 402, the client node resolves a destination name to a globally significant realm IP address as described above or by some other technique. At a step 404, the client node resolves the destination name to a locally significant IP address. The local destination IP address is obtained from the result of step 404. The globally significant destination realm IP address is obtained from the result of step 402; - for voice over IP (VoIP) applications, SIP may be used to resolve a single phone number to a combination of globally significant realm address and locally significant node address. Col. 9, lines 15-20 - host A 702 could be modified to perform the global two-part DNS resolution and to perform the encapsulation of FIG. 3 – See Fig.3&4);
sending, by the first client device, 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 (col. 5. Lines 25-47 At a step 406, the client forms a packet in the form illustrated in FIG. 3. The local destination IP address 312 is obtained from the result of step 404. The globally significant destination realm IP address is obtained from the result of step 402. The packet is transmitted at step 408 . Col. 7, line 65-70 -: Host A 602 then establishes an automatic stateless tunnel to realm gateway 614. The tunnel is implemented simply by encapsulation in the packet format of FIG. 3 as performed by host A 602 - Col. 8, line 20 - With step 808, host A 602 forms an encapsulated packet and transmits it...At step 810, realm gateway 614 receives the packet..."; See Also figures 3, 6, 8); and
receiving, by the first client device, a packet including media data from the second client device via the intermediate network device (col. 5, lines 19-24: - for voice over IP (VoIP) applications, SIP may be used ; Col. 8, lines 20-60: host B 604 transmitting a response packet back to host A 602. At step 812, host B 604 transmits a response back to host A 602. The response is an IPv6 packet with the IPv6 destination address being source IPv6 address of the packet that host B 604 has- the FIG. 9 is a flow chart describing operations in exchanging packets between host B 604 and host A 602 at the initiation of host B 604 At step 904, host B 604 forwards a packet using the IPv6 address obtained in step 902. At step 910, the packet reaches realm gateway 612. Realm gateway 612 then swaps the encapsulation IP header 304 and the inner IP header 306 so that further forwarding to host A 602 via private IPv4+ network 606 is based on the locally significant address HA).
Regarding claim 8,
Toebes further teaches
wherein the local IP address type comprises one of IPv4 or IPv6 (Col.3, lines 60-65 -Each of realms 202 incorporates a cloud of network nodes having an IPv4 address unique within that realm but not globally unique – Col.4, lines 10-12 - Each node within one of realms 202 has a globally unique "address" that consists of a concatenation of its realm's globally significant IPv4 address and its own locally unique IPv4 address).
Regarding claim 21,
Toebes teaches A first client device for exchanging media data via a network, the first client device (col. 5, lines 19-24,), 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 data representing a global Internet protocol (IP) address and a local IP address type for a second client device (Col. 5, lines 5 -47 - client outside the realm seeking to resolve a name in the form LOCALDNS@REALMNAME will first send a request to its global DNS server requesting a record for REALMNAME. What will be returned will be a globally significant IP address for REALMNAME plus an address for a DNS server. The DNS server address will typically be a locally significant IPv4 address for the DNS server within the target realm. Using both addresses, the client contacts this latter DNS server to resolve LOCAL-DNS to a locally significant address. With the locally significant address and the globally significant realm address, the client has the information to populate the destination fields of packet 300.At a step 402, the client node resolves a destination name to a globally significant realm IP address as described above or by some other technique. At a step 404, the client node resolves the destination name to a locally significant IP address. The local destination IP address 312 is obtained from the result of step 404. The globally significant destination realm IP address is obtained from the result of step 402; - for voice over IP (VoIP) applications, SIP may be used to resolve a single phone number to a combination of globally significant realm address and locally significant node address. Col. 9, lines 15-20 - host A 702 could be modified to perform the global two-part DNS resolution and to perform the encapsulation of FIG. 3 – See Fig.3&4);
send 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 (col. 5. Lines 25-47 At a step 406, the client forms a packet in the form illustrated in FIG. 3. The local destination IP address 312 is obtained from the result of step 404. The globally significant destination realm IP address is obtained from the result of step 402. The packet is transmitted at step 408 . Col. 7, line 65-70 -: Host A 602 then establishes an automatic stateless tunnel to realm gateway 614. The tunnel is implemented simply by encapsulation in the packet format of FIG. 3 as performed by host A 602 - Col. 8, line 20 - With step 808, host A 602 forms an encapsulated packet and transmits it...At step 810, realm gateway 614 receives the packet..."; See Also figures 3, 6, 8); and
receive, by the first client device, a packet including media data from the second client device via the intermediate network device (col. 5, lines 19-24: - for voice over IP (VoIP) applications, SIP may be used ; Col. 8, lines 20-60: host B 604 transmitting a response packet back to host A 602. At step 812, host B 604 transmits a response back to host A 602. The response is an IPv6 packet with the IPv6 destination address being source IPv6 address of the packet that host B 604 has- the FIG. 9 is a flow chart describing operations in exchanging packets between host B 604 and host A 602 at the initiation of host B 604 At step 904, host B 604 forwards a packet using the IPv6 address obtained in step 902. At step 910, the packet reaches realm gateway 612. Realm gateway 612 then swaps the encapsulation IP header 304 and the inner IP header 306 so that further forwarding to host A 602 via private IPv4+ network 606 is based on the locally significant address HA).
Regarding claim 22,
Toebes further teaches
wherein the local IP address type comprises one of IPv4 or IPv6 (Col.3, lines 60-65 -Each of realms 202 incorporates a cloud of network nodes having an IPv4 address unique within that realm but not globally unique – Col.4, lines 10-12 - Each node within one of realms 202 has a globally unique "address" that consists of a concatenation of its realm's globally significant IPv4 address and its own locally unique IPv4 address).
Regarding claim 31,
Toebes teaches a computer-readable storage medium having stored thereon instructions that, when executed, cause a processing system of a first client device to:
receive data representing a global Internet protocol (IP) address and a local IP address type for a second client device (Col. 5, lines 5 -47 - client outside the realm seeking to resolve a name in the form LOCALDNS@REALMNAME will first send a request to its global DNS server requesting a record for REALMNAME. What will be returned will be a globally significant IP address for REALMNAME plus an address for a DNS server. The DNS server address will typically be a locally significant IPv4 address for the DNS server within the target realm. Using both addresses, the client contacts this latter DNS server to resolve LOCAL-DNS to a locally significant address. With the locally significant address and the globally significant realm address, the client has the information to populate the destination fields of packet 300.At a step 402, the client node resolves a destination name to a globally significant realm IP address as described above or by some other technique. At a step 404, the client node resolves the destination name to a locally significant IP address. The local destination IP address 312 is obtained from the result of step 404. The globally significant destination realm IP address is obtained from the result of step 402; - for voice over IP (VoIP) applications, SIP may be used to resolve a single phone number to a combination of globally significant realm address and locally significant node address. Col. 9, lines 15-20 - host A 702 could be modified to perform the global two-part DNS resolution and to perform the encapsulation of FIG. 3 – See Fig.3&4);
send 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 (col. 5. Lines 25-47 At a step 406, the client forms a packet in the form illustrated in FIG. 3. The local destination IP address 312 is obtained from the result of step 404. The globally significant destination realm IP address is obtained from the result of step 402. The packet is transmitted at step 408 . Col. 7, line 65-70 -: Host A 602 then establishes an automatic stateless tunnel to realm gateway 614. The tunnel is implemented simply by encapsulation in the packet format of FIG. 3 as performed by host A 602 - Col. 8, line 20 - With step 808, host A 602 forms an encapsulated packet and transmits it...At step 810, realm gateway 614 receives the packet..."; See Also figures 3, 6, 8); and
receiving a packet including media data from the second client device via the intermediate network device (col. 5, lines 19-24: - for voice over IP (VoIP) applications, SIP may be used ; Col. 8, lines 20-60: host B 604 transmitting a response packet back to host A 602. At step 812, host B 604 transmits a response back to host A 602. The response is an IPv6 packet with the IPv6 destination address being source IPv6 address of the packet that host B 604 has- the FIG. 9 is a flow chart describing operations in exchanging packets between host B 604 and host A 602 at the initiation of host B 604 At step 904, host B 604 forwards a packet using the IPv6 address obtained in step 902. At step 910, the packet reaches realm gateway 612. Realm gateway 612 then swaps the encapsulation IP header 304 and the inner IP header 306 so that further forwarding to host A 602 via private IPv4+ network 606 is based on the locally significant address HA).
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 9,10 are rejected under 35 U.S.C. 103 as being unpatentable over Toebes in view of Cagenius et al. Publication No. US 2009/0083426 A1 (Cagenius hereinafter) .
Regarding claim 9,
Toebes further teaches
wherein the data representing the local IP address type [..] for a media communication session between the first client device and the second client device (Col. 5, lines 5 -47 & Col. 9, lines 15-20)
However, Toebes does not explicitly teach that the data representing the local IP address type includes session information
Cagenius teaches
data representing the local IP address type includes session information for a media communication session between the first client device and the second client device ( ¶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 Toebes 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,
Toebes 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 Toebes 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 Toebes in view of Handley et al. “SDP: Session Description Protocol” RFC 4566 – July 2006 (Handley hereinafter)
Regarding claim 11,
Toebes further teaches
wherein the data representing the local IP address type [..] for a network connecting the first client device and the second client device. (Col. 5, lines 5 -47. Col. 9, lines 15-20)
However, Toebes 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 Toebes 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,
Toebes 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 Toebes 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,
Toebes further teaches
wherein receiving the data representing the local IP address type comprises receiving one or more session SDP attributes representing the local IP address type (Col.5, lines 20-25 - The present invention is not, however, limited to DNS resolution techniques. For example, for voice over IP (VoIP) applications, SIP may be used to resolve a single phone number to a combination of globally significant realm address and locally significant node address – Col.5, lines 50-53 - If the remote node initiates the session, the remote node's globally significant address and locally significant address are learned from the incoming packets – Note: the SIP protocol inherently uses SDP) .
However, Toebes 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 Toebes 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,
Toebes further teaches
wherein receiving the data representing the local IP address type includes receiving an SDP attributes specifying the local IP address type, and a local IP address (Col.5, lines 20-25 - The present invention is not, however, limited to DNS resolution techniques. For example, for voice over IP (VoIP) applications, SIP may be used to resolve a single phone number to a combination of globally significant realm address and locally significant node address – Col.5, lines 50-53 - If the remote node initiates the session, the remote node's globally significant address and locally significant address are learned from the incoming packets – Note: the SIP protocol inherently uses SDP - Col.3, lines 60-65 -Each of realms 202 incorporates a cloud of network nodes having an IPv4 address unique within that realm but not globally unique – Col.4, lines 10-12 - Each node within one of realms 202 has a globally unique "address" that consists of a concatenation of its realm's globally significant IPv4 address and its own locally unique IPv4 address).
However, Toebes 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 Toebes 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,
Toebes further teaches
wherein receiving the data representing the local IP address type includes receiving an SDP attribute (Col.5, lines 20-25 - The present invention is not, however, limited to DNS resolution techniques. For example, for voice over IP (VoIP) applications, SIP may be used to resolve a single phone number to a combination of globally significant realm address and locally significant node address – Col.5, lines 50-53 - If the remote node initiates the session, the remote node's globally significant address and locally significant address are learned from the incoming packets – Note: the SIP protocol inherently uses SDP - Col.3, lines 60-65 -Each of realms 202 incorporates a cloud of network nodes having an IPv4 address unique within that realm but not globally unique – Col.4, lines 10-12 - Each node within one of realms 202 has a globally unique "address" that consists of a concatenation of its realm's globally significant IPv4 address and its own locally unique IPv4 address).
However, Toebes 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 Toebes 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 Toebes 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,
Toebes further teaches
wherein receiving the data representing the local IP address type includes receiving a line of a session description protocol (SDP) message (Col.5, lines 20-25 - The present invention is not, however, limited to DNS resolution techniques. For example, for voice over IP (VoIP) applications, SIP may be used to resolve a single phone number to a combination of globally significant realm address and locally significant node address – Col.5, lines 50-53 - If the remote node initiates the session, the remote node's globally significant address and locally significant address are learned from the incoming packets – Note: the SIP protocol inherently uses SDP - Col.3, lines 60-65 -Each of realms 202 incorporates a cloud of network nodes having an IPv4 address unique within that realm but not globally unique – Col.4, lines 10-12 - Each node within one of realms 202 has a globally unique "address" that consists of a concatenation of its realm's globally significant IPv4 address and its own locally unique IPv4 address).
However, Toebes does not explicitly teach
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
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 Toebes 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 Toebes 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,
Toebes further teaches
wherein receiving the data representing the local IP address type comprises receiving one or more session SDP attributes representing the local IP address type (Col.5, lines 20-25 - The present invention is not, however, limited to DNS resolution techniques. For example, for voice over IP (VoIP) applications, SIP may be used to resolve a single phone number to a combination of globally significant realm address and locally significant node address – Col.5, lines 50-53 - If the remote node initiates the session, the remote node's globally significant address and locally significant address are learned from the incoming packets – Note: the SIP protocol inherently uses SDP) .
However, Toebes 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 Toebes 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,
Toebes further teaches
wherein receiving the data representing the local IP address type includes receiving an SDP attributes specifying the local IP address type, and a local IP address (Col.5, lines 20-25 - The present invention is not, however, limited to DNS resolution techniques. For example, for voice over IP (VoIP) applications, SIP may be used to resolve a single phone number to a combination of globally significant realm address and locally significant node address – Col.5, lines 50-53 - If the remote node initiates the session, the remote node's globally significant address and locally significant address are learned from the incoming packets – Note: the SIP protocol inherently uses SDP - Col.3, lines 60-65 -Each of realms 202 incorporates a cloud of network nodes having an IPv4 address unique within that realm but not globally unique – Col.4, lines 10-12 - Each node within one of realms 202 has a globally unique "address" that consists of a concatenation of its realm's globally significant IPv4 address and its own locally unique IPv4 address).
However, Toebes 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 Toebes 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,
Toebes further teaches
wherein to receive the data representing the local IP address type, the processing system is configured to receive an SDP attribute (Col.5, lines 20-25 - The present invention is not, however, limited to DNS resolution techniques. For example, for voice over IP (VoIP) applications, SIP may be used to resolve a single phone number to a combination of globally significant realm address and locally significant node address – Col.5, lines 50-53 - If the remote node initiates the session, the remote node's globally significant address and locally significant address are learned from the incoming packets – Note: the SIP protocol inherently uses SDP - Col.3, lines 60-65 -Each of realms 202 incorporates a cloud of network nodes having an IPv4 address unique within that realm but not globally unique – Col.4, lines 10-12 - Each node within one of realms 202 has a globally unique "address" that consists of a concatenation of its realm's globally significant IPv4 address and its own locally unique IPv4 address).
However, Toebes 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 Toebes 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 Toebes 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,
Toebes further teaches
Wherein to receive the data representing the local IP address type the processing system is configured to receive a line of a session description protocol (SDP) message (Col.5, lines 20-25 - The present invention is not, however, limited to DNS resolution techniques. For example, for voice over IP (VoIP) applications, SIP may be used to resolve a single phone number to a combination of globally significant realm address and locally significant node address – Col.5, lines 50-53 - If the remote node initiates the session, the remote node's globally significant address and locally significant address are learned from the incoming packets – Note: the SIP protocol inherently uses SDP - Col.3, lines 60-65 -Each of realms 202 incorporates a cloud of network nodes having an IPv4 address unique within that realm but not globally unique – Col.4, lines 10-12 - Each node within one of realms 202 has a globally unique "address" that consists of a concatenation of its realm's globally significant IPv4 address and its own locally unique IPv4 address).
However, Toebes does not explicitly teach
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
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 Toebes 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 Toebes 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 Toebes in view of Yoshiuchi et al. Publication No. CN 101047548 A ( Yoshiuchi hereinafter)
Regarding claim 13,
Toebes further teaches
wherein the data representing the local IP address type (Col. 5, lines 5 -47. Col. 9, lines 15-20)
However, Toebes 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 Toebes 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,
Toebes further teaches
wherein the data representing the local IP address type (Col. 5, lines 5 -47. Col. 9, lines 15-20)
However, Toebes 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 Toebes 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 Toebes 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,
Toebes 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 Toebes 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,
Toebes 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 Toebes 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 Toebes in view of Perumal et al. Publication No. US 2010/0293297 A1 ( Perumal hereinafter)
Regarding claim 19,
Toebes further teaches
wherein receiving the data representing the local IP address type comprises receiving the data representing the local IP address type (Col. 5, lines 5 -47 - client outside the realm seeking to resolve a name in the form LOCALDNS@REALMNAME will first send a request to its global DNS server requesting a record for REALMNAME. What will be returned will be a globally significant IP address for REALMNAME plus an address for a DNS server. The DNS server address will typically be a locally significant IPv4 address for the DNS server within the target realm. Using both addresses, the client contacts this latter DNS server to resolve LOCAL-DNS to a locally significant address. With the locally significant address and the globally significant realm address, the client has the information to populate the destination fields of packet 300.At a step 402, the client node resolves a destination name to a globally significant realm IP address as described above or by some other technique. At a step 404, the client node resolves the destination name to a locally significant IP address. The local destination IP address 312 is obtained from the result of step 404. The globally significant destination realm IP address is obtained from the result of step 402; - for voice over IP (VoIP) applications, SIP may be used to resolve a single phone number to a combination of globally significant realm address and locally significant node address. Col. 9, lines 15-20 - host A 702 could be modified to perform the global two-part DNS resolution and to perform the encapsulation of FIG. 3 – See Fig.3&4).
However, Toebes 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 Toebes 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,
Toebes further teaches
wherein receiving the data representing the local IP address type, the processing system is configured to receive the data representing the local IP address type (Col. 5, lines 5 -47 - client outside the realm seeking to resolve a name in the form LOCALDNS@REALMNAME will first send a request to its global DNS server requesting a record for REALMNAME. What will be returned will be a globally significant IP address for REALMNAME plus an address for a DNS server. The DNS server address will typically be a locally significant IPv4 address for the DNS server within the target realm. Using both addresses, the client contacts this latter DNS server to resolve LOCAL-DNS to a locally significant address. With the locally significant address and the globally significant realm address, the client has the information to populate the destination fields of packet 300.At a step 402, the client node resolves a destination name to a globally significant realm IP address as described above or by some other technique. At a step 404, the client node resolves the destination name to a locally significant IP address. The local destination IP address 312 is obtained from the result of step 404. The globally significant destination realm IP address is obtained from the result of step 402; - for voice over IP (VoIP) applications, SIP may be used to resolve a single phone number to a combination of globally significant realm address and locally significant node address. Col. 9, lines 15-20 - host A 702 could be modified to perform the global two-part DNS resolution and to perform the encapsulation of FIG. 3 – See Fig.3&4).
However, Toebes 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 Toebes 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 Toebes in view of Liu et al. Publication No. US 2024/0276183 A1 ( Liu hereinafter)
Regarding claim 20,
Toebes further teaches wherein the intermediate network device comprises a device [..] (¶ 0023, ¶ 0026). However, Toebes 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 Toebes 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,
Toebes further teaches wherein the intermediate network device comprises a device [..] (¶ 0023, ¶ 0026).
However, Toebes 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 Toebes 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
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Kaul et al. Publication No. US 2005/0050211 A1 - ¶0011, ¶0022 – ¶0024, ¶ 0027, ¶0035, ¶0046
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