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 07/29/2024. Claims 1-20 have been examined.
Information Disclosure Statement
The information disclosure statements (IDSs) submitted on 02/26/2025,08/22/2024. The submissions are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered by the examiner.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims 13- 20 in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three, MPEP 2181(I) states in part, (emphasis noted)
“Accordingly, examiners will apply 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph to a claim limitation if it meets the following 3-prong analysis:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as "configured to" or "so that"; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
“With respect to the first prong of this analysis, a claim element that does not include the term “means” or “step” triggers a rebuttable presumption that 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, does not apply. When the claim limitation does not use the term “means,” examiners should determine whether the presumption that 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, paragraph 6 does not apply is overcome. The presumption may be overcome if the claim limitation uses a generic placeholder (a term that is simply a substitute for the term “means”). The following is a list of non-structural generic placeholders that may invoke 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, paragraph 6: “mechanism for,” “module for,” “device for,” “unit for,” “component for,” “element for,” “member for,” “apparatus for,” “machine for,” or “system for.”Welker Bearing Co., v. PHD, Inc., 550 F.3d 1090, 1096, 89 USPQ2d 1289, 1293-94 (Fed. Cir. 2008); Massachusetts Inst. of Tech. v. Abacus Software, 462 F.3d 1344, 1354, 80 USPQ2d 1225, 1228 (Fed. Cir. 2006); Personalized Media, 161 F.3d at 704, 48 USPQ2d at 1886–87; Mas-Hamilton Group v. LaGard, Inc., 156 F.3d 1206, 1214-1215, 48 USPQ2d 1010, 1017 (Fed. Cir. 1998). This list is not exhaustive, and other generic placeholders may invoke 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, paragraph.”
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “device” are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitations use a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitations are
“a first network device configured to generate” as recited in claims 13,14
“a first network device configured to send” as recited in claim 13
“a second network device configured to receive ” as recited in claim 13
“a second network device configured to process ” as recited in claim 13
Based on examiner review of the Published specification , the specification shows that the following appears to be the corresponding structure described in the specification for 35 U.S.C 112 (f0 or pre-AIA 35 U.S.C 112, sixth paragraph limitation:
“a first network device configured to generate” See Published Specification – Figs.11- 13, ¶0398-¶0399 ¶ 0389.
“a first network device configured to send” See Published Specification – Figs.11 -13, ¶0429 ¶ 0466-¶0470.
“a second network device configured to receive ” See Published Specification – Figs.11 -13, ¶0429 ¶ 0466-¶0470.
“a second network device configured to process ” See Published Specification – Fig.11-13, ¶0434-¶0436.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1,2,7,8,13 -16 are rejected under 35 U.S.C. 102 (a1) as being anticipated by Matsuyama et al. Publication No. US 2002/0010861 A1 (Matsuyama 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 – See Also ¶ 0028);
wherein the first service information corresponds to a first service, wherein the second service information corresponds to a second service, and 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).
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 and 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));
wherein the first service information corresponds to a first service, wherein the second service information corresponds to a second service, and 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).
Regarding claim 8,
Matsuyama teach
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 and 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));
wherein the first service information corresponds to a first service, wherein the second service information corresponds to a second service, and 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); 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).
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),
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 3-5,9-11,17-19 are rejected under 35 U.S.C. 103 as being unpatentable over Matsuyama 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 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.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Reznik et al. Publication No. US 2013/0230036 A1.
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