Prosecution Insights
Last updated: August 17, 2026
Application No. 18/741,047

Service Processing Method, Apparatus, and System

Final Rejection §103
Filed
Jun 12, 2024
Priority
Dec 14, 2021 — CN 202111527212.1 +2 more
Examiner
NAJI, YOUNES
Art Unit
2445
Tech Center
2400 — Computer Networks
Assignee
Huawei Technologies Co., Ltd.
OA Round
2 (Final)
75%
Grant Probability
Favorable
3-4
OA Rounds
8m
Est. Remaining
99%
With Interview

Examiner Intelligence

Grants 75% — above average
75%
Career Allowance Rate
333 granted / 444 resolved
+17.0% vs TC avg
Strong +73% interview lift
Without
With
+73.1%
Interview Lift
resolved cases with interview
Typical timeline
2y 11m
Avg Prosecution
30 currently pending
Career history
494
Total Applications
across all art units

Statute-Specific Performance

§101
9.6%
-30.4% vs TC avg
§103
51.5%
+11.5% vs TC avg
§102
12.6%
-27.4% vs TC avg
§112
19.1%
-20.9% vs TC avg
Black line = Tech Center average estimate • Based on career data from 444 resolved cases

Office Action

§103
DETAILED ACTION Notice of Pre-AIA or AIA Status The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . This office action is in response to Applicant’s communication filed on 05/13/2026. Claims 1-22 have been examined. Claims 21-22 are new. Response to Arguments Applicant’s argument #1 Applicant argues that Matsuyama fails to disclose that the first service information corresponds to a first service and second service information corresponds to a second service. Examiner response to Applicant’s argument #1 The examiner respectfully disagrees. Matsuyama teaches that the option field comprises first service information and second service information, wherein the first service information corresponds to a first service, wherein the second service information corresponds to a second service. Matsuyama’s invention teaches that the option field is a field which is to be filled in by individual service providers (SP). Thus, the option field is composed of sub-fields allocated to a plurality of service providers, each sub-field containing the distinguished name of the service provider, data size and contents (See - ¶ 0146). Matsuyama also teaches service providers 604 are the subjects or entities which offer the service "A", while service providers 607 are the subjects or entities that offer the service "B" (¶ 0118,Fig.5 & Fig.6). Therefore, based on the broadest reasonable interpretation of the claim language, the examiner interprets the option field comprises first service information and second service information, wherein the first service information corresponds to a first service and wherein the second service information corresponds to a second service as equivalent to the option field containing sub-fields allocated to multiple different service providers, each sub field containing respective service provider information and that each service provider within the option field corresponds to its own service. Applicant’s arguments, see Remarks – Page 14 , filed on 5/13/2026, with respect to the rejection of claims 1,7,13 under 102 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground of rejection is made in view of Stewart. 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 1,2,7,8,13 -16,21 are rejected under 35 U.S.C. 103 as being unpatentable over Matsuyama et al. Publication No. US 2002/0010861 A1 (Matsuyama hereinafter) in view of Stewart et al. Publication No. US 2006/0259602 A1 ( Stewart hereinafter) Regarding claim 1, Matsuyama teaches a network device comprising: a memory configured to store instructions; and one or more processors coupled to the memory and configured to execute the instructions to cause the network device (Fig.3,Fig.23) to: receive a packet comprising an option field, wherein the option field comprises first service information and second service information [..] (Claim 38 - a processing for receiving, from the device, an access permission accommodating a service provider identification data that identifies the service provider to which the device has been permitted to make an access – Fig.10, ¶ 0139 - FIG. 10 shows a sample of the access permission prepared in the form "B". The access permission has a plurality of fields: a fixed field to be set by the access control server (ACS), an option field to be set by each service provider (SP) and a signature field to be filled by the access control server (ACS). – Note: Fig.10 shows an option field comprising first service provider ID (SP1) and second service (SP2) – ¶0027 - the access control server is configured to generate the access permission in a format which comprises: an access-control-server-set fixed field set by the access control server; a service-provider-set option field set by each of the service providers – ¶0146 - The option field is a field which is to be filled in by individual service providers (SP). Thus, the option field is composed of sub-fields allocated to a plurality of service providers, each sub-field containing the distinguished name of the service provider, data size and contents See Also ¶ 0028); wherein the first service information corresponds to a first service, wherein the second service information corresponds to a second service, wherein the first service is different from the second service; and process the packet based on the first service information ( ¶ 0139 - FIG. 10 shows a sample of the access permission prepared in the form "B". The access permission has a plurality of fields: a fixed field to be set by the access control server (ACS), an option field to be set by each service provider (SP) and a signature field to be filled by the access control server (ACS). – Note: Fig.10 shows an option field comprising first service provider ID (SP1) and second service (SP2) Claim 1 - an access control server which issues to the service receiving device an access permission which identifies a service provider an access to which by the service receiving device is permitted;- Claim 38 - a processing for determining, based on the data contained in the received access permission, whether the device is to be permitted to make an access – See Also Claim 15, ¶ 0033, ¶ 0118,Fig.5 & Fig.6). However, Matsuyama does not explicitly teach the option field comprises a service flag subfield. Wherein the service flag subfield indicates the option field comprises the first service information and second service information. Stewart teaches option field comprises a service flag subfield. Wherein the service flag subfield indicates the option field comprises the first service information and second service information (¶ 0076 - A TCP Options flag typically occupies space at the end of a TCP header. The Options flag begins on an octet boundary and is a multiple of 8 bits in length. The typical length of an Options flag is 40 bytes. FIG. 3B is block diagram that illustrates the format of a TCP Options flag according to one embodiment. In this embodiment, the TCP Options flag includes Option Type field 332, Option Length field 334, Server ID field 336, Discovery ID 338, and Service Parameters field 340 – ¶ 0077 - Option Type field 332 stores information that uniquely identifies the type of the TCP Option. The TCP transport protocol stack at a network element uses the value stored in the Option Type field of a received TCP segment to recognize that one or more services are advertised in the segment. In one embodiment, the value stored in the Option Type field is an 8-bit value that uniquely distinguishes the TCP Option used for service discovery from other types of TCP Options. In this embodiment, the Option Type value is assigned by IANA. Other embodiments may use Option Type values that are not assigned by IANA. For example, since normally a TCP segment that is received over a broadcast transmission is discarded because it does not belong to a established TCP session, a particular TCP implementation may determine that one or more services are advertised in an Options flag just by receiving the Options flag in a TCP segment that is sent in a broadcast transmission. See Also ¶ 0051- ¶ 0052, ¶ 0080). 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 Matsuyama to include the teachings of Stewart. The motivation for doing so is to allow the system to determine that one or more services are advertised in an Options flag just by receiving the Options flag in a TCP segment that is sent in a broadcast transmission (Stewart – ¶0077) . Regarding claim 2 , Matsuyama further teaches wherein the option field further comprises a first subfield and a second subfield, wherein the first subfield comprises the first service information, and wherein the second subfield comprises the second service information (¶ 0027 - the access control server is configured to generate the access permission in a format which comprises: an access-control-server-set fixed field set by the access control server; a service-provider-set option field set by each of the service providers; ¶ 0146 - The option field is a field which is to be filled in by individual service providers (SP). Thus, the option field is composed of sub-fields allocated to a plurality of service providers, each sub-field containing the distinguished name of the service provider, data size and contents – ¶ 0028 - Claim 10,. wherein the service-provider-set option field includes identification data which indicates for each of the service receiving devices whether an access by the service receiving device is permitted, and wherein the identification data includes at least one of personal information concerning the user of the associated service receiving device, user ID, user device ID, and an access permission discrimination flag -See Claim 34), Regarding claim 7, Matsuyama teach a network device comprising: memory configured to store instructions; and one or more processors coupled to the memory and configured to execute the instructions to cause the network device (Fig.3 & Fig.23) to: generate a packet comprising an option field, wherein the option field comprises first service information, second service information [..] (¶ 0027 - the access control server is configured to generate the access permission in a format which comprises: an access-control-server-set fixed field set by the access control server; a service-provider-set option field set by each of the service providers – See Also ¶ 0028, Claim 38 - a processing for receiving, from the device, an access permission accommodating a service provider identification data that identifies the service provider to which the device has been permitted to make an access – Fig.10, ¶ 0139 - FIG. 10 shows a sample of the access permission prepared in the form "B". The access permission has a plurality of fields: a fixed field to be set by the access control server (ACS), an option field to be set by each service provider (SP) and a signature field to be filled by the access control server (ACS). – Note: Fig.10 shows an option field comprising first service provider ID (SP1) and second service (SP2) ¶0146 - The option field is a field which is to be filled in by individual service providers (SP). Thus, the option field is composed of sub-fields allocated to a plurality of service providers, each sub-field containing the distinguished name of the service provider, data size and contents); wherein the first service information corresponds to a first service, wherein the second service information corresponds to a second service, wherein the first service is different from the second service; and send the packet( ¶ 0139 - FIG. 10 shows a sample of the access permission prepared in the form "B". The access permission has a plurality of fields: a fixed field to be set by the access control server (ACS), an option field to be set by each service provider (SP) and a signature field to be filled by the access control server (ACS). – Note: Fig.10 shows an option field comprising first service provider ID (SP1) and second service (SP2) Claim 1 - an access control server which issues to the service receiving device an access permission which identifies a service provider an access to which by the service receiving device is permitted;- Claim 38 - a processing for determining, based on the data contained in the received access permission, whether the device is to be permitted to make an access –See Also Claim 15, ¶ 0033, ¶ 0118,Fig.5 & Fig.6). However, Matsuyama does not explicitly teach the option field comprises a service flag subfield. Wherein the service flag subfield indicates the option field comprises the first service information and second service information. Stewart teaches option field comprises a service flag subfield. Wherein the service flag subfield indicates the option field comprises the first service information and second service information (¶ 0076 - A TCP Options flag typically occupies space at the end of a TCP header. The Options flag begins on an octet boundary and is a multiple of 8 bits in length. The typical length of an Options flag is 40 bytes. FIG. 3B is block diagram that illustrates the format of a TCP Options flag according to one embodiment. In this embodiment, the TCP Options flag includes Option Type field 332, Option Length field 334, Server ID field 336, Discovery ID 338, and Service Parameters field 340 – ¶ 0077 - Option Type field 332 stores information that uniquely identifies the type of the TCP Option. The TCP transport protocol stack at a network element uses the value stored in the Option Type field of a received TCP segment to recognize that one or more services are advertised in the segment. In one embodiment, the value stored in the Option Type field is an 8-bit value that uniquely distinguishes the TCP Option used for service discovery from other types of TCP Options. In this embodiment, the Option Type value is assigned by IANA. Other embodiments may use Option Type values that are not assigned by IANA. For example, since normally a TCP segment that is received over a broadcast transmission is discarded because it does not belong to a established TCP session, a particular TCP implementation may determine that one or more services are advertised in an Options flag just by receiving the Options flag in a TCP segment that is sent in a broadcast transmission. See Also ¶ 0051- ¶ 0052, ¶ 0080). 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 Matsuyama to include the teachings of Stewart. The motivation for doing so is to allow the system to determine that one or more services are advertised in an Options flag just by receiving the Options flag in a TCP segment that is sent in a broadcast transmission (Stewart – ¶0077) . Regarding claim 8, Matsuyama further teaches wherein the option field further comprises a first subfield and a second subfield, wherein the first subfield comprises the first service information, and wherein the second subfield comprises the second service information(¶ 0027 - the access control server is configured to generate the access permission in a format which comprises: an access-control-server-set fixed field set by the access control server; a service-provider-set option field set by each of the service providers; ¶ 0146 - The option field is a field which is to be filled in by individual service providers (SP). Thus, the option field is composed of sub-fields allocated to a plurality of service providers, each sub-field containing the distinguished name of the service provider, data size and contents – ¶ 0028 - Claim 10,. wherein the service-provider-set option field includes identification data which indicates for each of the service receiving devices whether an access by the service receiving device is permitted, and wherein the identification data includes at least one of personal information concerning the user of the associated service receiving device, user ID, user device ID, and an access permission discrimination flag -See Claim 34). Regarding claim 13, Matsuyama further teaches a system, comprising: a first network device configured to: generate a packet comprising an option field, wherein the option field comprises first service information, second service information [..] ( ¶ 0027 - the access control server is configured to generate the access permission in a format which comprises: an access-control-server-set fixed field set by the access control server; a service-provider-set option field set by each of the service providers – See Also ¶ 0028Claim 38 - a processing for receiving, from the device, an access permission accommodating a service provider identification data that identifies the service provider to which the device has been permitted to make an access – Fig.10, ¶ 0139 - FIG. 10 shows a sample of the access permission prepared in the form "B". The access permission has a plurality of fields: a fixed field to be set by the access control server (ACS), an option field to be set by each service provider (SP) and a signature field to be filled by the access control server (ACS). – Note: Fig.10 shows an option field comprising first service provider ID (SP1) and second service (SP2) ¶0146 - The option field is a field which is to be filled in by individual service providers (SP). Thus, the option field is composed of sub-fields allocated to a plurality of service providers, each sub-field containing the distinguished name of the service provider, data size and contents); wherein the first service information corresponds to a first service, wherein the second service information corresponds to a second service, wherein the first service is different from the second service; and send the packet (¶ 0139 - FIG. 10 shows a sample of the access permission prepared in the form "B". The access permission has a plurality of fields: a fixed field to be set by the access control server (ACS), an option field to be set by each service provider (SP) and a signature field to be filled by the access control server (ACS). – Note: Fig.10 shows an option field comprising first service provider ID (SP1) and second service (SP2) Claim 1 - an access control server which issues to the service receiving device an access permission which identifies a service provider an access to which by the service receiving device is permitted;- Claim 38 - a processing for determining, based on the data contained in the received access permission, whether the device is to be permitted to make an access – See Also Claim 15, ¶ 0033, ¶ 0118,Fig.5 & Fig.6); and second network device configured to: receive the packet from the first network device; and process the packet based on the first service information( Claim 38 - a processing for receiving, from the device, an access permission accommodating a service provider identification data that identifies the service provider to which the device has been permitted to make an access – Fig.10, ¶ 0139 - FIG. 10 shows a sample of the access permission prepared in the form "B". The access permission has a plurality of fields: a fixed field to be set by the access control server (ACS), an option field to be set by each service provider (SP) and a signature field to be filled by the access control server (ACS). – Note: Fig.10 shows an option field comprising first service provider ID (SP1) and second service (SP2). However, Matsuyama does not explicitly teach the option field comprises a service flag subfield. Wherein the service flag subfield indicates the option field comprises the first service information and second service information. Stewart teaches option field comprises a service flag subfield. Wherein the service flag subfield indicates the option field comprises the first service information and second service information (¶ 0076 - A TCP Options flag typically occupies space at the end of a TCP header. The Options flag begins on an octet boundary and is a multiple of 8 bits in length. The typical length of an Options flag is 40 bytes. FIG. 3B is block diagram that illustrates the format of a TCP Options flag according to one embodiment. In this embodiment, the TCP Options flag includes Option Type field 332, Option Length field 334, Server ID field 336, Discovery ID 338, and Service Parameters field 340 – ¶ 0077 - Option Type field 332 stores information that uniquely identifies the type of the TCP Option. The TCP transport protocol stack at a network element uses the value stored in the Option Type field of a received TCP segment to recognize that one or more services are advertised in the segment. In one embodiment, the value stored in the Option Type field is an 8-bit value that uniquely distinguishes the TCP Option used for service discovery from other types of TCP Options. In this embodiment, the Option Type value is assigned by IANA. Other embodiments may use Option Type values that are not assigned by IANA. For example, since normally a TCP segment that is received over a broadcast transmission is discarded because it does not belong to a established TCP session, a particular TCP implementation may determine that one or more services are advertised in an Options flag just by receiving the Options flag in a TCP segment that is sent in a broadcast transmission. See Also ¶ 0051- ¶ 0052, ¶ 0080). 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 Matsuyama to include the teachings of Stewart. The motivation for doing so is to allow the system to determine that one or more services are advertised in an Options flag just by receiving the Options flag in a TCP segment that is sent in a broadcast transmission (Stewart – ¶0077) . Regarding claim 14, Matsuyama further teaches controller configured to send, to the first network device, indication information indicating to the first network device to generate the packet, and wherein the first network device is further configured to ,further generate the packet based on the indication information (¶ 0211- ¶ 0213 – based on the request data, creates an access permit (ACPMS), and transmits data {ACPMS} Sig·KsAcsi on which the signature of the access control server (ACSl) 1701 is put to the access-control-server registration server (RACSl) 1702 (process (11)). As for the access permit created by the access control server (ACSl) 1701, there is a plurality of methods, as described above with reference to FIGS. 9 and 10. For example, in the case in accordance with the method A of FIG. 9, it becomes an access permit for each service provider, and in this case, a new access permit which is effective for only the service provider (SP12) 1704 is issued – ¶ 0026 - The arrangement also may be such that the access control server generates the access permission in a form commonly usable for a plurality of service providers – ¶ 0132 - access-control-server registration server 720 receive access permission issuance requests from the user devices 708 and 709 via the service providers 705 to 707, and request the access control server 710 to issue the access permissions based on the access permission issuance). Regarding claim 15, Matsuyama further teaches wherein the first network device is a head node on a forwarding path of the, packet and wherein the second network device is an intermediate node or a tail node on the forwarding path ( Claim 38 -a processing for receiving, from the device, an access permission accommodating a service provider identification data that identifies the service provider to which the device has been permitted to make an access Fig.10, ¶ 0139 - FIG. 10 shows a sample of the access permission prepared in the form "B". The access permission has a plurality of fields: a fixed field to be set by the access control server (ACS), an option field to be set by each service provider (SP) and a signature field to be filled by the access control server (ACS). –¶ 0027 - the access control server is configured to generate the access permission in a format which comprises: an access-control-server-set fixed field set by the access control server; a service-provider-set option field set by each of the service providers – Claim 38 - a processing for determining, based on the data contained in the received access permission, whether the device is to be permitted to make an access – See Also Claim 15, ¶ 0033). Regarding claim 16 , Matsuyama further teaches wherein the option field further comprises a first subfield and a second subfield, wherein the first subfield comprises the first service information, and wherein the second subfield comprises the second service information (¶ 0027 - the access control server is configured to generate the access permission in a format which comprises: an access-control-server-set fixed field set by the access control server; a service-provider-set option field set by each of the service providers; ¶ 0146 - The option field is a field which is to be filled in by individual service providers (SP). Thus, the option field is composed of sub-fields allocated to a plurality of service providers, each sub-field containing the distinguished name of the service provider, data size and contents – ¶ 0028 - Claim 10,. wherein the service-provider-set option field includes identification data which indicates for each of the service receiving devices whether an access by the service receiving device is permitted, and wherein the identification data includes at least one of personal information concerning the user of the associated service receiving device, user ID, user device ID, and an access permission discrimination flag -See Claim 34), Regarding claim 21 , Matsuyama does not explicitly teach wherein the service flag subfield corresponds to m services, wherein the m services comprise the first service and the second service, and wherein m is an integer greater than 1 However, Stewart teaches wherein the service flag subfield corresponds to m services, wherein the m services comprise the first service and the second service, and wherein m is an integer greater than 1 (¶ 0076 - A TCP Options flag typically occupies space at the end of a TCP header. The Options flag begins on an octet boundary and is a multiple of 8 bits in length. The typical length of an Options flag is 40 bytes. FIG. 3B is block diagram that illustrates the format of a TCP Options flag according to one embodiment. In this embodiment, the TCP Options flag includes Option Type field 332, Option Length field 334, Server ID field 336, Discovery ID 338, and Service Parameters field 340 – ¶ 0077 - Option Type field 332 stores information that uniquely identifies the type of the TCP Option. The TCP transport protocol stack at a network element uses the value stored in the Option Type field of a received TCP segment to recognize that one or more services are advertised in the segment. In one embodiment, the value stored in the Option Type field is an 8-bit value that uniquely distinguishes the TCP Option used for service discovery from other types of TCP Options. In this embodiment, the Option Type value is assigned by IANA. Other embodiments may use Option Type values that are not assigned by IANA. For example, since normally a TCP segment that is received over a broadcast transmission is discarded because it does not belong to a established TCP session, a particular TCP implementation may determine that one or more services are advertised in an Options flag just by receiving the Options flag in a TCP segment that is sent in a broadcast transmission. See Also ¶ 0051- ¶ 0052, ¶ 0080). 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 Matsuyama to include the teachings of Stewart. The motivation for doing so is to allow the system to determine that one or more services are advertised in an Options flag just by receiving the Options flag in a TCP segment that is sent in a broadcast transmission (Stewart – ¶0077) . Claims 3-5,9-11,17-19 are rejected under 35 U.S.C. 103 as being unpatentable over Matsuyama in view of Stewart further in view of Abraham et al. Publication No. US 2013/0177001 A1 (Abraham hereinafter) Regarding claim 3 , Matsuyama further teaches wherein the first subfield and the second subfield ( Fig.10, ¶ 0027, ¶ 0146. Claim 10, 34). However, Matsuyama does not explicitly teach that the first subfield and the second subfield have a first length Abraham teaches first subfield and the second subfield have a first length (¶ 0104 - Referring still to FIG. 4, the access network options field 470 can include access services provided by the AP 104. For example, the access network options field 470 can include a 4-bit access network type field, a one-bit internet flag, a one-bit additional step required for access (ASRA) flag, one bit emergency services reachable (ESR) flag, and a one-bit unauthenticated emergency service accessible (UESA) flag. – ¶ 0074 - the frame control (FC) field 410 includes a two-bit version field 411, a two-bit type field 412). 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 Matsuyama to include the teachings of Abraham. The motivation for doing so is to allow the system to have a fixed length fields in order to simplify packet processing by knowing exactly how many bits or bytes to read for each component without needing to read a length indicator first . Regarding claim 4 , Matsuyama further teaches wherein the option field further comprises a third subfield, wherein the third subfield comprises third service information corresponding to a third service that is different from the first service and the second service, wherein the first subfield, the second subfield, and the third subfield are sequentially arranged within the option field( (¶ 0027 - the access control server is configured to generate the access permission in a format which comprises: an access-control-server-set fixed field set by the access control server; a service-provider-set option field set by each of the service providers; ¶ 0146 - The option field is a field which is to be filled in by individual service providers (SP). Thus, the option field is composed of sub-fields allocated to a plurality of service providers, each sub-field containing the distinguished name of the service provider, data size and contents –¶ 0052 - The access control server also may be configured to execute a processing for generating and issuing an access permission containing service provider identification data for a single service provider, or an access permission containing service provider identification data for a plurality of service providers. -See Claim 34, Fig.10). However, Matsuyama does not explicitly teach third subfield has a second length that is different from the first length. Abraham teaches third subfield has a second length that is different from the first length (¶ 0104 - Referring still to FIG. 4, the access network options field 470 can include access services provided by the AP 104. For example, the access network options field 470 can include a 4-bit access network type field, a one-bit internet flag, a one-bit additional step required for access (ASRA) flag, one bit emergency services reachable (ESR) flag, and a one-bit unauthenticated emergency service accessible (UESA) flag. – ¶ 0074 - the frame control (FC) field 410 includes a two-bit version field 411, a two-bit type field 412, a four-bit subtype field 413, a one-bit next fill beacon time indication present flag 414, a one-bit SSID present flag 415, a one-bit internetworking present flag 416, a three-bit bandwidth (BW) field 417, a one-bit security flag 418, and one reserved (RSVD) bit 419. In various embodiments, the FC field 410 can omit one or more fields shown in FIG. 4 and/or include one or more fields not shown in FIG. 4, including any of the fields discussed herein. A person having ordinary skill in the art will appreciate that the fields in the beacon FC field 410 can be of different suitable lengths, and can be in a different order). 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 Matsuyama to include the teachings of Abraham. The motivation for doing so is to allow the system to have a variable length fields in order to allow for attaching optional data which are only included when necessary. This prevents wasting space for information that is not used in every packet. Regarding claim 5 , Matsuyama does not explicitly teach wherein the second length is greater than the first length However, Abraham teaches second length is greater than the first length( ¶ 0104 - Referring still to FIG. 4, the access network options field 470 can include access services provided by the AP 104. For example, the access network options field 470 can include a 4-bit access network type field, a one-bit internet flag, a one-bit additional step required for access (ASRA) flag, one bit emergency services reachable (ESR) flag, and a one-bit unauthenticated emergency service accessible (UESA) flag. – ¶ 0074 - the frame control (FC) field 410 includes a two-bit version field 411, a two-bit type field 412, a four-bit subtype field 413, a one-bit next fill beacon time indication present flag 414, a one-bit SSID present flag 415, a one-bit internetworking present flag 416, a three-bit bandwidth (BW) field 417, a one-bit security flag 418, and one reserved (RSVD) bit 419. In various embodiments, the FC field 410 can omit one or more fields shown in FIG. 4 and/or include one or more fields not shown in FIG. 4, including any of the fields discussed herein. A person having ordinary skill in the art will appreciate that the fields in the beacon FC field 410 can be of different suitable lengths, and can be in a different order). 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 Matsuyama to include the teachings of Abraham. The motivation for doing so is to allow the system to have a variable length fields in order to allow for attaching optional data which are only included when necessary. This prevents wasting space for information that is not used in every packet. Regarding claim 9 , Matsuyama further teaches wherein the first subfield and the second subfield ( Fig.10, ¶ 0027, ¶ 0146. Claim 10, 34). However, Matsuyama does not explicitly teach the first subfield and the second subfield have a first length Abraham teaches first subfield and the second subfield have a first length (¶ 0104 - Referring still to FIG. 4, the access network options field 470 can include access services provided by the AP 104. For example, the access network options field 470 can include a 4-bit access network type field, a one-bit internet flag, a one-bit additional step required for access (ASRA) flag, one bit emergency services reachable (ESR) flag, and a one-bit unauthenticated emergency service accessible (UESA) flag. – ¶ 0074 - the frame control (FC) field 410 includes a two-bit version field 411, a two-bit type field 412). 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 Matsuyama to include the teachings of Abraham. The motivation for doing so is to allow the system to have a fixed length fields in order to simplify packet processing by knowing exactly how many bits or bytes to read for each component without needing to read a length indicator first . Regarding claim 10, Matsuyama further teaches wherein the option field further comprises a third subfield, wherein the third subfield comprises third service information corresponding to a third service that is different from the first service and the second service, wherein the first subfield, the second subfield, and the third subfield are sequentially arranged within the option field( (¶ 0027 - the access control server is configured to generate the access permission in a format which comprises: an access-control-server-set fixed field set by the access control server; a service-provider-set option field set by each of the service providers; ¶ 0146 - The option field is a field which is to be filled in by individual service providers (SP). Thus, the option field is composed of sub-fields allocated to a plurality of service providers, each sub-field containing the distinguished name of the service provider, data size and contents –¶ 0052 - The access control server also may be configured to execute a processing for generating and issuing an access permission containing service provider identification data for a single service provider, or an access permission containing service provider identification data for a plurality of service providers. -See Claim 34, Fig.10), However, Matsuyama does not explicitly teach third subfield has a second length that is different from the first length. Abraham teaches third subfield has a second length that is different from the first length (¶ 0104 - Referring still to FIG. 4, the access network options field 470 can include access services provided by the AP 104. For example, the access network options field 470 can include a 4-bit access network type field, a one-bit internet flag, a one-bit additional step required for access (ASRA) flag, one bit emergency services reachable (ESR) flag, and a one-bit unauthenticated emergency service accessible (UESA) flag. – ¶ 0074 - the frame control (FC) field 410 includes a two-bit version field 411, a two-bit type field 412, a four-bit subtype field 413, a one-bit next fill beacon time indication present flag 414, a one-bit SSID present flag 415, a one-bit internetworking present flag 416, a three-bit bandwidth (BW) field 417, a one-bit security flag 418, and one reserved (RSVD) bit 419. In various embodiments, the FC field 410 can omit one or more fields shown in FIG. 4 and/or include one or more fields not shown in FIG. 4, including any of the fields discussed herein. A person having ordinary skill in the art will appreciate that the fields in the beacon FC field 410 can be of different suitable lengths, and can be in a different order). 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 Matsuyama to include the teachings of Abraham. The motivation for doing so is to allow the system to have a variable length fields in order to allow for attaching optional data which are only included when necessary. This prevents wasting space for information that is not used in every packet. Regarding claim 11 , Matsuyama does not explicitly teach wherein the second length is greater than the first length However, Abraham teaches second length is greater than the first length ¶ 0104 - Referring still to FIG. 4, the access network options field 470 can include access services provided by the AP 104. For example, the access network options field 470 can include a 4-bit access network type field, a one-bit internet flag, a one-bit additional step required for access (ASRA) flag, one bit emergency services reachable (ESR) flag, and a one-bit unauthenticated emergency service accessible (UESA) flag. – ¶ 0074 - the frame control (FC) field 410 includes a two-bit version field 411, a two-bit type field 412, a four-bit subtype field 413, a one-bit next fill beacon time indication present flag 414, a one-bit SSID present flag 415, a one-bit internetworking present flag 416, a three-bit bandwidth (BW) field 417, a one-bit security flag 418, and one reserved (RSVD) bit 419. In various embodiments, the FC field 410 can omit one or more fields shown in FIG. 4 and/or include one or more fields not shown in FIG. 4, including any of the fields discussed herein. A person having ordinary skill in the art will appreciate that the fields in the beacon FC field 410 can be of different suitable lengths, and can be in a different order). 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 Matsuyama to include the teachings of Abraham. The motivation for doing so is to allow the system to have a variable length fields in order to allow for attaching optional data which are only included when necessary. This prevents wasting space for information that is not used in every packet. Regarding claim 17 , Matsuyama further teaches wherein the first subfield and the second subfield ( Fig.10, ¶ 0027, ¶ 0146. Claim 10, 34). However, Matsuyama does not explicitly teach that the first subfield and the second subfield have a first length Abraham teaches first subfield and the second subfield have a first length (¶ 0104 - Referring still to FIG. 4, the access network options field 470 can include access services provided by the AP 104. For example, the access network options field 470 can include a 4-bit access network type field, a one-bit internet flag, a one-bit additional step required for access (ASRA) flag, one bit emergency services reachable (ESR) flag, and a one-bit unauthenticated emergency service accessible (UESA) flag. – ¶ 0074 - the frame control (FC) field 410 includes a two-bit version field 411, a two-bit type field 412). 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 Matsuyama to include the teachings of Abraham. The motivation for doing so is to allow the system to have a fixed length fields in order to simplify packet processing by knowing exactly how many bits or bytes to read for each component without needing to read a length indicator first . Regarding claim 18 , Matsuyama further teaches wherein the option field further comprises a third subfield, wherein the third subfield comprises third service information corresponding to a third service that is different from the first service and the second service, wherein the first subfield, the second subfield, and the third subfield are sequentially arranged within the option field( (¶ 0027 - the access control server is configured to generate the access permission in a format which comprises: an access-control-server-set fixed field set by the access control server; a service-provider-set option field set by each of the service providers; ¶ 0146 - The option field is a field which is to be filled in by individual service providers (SP). Thus, the option field is composed of sub-fields allocated to a plurality of service providers, each sub-field containing the distinguished name of the service provider, data size and contents –¶ 0052 - The access control server also may be configured to execute a processing for generating and issuing an access permission containing service provider identification data for a single service provider, or an access permission containing service provider identification data for a plurality of service providers. -See Claim 34, Fig.10), However, Matsuyama does not explicitly teach third subfield has a second length that is different from the first length. Abraham teaches third subfield has a second length that is different from the first length (¶ 0104 - Referring still to FIG. 4, the access network options field 470 can include access services provided by the AP 104. For example, the access network options field 470 can include a 4-bit access network type field, a one-bit internet flag, a one-bit additional step required for access (ASRA) flag, one bit emergency services reachable (ESR) flag, and a one-bit unauthenticated emergency service accessible (UESA) flag. – ¶ 0074 - the frame control (FC) field 410 includes a two-bit version field 411, a two-bit type field 412, a four-bit subtype field 413, a one-bit next fill beacon time indication present flag 414, a one-bit SSID present flag 415, a one-bit internetworking present flag 416, a three-bit bandwidth (BW) field 417, a one-bit security flag 418, and one reserved (RSVD) bit 419. In various embodiments, the FC field 410 can omit one or more fields shown in FIG. 4 and/or include one or more fields not shown in FIG. 4, including any of the fields discussed herein. A person having ordinary skill in the art will appreciate that the fields in the beacon FC field 410 can be of different suitable lengths, and can be in a different order). 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 Matsuyama to include the teachings of Abraham. The motivation for doing so is to allow the system to have a variable length fields in order to allow for attaching optional data which are only included when necessary. This prevents wasting space for information that is not used in every packet. Regarding claim 19 , Matsuyama does not explicitly teach wherein the second length is greater than the first length However, Abraham teaches second length is greater than the first length (¶ 0104 - Referring still to FIG. 4, the access network options field 470 can include access services provided by the AP 104. For example, the access network options field 470 can include a 4-bit access network type field, a one-bit internet flag, a one-bit additional step required for access (ASRA) flag, one bit emergency services reachable (ESR) flag, and a one-bit unauthenticated emergency service accessible (UESA) flag. – ¶ 0074 - the frame control (FC) field 410 includes a two-bit version field 411, a two-bit type field 412, a four-bit subtype field 413, a one-bit next fill beacon time indication present flag 414, a one-bit SSID present flag 415, a one-bit internetworking present flag 416, a three-bit bandwidth (BW) field 417, a one-bit security flag 418, and one reserved (RSVD) bit 419. In various embodiments, the FC field 410 can omit one or more fields shown in FIG. 4 and/or include one or more fields not shown in FIG. 4, including any of the fields discussed herein. A person having ordinary skill in the art will appreciate that the fields in the beacon FC field 410 can be of different suitable lengths, and can be in a different order). 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 Matsuyama to include the teachings of Abraham. The motivation for doing so is to allow the system to have a variable length fields in order to allow for attaching optional data which are only included when necessary. This prevents wasting space for information that is not used in every packet. Claims 6,12,20 are rejected under 35 U.S.C. 103 as being unpatentable over Matsuyama in view of Stewart further in view of Wang et al. Publication No. US 2014/0181298 A1 ( Wang hereinafter) Regarding claim 6 , Matsuyama does not explicitly teach first length of the first subfield and second length of the second subfield are 2n bits, wherein n is an integer greater than or equal to 3. However, Wang teaches first length of the first subfield and second length of the second subfield are 2n bits, wherein n is an integer greater than or equal to 3 (¶ 0043-¶0044 -. first, the node accepts the configuration of the session limit parameter made by the user or the administrator. Then, the node may generate the session limit capability message. FIG. 5 illustratively shows a diagram of a format of the session limit capability message. As shown in FIG. 5, the session limit capability message may include "code," "length," "sub-code l," "sub-cod e2," "session limit," "current session," "length 1," "length 2," and "reserved" fields. The "code" field may be used as an indicator uniquely indicating the session limit capability, which may be 8 bits. The "length" field may be used to indicate the length of the session limit capability message, which may be 8 bits. The "sub-code l" field may be used to identify a feature of the session limit capability, such as the session limit parameter. The "sub-code 2" field may be used to identify a feature of the current sessions, such as the number of the current sessions. The lengths of the "sub-code l" and "sub-code 2" fields may be both 8 bits. The "session limit" field may be used to indicate a threshold of the number of acceptable sessions, which may be 16 bits. The "current session" field may be used to indicate the actual number of the currently established sessions, which may be 16 bits) 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 Matsuyama to include the teachings of Wang. The motivation for doing so is to allow the system to have a 2nd bit fields in order to allow the system to provide a balance between addressable space ,alignment and efficient hardware processing. Regarding claim 12 , Matsuyama does not explicitly teach first length of the first subfield and second length of the second subfield are 2n bits, wherein n is an integer greater than or equal to 3. However, Wang teaches first length of the first subfield and second length of the second subfield are 2n bits, wherein n is an integer greater than or equal to 3 (¶ 0043-¶0044 -. first, the node accepts the configuration of the session limit parameter made by the user or the administrator. Then, the node may generate the session limit capability message. FIG. 5 illustratively shows a diagram of a format of the session limit capability message. As shown in FIG. 5, the session limit capability message may include "code," "length," "sub-code l," "sub-cod e2," "session limit," "current session," "length 1," "length 2," and "reserved" fields. The "code" field may be used as an indicator uniquely indicating the session limit capability, which may be 8 bits. The "length" field may be used to indicate the length of the session limit capability message, which may be 8 bits. The "sub-code l" field may be used to identify a feature of the session limit capability, such as the session limit parameter. The "sub-code 2" field may be used to identify a feature of the current sessions, such as the number of the current sessions. The lengths of the "sub-code l" and "sub-code 2" fields may be both 8 bits. The "session limit" field may be used to indicate a threshold of the number of acceptable sessions, which may be 16 bits. The "current session" field may be used to indicate the actual number of the currently established sessions, which may be 16 bits) 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 Matsuyama to include the teachings of Wang. The motivation for doing so is to allow the system to have a 2nd bit fields in order to allow the system to provide a balance between addressable space ,alignment and efficient hardware processing. Regarding claim 20 , Matsuyama does not explicitly teach first length of the first subfield and second length of the second subfield are 2n bits, wherein n is an integer greater than or equal to 3. However, Wang teaches first length of the first subfield and second length of the second subfield are 2n bits, wherein n is an integer greater than or equal to 3 (¶ 0043-¶0044 -. first, the node accepts the configuration of the session limit parameter made by the user or the administrator. Then, the node may generate the session limit capability message. FIG. 5 illustratively shows a diagram of a format of the session limit capability message. As shown in FIG. 5, the session limit capability message may include "code," "length," "sub-code l," "sub-cod e2," "session limit," "current session," "length 1," "length 2," and "reserved" fields. The "code" field may be used as an indicator uniquely indicating the session limit capability, which may be 8 bits. The "length" field may be used to indicate the length of the session limit capability message, which may be 8 bits. The "sub-code l" field may be used to identify a feature of the session limit capability, such as the session limit parameter. The "sub-code 2" field may be used to identify a feature of the current sessions, such as the number of the current sessions. The lengths of the "sub-code l" and "sub-code 2" fields may be both 8 bits. The "session limit" field may be used to indicate a threshold of the number of acceptable sessions, which may be 16 bits. The "current session" field may be used to indicate the actual number of the currently established sessions, which may be 16 bits) 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 Matsuyama to include the teachings of Wang. The motivation for doing so is to allow the system to have a 2nd bit fields in order to allow the system to provide a balance between addressable space ,alignment and efficient hardware processing. Claim 22 is rejected under 35 U.S.C. 103 as being unpatentable over Matsuyama in view of Stewart further in view of Yerrabommanahalli et al. Patent No. US 10,057,767 B2 ( Yerrabommanahalli hereinafter) Regarding claim 22 , Matsuyama does not explicitly teach wherein the first service or the second service comprises a slice service, an in-band flow measurement service, an application-aware networking (APN) service, or a deterministic networking (DetNet) service However, Yerrabommanahalli teaches wherein the first service or the second service comprises a slice service, an in-band flow measurement service, an application-aware networking (APN) service, or a deterministic networking (DetNet) service (Abstract , Col.2, lines 25-30 - APN services) 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 Matsuyama to include the teachings of Yerrabommanahalli. The motivation for doing so is to allow the network to instantly identify application-level service requirements without inspecting deep payloads. Conclusion Applicant's amendment necessitated the new ground of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action. Any inquiry concerning this communication or earlier communications from the examiner should be directed to YOUNES NAJI whose telephone number is (571)272-2659. The examiner can normally be reached Monday - Friday 8:30 AM -5:30 PM. Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Oscar A Louie can be reached on (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
Read full office action

Prosecution Timeline

Jun 12, 2024
Application Filed
Jul 29, 2024
Response after Non-Final Action
Feb 17, 2026
Non-Final Rejection mailed — §103
May 13, 2026
Response Filed
Jul 28, 2026
Final Rejection mailed — §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12706891
TUNNELLED REMOTE INTENT MECHANISM
3y 5m to grant Granted Aug 11, 2026
Patent 12665749
MIGRATING SECRETS FROM A CLOUD ENVIRONMENT TO A LOCAL SYSTEM
3y 3m to grant Granted Jun 23, 2026
Patent 12659322
Systems and methods for identifying legitimate network traffic imitation
2y 2m to grant Granted Jun 16, 2026
Patent 12647495
METHODS AND APPARATUS TO IDENTIFY MAIN PAGE VIEWS
1y 8m to grant Granted Jun 02, 2026
Patent 12640930
REDUCING NETWORK LOAD AND LEAD TIME FOR SIGNING A PACKAGE MANAGER FILE
2y 11m to grant Granted May 26, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

3-4
Expected OA Rounds
75%
Grant Probability
99%
With Interview (+73.1%)
2y 11m (~8m remaining)
Median Time to Grant
Moderate
PTA Risk
Based on 444 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month