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 .
DETAILED ACTION
1. This action is in response to the application filed on 14 February 2025.
Claims 1-20 are presently pending for examination.
Information Disclosure Statement
2. The information disclosure statement (IDS) submitted on 03/25/2025 and 09/18/2025 have being considered by the examiner.
Claim Rejections - 35 USC § 102
3. 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)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1-20 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Jin et al., U. S. Patent Publication No. 2017/0155596.
Regarding claim 1, Jin discloses a bandwidth control method, comprising: obtaining, by a service enabler architecture layer data delivery (SEALDD) server, bandwidth limit information from a first server, wherein the bandwidth limit information comprises at least one of bandwidth limit information of the first server or bandwidth limit information of a first user (see Jin, ¶ [0047] and [0054]; available bandwidth is obtained); determining, by the SEALDD server based on the bandwidth limit information, bandwidth allocated to a first SEALDD client, wherein the first SEALDD client is a client corresponding to the first user (see Jin, ¶ [0032]-[0033] and [0040]; allocated bandwidth of the client is determined); and sending, by the SEALDD server to the first SEALDD client, information about the bandwidth allocated to the first SEALDD client (see Jin, ¶ [0012] and [0056]; bandwidth is allocated to the user).
Regarding claim 2, Jin discloses wherein before the determining, by the SEALDD server based on the bandwidth limit information, bandwidth allocated to a first SEALDD client, the method further comprises: determining, by the SEALDD server based on whether a first condition is met, whether to allocate the bandwidth to the first SEALDD client, wherein the first condition comprises: used bandwidth of the first server is less than a first threshold or available bandwidth of the first server is greater than a first threshold (see Jin, ¶ [0047] and [0055]-[0057]).
Regarding claim 3, Jin discloses wherein the first condition further comprises: available bandwidth that is of a first service and that is provided by the first server is greater than a minimum bandwidth limit that is of the first service and that is provided for the first user (see Jin, ¶ [0032]).
Regarding claim 4, Jin discloses wherein the determining, by the SEALDD server based on whether a first condition is met, whether to allocate the bandwidth to the first SEALDD client comprises: when the first condition is met, determining, by the SEALDD server, to allocate the bandwidth to the first SEALDD client; when the first condition is not met, rejecting, by the SEALDD server, to allocate the bandwidth to the first SEALDD client; when the first condition is not met, determining, by the SEALDD server based on a priority of the first user, whether to allocate the bandwidth to the first SEALDD client; or when the first condition is not met, determining, by the SEALDD server according to a first configuration rule, whether to allocate the bandwidth to the first SEALDD client, wherein the first configuration rule indicates to allocate the bandwidth to the first SEALDD client based on a priority of the first user when the first condition is not met, or the first configuration rule indicates to reject to allocate the bandwidth to the first SEALDD client when the first condition is not met (see Jin, ¶ [0047] and [0070]).
Regarding claim 5, Jin discloses wherein the method further comprises: obtaining, by the SEALDD server, the first configuration rule from the first server (see Jin, ¶ [0064]-[0065]).
Regarding claim 6, Jin discloses wherein the rejecting, by the SEALDD server, to allocate the bandwidth to the first SEALDD client comprises: sending, by the SEALDD server, a reject message to the first SEALDD client, wherein the reject message carries a pending time; and re-receiving, by the SEALDD server, second request information from the first SEALDD client after the pending time ends, wherein the second request information carries at least one of information about the first user or information about a first service (see Jin, ¶ [0037] and [0056]).
Regarding claim 7, Jin discloses wherein the bandwidth limit information comprises the bandwidth limit information of the first user, and the obtaining, by a SEALDD server, bandwidth limit information from a first server comprises: sending, by the SEALDD server, first request information to the first server, wherein the first request information carries the information about the first user; and receiving, by the SEALDD server, the bandwidth limit information of the first user from the first server (see Jin, ¶ [0047] and [0055]).
Regarding claim 8, Jin discloses wherein the determining, by the SEALDD server based on the bandwidth limit information, bandwidth allocated to a first SEALDD client comprises: determining, by the SEALDD server based on the bandwidth limit information and at least one of a priority of the first SEALDD client or quality of service information of the first SEALDD client, the bandwidth allocated to the first SEALDD client (see Jin, ¶ [0033]-[0034]).
Regarding claim 9, Jin discloses wherein the method further comprises at least one of: obtaining, by the SEALDD server, the priority of the first SEALDD client from the first server; or obtaining, by the SEALDD server, the quality of service information of the first SEALDD client from a core network device (see Jin, ¶ [0043]-[0044]).
Regarding claim 10, Jin discloses a bandwidth control method, comprising: determining, by a first server, bandwidth limit information, wherein the bandwidth limit information comprises at least one of bandwidth limit information of the first server or bandwidth limit information of a first user, the bandwidth limit information is used to determine bandwidth allocated to a first service enabler architecture layer data delivery (SEALDD) client (see Jin, ¶ [0032]-[0033] and [0040]; allocated bandwidth of the client is determined), and the first SEALDD client is a client corresponding to the first user (see Jin, ¶ [0060] and [0086]; user client is provided); and sending, by the first server, the bandwidth limit information to a SEALDD server (see Jin, ¶ [0054]-[0055] and [0066]; bandwidth information is gathered).
Regarding claim 11, Jin discloses wherein the method further comprises: sending, by the first server, a first configuration rule to the SEALDD server, wherein the first configuration rule indicates to allocate the bandwidth to the first SEALDD client based on a priority of the first user when a first condition is not met, or the first configuration rule indicates to reject to allocate the bandwidth to the first SEALDD client when a first condition is not met, and the first condition comprises: used bandwidth of the first server is less than a first threshold or available bandwidth of the first server is greater than a first threshold (see Jin, ¶ [0047] and [0055]-[0057]).
Regarding claim 12, Jin discloses wherein rejecting to allocate the bandwidth to the first SEALDD client comprises: sending, by the SEALDD server, a reject message to the first SEALDD client, wherein the reject message carries a pending time; and re-receiving, by the SEALDD server, second request information from the first SEALDD client after the pending time ends, wherein the second request information carries at least one of information about the first user or information about a first service (see Jin, ¶ [0047] and [0070]).
Regarding claim 13, Jin discloses wherein the first condition further comprises: available bandwidth that is of the first service and that is provided by the first server is greater than a minimum bandwidth limit that is of the first service and that is provided for the first user (see Jin, ¶ [0032]).
Regarding claim 14, Jin discloses wherein the method further comprises: sending, by the first server, a priority of the first user to the SEALDD server, wherein the priority of the first user is used to determine the bandwidth allocated to the first SEALDD client (see Jin, ¶ [0033]-[0034]).
Regarding claim 15, Jin discloses a bandwidth control method, comprising: receiving, by a first SEALDD client, information about allocated bandwidth from a SEALDD server or a reject message from a SEALDD server, wherein the first SEALDD client is a client corresponding to a first user (see Jin, ¶ [0032], [0047] and [0070]; bandwidth allocation is rejected); and the information about the bandwidth is determined based on bandwidth limit information provided by a first server, and the bandwidth limit information comprises at least one of bandwidth limit information of the first server or bandwidth limit information of the first user (see Jin, ¶ [0032]-[0033] and [0040]; allocated bandwidth is determined).
Regarding claim 16, Jin discloses wherein the bandwidth limit information of the first server comprises at least one of total bandwidth limit information of the first server or bandwidth limit information that is of a first service and that is provided by the first server; and the bandwidth limit information of the first user comprises bandwidth limit information that is of the first service and that is provided for the first user (see Jin, ¶ [0032]-[0033] and [0047]).
Regarding claim 17, Jin discloses wherein the bandwidth of the first SEALDD client comprises bandwidth of the first SEALDD client for transmission of data of a first service (see Jin, ¶ [0055]-[0056]).
Regarding claim 18, Jin discloses wherein the method further comprises: sending, by the first SEALDD client, a second request information to the SEALDD server, wherein the second request information carries at least one of information about the first user or information about a first service (see Jin, ¶ [0047] and [0056]).
Regarding claim 19, Jin discloses wherein the method further comprises: sending, by the first SEALDD client, a second request information to a first port, wherein the first port is used by the SEALDD server to receive the second request information, and information from the first port is used by the SEALDD server to determine at least one of information about the first user or information about a first service (see Jin, ¶ [0034] and [0047]).
Regarding claim 20, Jin discloses wherein the reject message carries a pending time, and the method further comprises: re-sending, by the first SEALDD client, the second request information to the SEALDD server after the pending time ends, wherein the second request information carries at least one of the information about the first user [[and/]]or the information about the first service (see Jin, ¶ [0070]-[0071]).
Prior Art of Record
4. The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure. Please refer to form PTO-892 (Notice of Reference Cited) for a list of relevant prior art.
Conclusion
5. Any inquiry concerning this communication or earlier communications from the examiner should be directed to MOHAMED IBRAHIM whose telephone number is (571)270-1132. The examiner can normally be reached on Monday through Friday from 9:30AM to 6:00PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, John Follansbee can be reached on 571-272-3964. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Mohamed Ibrahim/
Primary Examiner, Art Unit 2444
Prosecution Insights