Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicant’s amendments with respect to the specification have been fully considered. The
objection of the specification has been withdrawn.
Applicant’s arguments with respect to claim(s) 1 and 15 have been considered, a new
rejection has been made. Claims 1 and 15 are rejected under 35 U.S.C 103 (See 103 rejection of claim 15 below).
Applicant’s arguments with respect to claim(s) 11 and 12 have been considered, a new
rejection has been made. Claims 11 and 12 are rejected under 35 U.S.C 103 (See 103 rejection of claim 11 and 12 below).
Claim Objections
Claim 1, 11 and 15 are objected to because of the following informalities:
In claim 1, line 11, “fourth packet,;” should read “fourth packet;”.
In claim 11, line 10, “a first packet” should read “the first packet”.
In claim 11, line 11, “padding data” should read “the padding data”.
In claim 15, line 12, “fourth packet,;” should read “fourth packet;”.
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 1-5 and 15-19 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.
Regarding claim 1, the claim recites
“encapsulating, by the first device, the third packet according to the N3 tunneling protocol to obtain a fourth packet; and adding, in response to determining that a data length of the fourth packet is less than a minimum Ethernet frame length, tunneling protocol padding data to an N3 tunneling protocol header of the fourth packet to obtain the second packet, wherein a data length of the second packet is greater than or equal to the minimum Ethernet frame length; or
encapsulating, by the first device, in response to determining that a data length of an encapsulated packet obtained by the first device by encapsulating the third packet according to the N3 tunneling protocol is less than a minimum Ethernet frame length, the third packet according to the N3 tunneling protocol to obtain the encapsulated packet, and adding tunneling protocol padding data to an N3 tunneling protocol header of the encapsulated packet to obtain the second packet, wherein a data length of the second packet is greater than or equal to the minimum Ethernet frame length;”.
It is unclear how "an encapsulated packet obtained by the FIRST DEVICE by encapsulating the third packet according to the N3 tunneling protocol " is differentiated from the "fourth packet" and how the encapsuating steps for both cases are differentiated from one another. One of two alternative cases listed above should be removed. For the examination purpose claim 1 will be read as if the second alternative case is removed.
Claim 15 recites similar limitations of claim 1, is thus rejected under similar rational.
Claims 2-5 and 16-19 are rejected due to their dependency on claim 1 and 15.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim(s) 1-5 and 15-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over 20210344441 A1 (hereinafter Zhang), in view of “5G; System architecture for the 5G System (5GS)”, 3GPP TS 23.501 version 16.5.0 (2020-07) (hereinafter 23.501), and US 20180063296 A1 (hereinafter Kato).
Regarding claim 15, Zhang teaches A device, comprising (Zhang Fig. 11; communication device
1100 in Fig. 11.):
at least one processor (Zhang processor 1102 in Fig. 11; [0219] the communications device
1100 includes a processor 1102.); and
one or more memories coupled to the at least one processor and storing programming
instructions for execution by the at least one processor to cause the device to (Zhang memory 1101 in
Fig. 11; [0219] As shown in FIG. 11, the communications device 1100 includes a memory 1101, a processor 1102, and a computer program 11011 stored in the memory 1101 and capable of running on
the processor 1102.):
receive a first packet, wherein load data in the first packet comprises padding data;
delete the padding data (Zhang Fig. 1, [0035] FIG. 1 is a schematic diagram of an architecture of
a wireless communications system to which some embodiments of this disclosure may be applied. For
downlink data, the UPF is an ingress device of the bridge. the UPF may establish a connection with a
second external device.
[0139 ] the first device is an ingress device (for example, a UPF) of a 5G system.
[0140] The ingress device of the 5G system receives an Ethernet frame from an external
device.
Fig. 2; [0040] FIG. 2 is a flowchart of an Ethernet frame transmission method. The method is
applied to a first device.
[0046] the first device may be an UPF.
[0041] Remove a specified field from an Ethernet frame.
[0047] the specified field includes at least one of the following: [0048] a padding field.);
Although Zhang teaches a third packet that is a packet obtained after the padding data is
deleted from the first packet, send the third packet as a payload data over N3 interface to a second
device (Zhang [0046] the first device may be an UPF.
[0041] Remove a specified field from an Ethernet frame.
[0047] the specified field includes at least one of the following: [0048] a padding field.
[0043] The Ethernet frame may be a downlink Ethernet frame.
[0044] Transmit the Ethernet frame with the specified field removed to a second device.),
adding, in response to determining that a data length of the fourth packet is less than a
minimum Ethernet frame length, padding data to the fourth packet to obtain the second packet, wherein a data length of the second packet is greater than or equal to the minimum Ethernet frame length (Zhang [0120] adding the padding field to the Ethernet frame if an actual data field length of the Ethernet frame is less than a protocol-prescribed minimum data field length corresponding to a format of the Ethernet frame, where a length of the padding field is a difference between the minimum data field length and the actual data field length.); Zhang does not explicitly teach generating, by the first device, a second packet by encapsulating, according to an N3 tunneling, the third packet, wherein load data in the second packet is the third packet, wherein the generating, by the first device, the second packet comprises:
encapsulating, by the first device, the third packet according to the N3 tunneling protocol to
obtain a fourth packet; adding tunneling protocol padding data to an N3 tunneling protocol header.
23.501 in the same or similar field of endeavor teaches generating, by the first device, a second packet by encapsulating, according to an N3 tunneling, the third packet, wherein load data in the second packet is the third packet (23.501 page 396, Figure 8.3.1-1: User Plane Protocol Stack
PDU layer: This layer corresponds to the PDU carried between the UE and the DN over the
PDU Session.
When the PDU Session Type is IPv4 or IPv6 or IPv4v6, it corresponds to IPv4 packets or IPv6
packets or both of them; When the PDU Session Type is Ethernet, it corresponds to Ethernet frames;
etc.
GPRS Tunnelling Protocol for the user plane (GTP-U): This protocol supports tunnelling user
data over N3 (i.e. between the 5G-AN node and the UPF). GTP shall encapsulate all end user PDUs.),
wherein the generating, by the first device, the second packet comprises:
encapsulating, by the first device, the third packet according to the N3 tunneling protocol to
obtain a fourth packet (23.501 page 396, Figure 8.3.1-1: User Plane Protocol Stack
PDU layer: This layer corresponds to the PDU carried between the UE and the DN over the
PDU Session.
When the PDU Session Type is IPv4 or IPv6 or IPv4v6, it corresponds to IPv4 packets or IPv6
packets or both of them; When the PDU Session Type is Ethernet, it corresponds to Ethernet frames;
etc.
GPRS Tunnelling Protocol for the user plane (GTP-U): This protocol supports tunnelling user
data over N3 (i.e. between the 5G-AN node and the UPF). GTP shall encapsulate all end user PDUs);
N3 tunneling protocol header includes an IP header, a UDP header and a GTP-U header (23.501 page 396, Figure 8.3.1-1: As shown in the Fig, N3 includes IP header, UDP header and GTP-U header).
23.501 does not explicitly teach adding padding data to an IP header.
Kato in the same or similar field of endeavor teaches adding padding data to an IP header (Kato [0041] The IP header includes version information, a header length, a service type, a packet length, an identifier, a flag, a fragment offset, a time to live (TTL), a protocol number, a header checksum, a transmission source IP address, and a destination IP address. The IP header may further include an option field and padding for adjusting the length of the IP header.).
By modifying Zhang’s teachings of a third packet that is a packet obtained after the padding data is deleted from the first packet, send the third packet as a payload data over N3 interface to a second
device, adding, in response to determining that a data length of the fourth packet is less than a minimum Ethernet frame length, padding data to the fourth packet to obtain the second packet, wherein a data length of the second packet is greater than or equal to the minimum Ethernet frame length with 23.501’s teachings of generating, by the first device, a second packet by encapsulating, according to an N3 tunneling, the third packet, wherein load data in the second packet is the third packet, wherein the generating, by the first device, the second packet comprises:
encapsulating, by the first device, the third packet according to the N3 tunneling protocol to
obtain a fourth packet, N3 tunneling protocol header includes an IP header, a UDP header and a GTP-U header, with Kato’s teachings of adding padding data to an IP header, the modification results in
generating, by the first device, a second packet by encapsulating, according to an N3 tunneling
protocol, a third packet that is a packet obtained after the padding data is deleted from the first packet, wherein load data in the second packet is payload data obtained after the padding data is deleted from the first packet, wherein the generating, by the first device, the second packet comprises:
encapsulating, by the first device, the third packet according to the N3 tunneling protocol to
obtain a fourth packet; and adding, in response to determining that a data length of the fourth packet is less than a minimum Ethernet frame length, tunneling protocol padding data to an N3 tunneling protocol header of the fourth packet to obtain the second packet, wherein a data length of the second packet is greater than or equal to the minimum Ethernet frame length;
send the second packet to a second device.
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Zhang with 23.501’s above teachings. The
motivation is supporting standard user plane protocol between NG-RAN and UPF (23.501 page 395).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Zhang as modified by 23.501 with Kato’s above teachings. The motivation is reducing the amount of processing load on the communication apparatus (Kato [0007]).
Claim 1 recites similar limitations of claim 15, is thus rejected under similar rational.
Regarding claim 2, Zhang in view of 23.501 and Kato (hereinafter combination) discloses The method according to claim 1.
Zhang teaches wherein the method further comprises: receiving, by the first
device, first indication information; and the deleting, by the first device, the padding data comprises:
deleting, by the first device, the padding data based on the first indication information (Zhang [0139]
the first device is an ingress device (for example, a UPF) of a 5G system.
[0140] The ingress device of the 5G system receives an Ethernet frame from an external
device.
[0062] removing the padding field if it is determined, based on an actual data field length of
the Ethernet frame and a protocol-prescribed minimum data field length corresponding to a format of
the Ethernet frame, that the Ethernet frame includes the padding field.).
Regarding claim 3, the combination discloses The method according to claim 2.
Zhang teaches wherein the first indication information indicates the first device to delete the padding data, or
the first indication information comprises length information of the padding data or location
information of the padding redundant data, or
the first indication information comprises length information of payload data of the first packet
or location information of the payload data of the first packet (Zhang [0062] removing the padding field
if it is determined, based on an actual data field length of the Ethernet frame and a protocol-
prescribed minimum data field length corresponding to a format of the Ethernet frame, that the
Ethernet frame includes the padding field.).
Regarding claim 4, the combination discloses The method according to claim 1.
Zhang teaches wherein the deleting, by the first device, the padding redundant data comprises: deleting, by the first device, the padding data based on a length field of the first packet (Zhang [0062] removing the padding field if it is determined, based on an actual data field length of the Ethernet frame and a protocol-prescribed minimum data field length corresponding to a format of the Ethernet frame, that the Ethernet frame includes the padding field.).
Regarding claim 5, the combination discloses The method according to claim 1.
Zhang teaches wherein the first device is a user plane network element, the second device is a
radio access network (RAN) device, and the first packet is a downlink Ethernet packet (Zhang Fig. 2;
[0040] FIG. 2 is a flowchart of an Ethernet frame transmission method. The method is applied to a first device.
[0046] the first device may be an UPF.
[0041] Step 201: Remove a specified field from an Ethernet frame.
[0047] the specified field includes at least one of the following: [0048] a padding field
[0043] The Ethernet frame may be a downlink Ethernet frame.
[0044] Step 202: Transmit the Ethernet frame with the specified field removed to a second
device.
Note: as shown in Fig. 1, NG-RAN is in down link direction from UPF, NG-RAN is the second
Device.).
Claims 16, 17, 18 and 19 recite similar limitations of claims 2, 3, 4 and 5 respectively, are thus
rejected under similar rational.
Claim(s) 11 is/are rejected under 35 U.S.C. 103 as being unpatentable over “5G; Policy and charging control framework for the 5G System (5GS); Stage 2”, 3GPP TS 23.503 version 16.5.0 (2020-07) (hereinafter 23.503), in view of “5G System; Technical Realization of Service Based Architecture; Stage 3,
3GPP TS 29.500 V16.4.0 (2020-06) (hereinafter 29.500) and “IPv4”, Wikipedia, 9/12/2011 (hereinafter wiki).
Regarding claim 11, 23.503 teaches A method, comprising: receiving, by a third device, second
indication information from a fifth device, wherein the second indication information is a second service based message for policy control (23.503 page 17-18, Section 5.2 Reference architecture
The reference architecture of policy and charging control framework for the 5G System is comprised by the functions of the Policy Control Function (PCF), the Session Management Function (SMF), ... the Application Function (AF)
Figure 5.2.1-1: Overall non-roaming reference architecture of policy and charging control framework
for the 5G System (service based representation)
Figure 5.2.1-1a: Overall non-roaming reference architecture of policy and charging control framework
for the 5G System (reference point representation)
page 21, 5.3.1 Interactions between PCF and AF
Npcf and Naf enable transport of application level session information and Ethernet port management information from AF to PCF.
The N5 reference point is defined for the interactions between PCF and AF in the reference point representation.
Note: The third device is a PCF, the fifth device is a AF. Npcf and Naf is the second service based message for policy control.);
determining, by the third device, first indication information based on the second indication information (23.503 page 36, 6.1.3 Session management related policy control
The session management related policy control functionality of the Policy and Charging control framework for the 5G system provides the functions for policy and charging control as well as event reporting for service data flows.
page 47, 6.1.3.6 Policy control
For policy control, the AF interacts with the PCF and the PCF interacts with the SMF as instructed by the AF.); and
sending, by the third device, the first indication information to a fourth device, wherein the first indication information is a first service based message for policy control (23.503
page 21, 5.3.2 Interactions between PCF and SMF.
Npcf and Nsmf enable the PCF to have dynamic control over the policy and charging behaviour at a SMF.
The N7 reference point is defined for the interactions between PCF and SMF in the reference point representation.
Page 47, 6.1.3.6 Policy control
For policy control, the AF interacts with the PCF and the PCF interacts with the SMF as instructed by the AF.
Note: The third device is a PCF, the fourth device is a SMF. Npcf and Nsmf is the first service based message for policy control.);
wherein the third device is a policy control network element, the fourth device is a session management network element, and a fifth device is an application function network element (23.503 23.503 page 17-18, Section 5.2 Reference architecture
The reference architecture of policy and charging control framework for the 5G System is comprised by the functions of the Policy Control Function (PCF), the Session Management Function (SMF), ... the Application Function (AF)
Figure 5.2.1-1: Overall non-roaming reference architecture of policy and charging control framework
for the 5G System (service based representation)
Figure 5.2.1-1a: Overall non-roaming reference architecture of policy and charging control framework
for the 5G System (reference point representation).
Note: The third device is a PCF, the fourth device is a SMF, the fifth device is AF.).
23.503 does not explicitly teach the second service based message comprises a IP header and the IP header indicates length information of payload data of a first packet or location information of the payload data of the first packet; the first service based message comprises a IP header and the IP header comprises length information of payload data of the first packet or location information of the payload data of the first packet.
29.500 in the same or similar field of endeavor teaches the second service based message comprises a IP header; the first service based message comprises a IP header (29.500 page 12-13, 5.1 Protocol Stack Overview
The protocol stack for the service based interfaces is shown on Figure 5.1-1.
PNG
media_image1.png
200
400
media_image1.png
Greyscale
Note: As shown in the above figure, a service based message comprises a IP header.).
It would have been prima facie obvious to one of ordinary skill in the art before the effective
filing date of the claimed invention to have modified 23.503 with 29.500’s above teachings. The motivation is realization of the 5GC Service Based Architecture (29.500 page 8, Scope).
Wiki in the same or similar field of endeavor teaches a IP header comprises length information of payload data of the first packet or location information of the payload data of the first packet (wiki page 10-11, As shown in the figure, IP header comprises header length field and total length field.
Internet Header Length (IHL)
The second field (4 bits) is the Internet Header Length (IHL) telling the number of 32-bit words in the header. Since an IPv4 header may contain a variable number of options, this field specifies the size of the header (this also coincides with the offset to the data).
Total Length
This 16-bit field defines the entire datagram size, including header and data, in bytes. The minimum-length datagram is 20 bytes (20-byte header + 0 bytes data) and the maximum is 65,535 bytes — the maximum value of a 16-bit word.).
By modifying 23.503’s teachings of A method, comprising: receiving, by a third device, second
indication information from a fifth device, wherein the second indication information is a second service based message for policy control; determining, by the third device, first indication information based on the second indication information; and sending, by the third device, the first indication information to a fourth device, wherein the first indication information is a first service based message for policy control, wherein the third device is a policy control network element, the fourth device is a session management network element, and a fifth device is an application function network element with 29.500’s teachings of the second service based message comprises a IP header; the first service based message comprises a IP header and with wiki’s teachings of a IP header comprises length information of payload data of the first packet or location information of the payload data of the first packet, the modification results in
A method, comprising: receiving, by a third device, second indication information from a fifth
device, wherein information of payload data of a first packet or location information of the payload data of the first packet; and
determining, by the third device, first indication information based on the second indication information; and
sending, by the third device, the first indication information to a fourth device, wherein
wherein the third device is a policy control network element, the fourth device is a session management network element, and a fifth device is an application function network element.
It would have been prima facie obvious to one of ordinary skill in the art before the effective
filing date of the claimed invention to have modified 23.503 as modified by 29.500 with wiki’s above teachings. The motivation is supporting standards-based internetworking methods (wiki page 2).
Claim(s) 12 is/are rejected under 35 U.S.C. 103 as being unpatentable over 23.503 in view of 29.500 and wiki as applied to claim 11 above, and further in view of US 20220377602 A1 (hereinafter Kim).
Regarding claim 12, 23.503 in view of 29.500 and wiki (hereinafter combination) teaches The
method according to claim 11.
The combination does not explicitly teach wherein in response to at least that the
first indication information is for deleting the padding data from the first packet, the third device is a policy control network element, the fourth device is a session management network element, and the first packet is an Ethernet packet; or the third device is a session management network element, the fourth device is a user plane network element, and the first packet is an Ethernet packet; or the third device is a session management network element, the fourth device is a user equipment (UE), and the first packet is an Ethernet packet; or the third device is a session management network element, and the fourth device is a radio access network (RAN) device; or the third device is a radio access network (RAN) device, and the fourth device is a user equipment (UE).
Kim in the same or similar field of endeavor teaches wherein in response to at least that the
first indication information is for deleting the padding data from the first packet (Kim Fig. 1E RRCConnectionSetup from gNB to UE
[0138] the RRCConnectionSetup message may configure which type of Ethernet frame or Ethernet header is to be used. which type of fields are configured in the Ethernet header, how many bytes the Ethernet header size is, how many bits the size of each field of the Ethernet header is. in a case where padding is added to the Ethernet frame, the base station may indicate whether to configure using a function of preventing the padding from being transmitted through the actual wireless link by removing the padding at the transmission terminal and by adding the padding at the reception terminal.),
the third device is a policy control network element, the fourth device is a session management network element, and the first packet is an Ethernet packet; or
the third device is a session management network element, the fourth device is a user plane network element, and the first packet is an Ethernet packet; or
the third device is a session management network element, the fourth device is a user equipment (UE), and the first packet is an Ethernet packet; or
the third device is a session management network element, and the fourth device is a radio access network (RAN) device; or
the third device is a radio access network (RAN) device, and the fourth device is a user equipment (UE) (Kim Fig. 1E RRCConnectionSetup from gNB to UE.
Note the third device is a gNB, the fourth device is a UE.).
It would have been prima facie obvious to one of ordinary skill in the art before the effective
filing date of the claimed invention to have modified the combination with Kim’s above teachings. The motivation is improving operations of a protocol layer device (Kim [0009]).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to David Z Sun whose telephone number is (571)270-0750. The examiner can normally be reached Monday-Friday 0800am-0500pm.
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, Moo Jeong can be reached at 571-272-9617. 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.
/D.Z.S./Examiner, Art Unit 2418
/Moo Jeong/Supervisory Patent Examiner, Art Unit 2418