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 .
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 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.
Claim(s) 1 - 20 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by IEEE P802.11be/D1.01.
IEEE teaches:
1. A method for negotiating traffic-to-link mapping configuration, applied to a multi-link device, the multi-link device (MLD) comprising a higher-layer management entity and a lower-layer management entity (See 9.6.35.3 TID-To-Link Mapping Response frame format), wherein the method comprises:
sending, by the higher-layer management entity, a first traffic-to-link mapping request primitive to the lower-layer management entity, wherein the first traffic-to-link mapping request primitive comprises an address of a peer device, a negotiation session identifier and traffic-to-link mapping configuration information, and the peer device is a multi-link device (TIDs are mapped to all setup links using utilizing message frames and control frames between AP-MLD and non-AP MLDs, IEEE, p. 281);
sending, by the lower-layer management entity, a first traffic-to-link mapping request message to the peer device, wherein the first traffic-to-link mapping request message comprises a type of the message, a negotiation session identifier, traffic-to-link mapping configuration information and an instruction whether to use default configuration, and setting the first traffic-to-link mapping request message according to the first traffic-to-link mapping request primitive (see 35.3.6.1.3 Negotiation of TID-to-link mapping);
receiving, by the lower-layer management entity, a traffic-to-link mapping response message from the peer device, wherein the traffic-to-link mapping response message comprises a type of the message, a negotiation session identifier and a processing status for a request (see 35.3.6.1.3 Negotiation of TID-to-link mapping); and
sending, by the lower-layer management entity, a traffic-to-link mapping confirm primitive to the higher-layer management entity, wherein the traffic-to-link mapping confirm primitive comprises an address of the peer device, a negotiation session identifier and a processing status for a request, and setting the traffic-to-link mapping confirm primitive according to a received traffic-to-link mapping response message (see 35.3.6.1.3 Negotiation of TID-to-link mapping, especially p.282 which defines frame elements for creating the links, see also 9.6.35 which demonstrates fields for mapping request and response frames).
2. The method for negotiating traffic-to-link mapping configuration as claimed in claim 1, wherein the sending, by the lower-layer management entity, the first traffic-to-link mapping request message to the peer device comprises:
with the address of the peer device in the first traffic-to-link mapping request primitive being an address of the multi-link device, sending the first traffic-to-link mapping request message to the peer device on any link (see 35.3.6.1.3 Negotiation of TID-to-link mapping, especially p.282 which defines frame elements for creating the links, see also 9.6.35 which demonstrates fields for mapping request and response frames);
alternatively, with the address of the peer device in the first traffic-to-link mapping request primitive being an address of a logical entity belonging to the multi-link device, sending the first traffic-to-link mapping request message to the peer device on a link corresponding to the logical entity (see 35.3.6.1.3 Negotiation of TID-to-link mapping, especially p.282 which defines frame elements for creating the links, see also 9.6.35 which demonstrates fields for mapping request and response frames).
3. The method for negotiating traffic-to-link mapping configuration as claimed in claim 1, wherein under a condition that the processing status for the request indicates acceptance of the request or suggestion, the traffic-to-link mapping response message and the traffic-to-link mapping confirm primitive each further comprise traffic-to-link mapping configuration information, and the traffic-to-link mapping response message further comprises an instruction whether to use default configuration (see 35.3.6.1.3 Negotiation of TID-to-link mapping, especially p.282 which defines frame elements for creating the links, see also 9.6.35 which demonstrates fields for mapping request and response frames).
4. The method for negotiating traffic-to-link mapping configuration as claimed in claim 3, further comprising:
carrying out, by the higher-layer management entity, traffic-to-link mapping configuration according to the traffic-to-link mapping confirm primitive under a condition that the processing status for the request in the traffic-to-link mapping confirm primitive indicates acceptance of the request (see 35.3.6.1.3 Negotiation of TID-to-link mapping, especially p.282 which defines frame elements for creating the links, see also 9.6.35 which demonstrates fields for mapping request and response frames); and
not changing, by the higher-layer management entity, current traffic-to-link mapping configuration or setting, by the higher-layer management entity, the current traffic-to-link mapping configuration as default configuration under a condition that the processing status for the request in the traffic-to-link mapping confirm primitive indicates refuse of the request (see 35.3.6.1.3 Negotiation of TID-to-link mapping, especially p.282 which defines frame elements for creating the links, see also 9.6.35 which demonstrates fields for mapping request and response frames).
5. The method for negotiating traffic-to-link mapping configuration as claimed in claim 3, further comprising:
determining, by the higher-layer management entity, whether to accept suggested configuration parameters according to self-traffic conditions, or self-capability, or operation limitation under the condition that the processing status for request in the traffic-to-link mapping confirm primitive indicates suggestion, carrying out traffic-to-link mapping configuration according to suggested parameters under the condition that the suggested configuration parameters are accepted, and not changing current traffic-to-link mapping configuration or setting the current traffic-to-link mapping configuration as default configuration under the condition that the suggested configuration parameters are not accepted (see 35.3.6.1.3 Negotiation of TID-to-link mapping, especially the first four paragraphs of p.283 which defines negotiation and acceptance or denial, for forming the links, see also 9.6.35 which demonstrates fields for mapping request and response frames).
6. The method for negotiating traffic-to-link mapping configuration as claimed in claim 1, further comprising:
sending, by the higher-layer management entity, a traffic-to-link mapping termination request primitive or a second traffic-to-link mapping request primitive to the lower-layer management entity, so as to instruct the lower-layer management entity to send a traffic-to-link mapping termination message or a second traffic-to-link mapping request message to ask the peer device to terminate use of current traffic-to-link mapping configuration (see 35.3.6.1.3 Negotiation of TID-to-link mapping, especially the first four paragraphs of p.283 which defines tearing down links and renegotiation, see also 9.6.35 which demonstrates fields for mapping request and response frames); and
sending, by the lower-layer management entity, the second traffic-to-link mapping request message or the traffic-to-link mapping termination message to the peer device, so as to instruct the peer device to terminate use of the current traffic-to-link mapping configuration, and setting the second traffic-to-link mapping request message or the traffic-to-link mapping termination message according to the traffic-to-link mapping termination request primitive or the second traffic-to-link mapping request primitive (see 35.3.6.1.3 Negotiation of TID-to-link mapping, especially the first four paragraphs of p.283 which defines tearing down links and renegotiation, see also 9.6.35 which demonstrates fields for mapping request and response frames).
7. The method for negotiating traffic-to-link mapping configuration as claimed in claim 6, wherein the traffic-to-link mapping termination request primitive comprises an address of the peer device (see generally section 9 which demonstrates the multiple fields and frame formats, including a device address);
the second traffic-to-link mapping request primitive comprises an address of the peer device and an instruction to use default configuration (see 35.3.6.1.3 Negotiation of TID-to-link mapping, especially p.282 which defines mapping negotiations, see also 9.6.35 which demonstrates fields for mapping request and response frames); and
the second traffic-to-link mapping request message comprises a type of the message and an instruction whether to use default configuration (see 35.3.6.1.3 Negotiation of TID-to-link mapping, p.282 which defines mapping negotiations, see also 9.6.35 which demonstrates fields for mapping request and response frames).
8. The method for negotiating traffic-to-link mapping configuration as claimed in claim 6, wherein the sending, by the lower-layer management entity, the second traffic-to-link mapping request message or the traffic-to-link mapping termination message to the peer device comprises:
with an address of the peer device in the traffic-to-link mapping termination request primitive or the second traffic-to-link mapping request primitive being an address of a multi-link device, sending the second traffic-to-link mapping request message or the traffic-to-link mapping termination message to the peer device on any link (see 35.3.6.1.3 Negotiation of TID-to-link mapping, especially the first four paragraphs of p.283 which defines tearing down links and renegotiation, see also 9.6.35 which demonstrates fields for mapping request and response frames);
alternatively, with the address of the peer device in the traffic-to-link mapping termination request primitive or the second traffic-to-link mapping request primitive being an address of a logical entity belonging to the multi-link device, sending the second traffic-to-link mapping request message or the traffic-to-link mapping termination message to the peer device on a link corresponding to the logical entity (see 35.3.6.1.3 Negotiation of TID-to-link mapping, especially the first four paragraphs of p.283 which defines tearing down links and renegotiation, see also 9.6.35 which demonstrates fields for mapping request and response frames).
9. The method for negotiating traffic-to-link mapping configuration as claimed in claim 1, wherein the setting the first traffic-to-link mapping request message according to the first traffic-to-link mapping request primitive comprises:
setting the instruction whether to use default configuration in the first traffic-to-link mapping request message as an instruction not to use default configuration according to a type of the first traffic-to-link mapping request primitive or the traffic-to-link mapping configuration information comprised in the first traffic-to-link mapping request primitive (see 35.3.6.1.3 Negotiation of TID-to-link mapping, especially the first four paragraphs of p.283 which defines tearing down links and renegotiation, see also 9.6.35 which demonstrates fields for mapping request and response frames).
10. The method for negotiating traffic-to-link mapping configuration as claimed in claim 7, wherein the setting the second traffic-to-link mapping request message according to the traffic-to-link mapping termination request primitive or the second traffic-to-link mapping request primitive comprises:
setting an instruction whether to use default configuration in the second traffic-to-link mapping request message as an instruction to use default configuration according to a type of the traffic-to-link mapping termination request primitive or the second traffic-to-link mapping request primitive, or according to an instruction whether to use default configuration in the second traffic-to-link mapping request primitive (see 35.3.6.1.3 Negotiation of TID-to-link mapping, p.282 which defines mapping negotiations, see also 9.6.35 which demonstrates fields for mapping request and response frames).
11. The method for negotiating traffic-to-link mapping configuration as claimed in claim 1, wherein the first traffic-to-link mapping request primitive further comprises an instruction not to use default configuration, and the traffic-to-link mapping confirm primitive further comprises an instruction whether to use default configuration (see 35.3.6.1.3 Negotiation of TID-to-link mapping, p.282 which defines mapping negotiations, see also 9.6.35 which demonstrates fields for mapping request and response frames).
12. The method for negotiating traffic-to-link mapping configuration as claimed in claim 1, wherein the traffic-to-link mapping configuration information comprises a first parameter, a second parameter, and one or more third parameters, the first parameter being used for indicating that traffics match links for uplink, or downlink, or uplink and downlink, the second parameter being used for indicating which traffics are to be configured, and the third parameter being used for indicating links matching traffics which are to be configured as indicated by the second parameter (see 35.3.6.1.3 Negotiation of TID-to-link mapping, p.282 which defines mapping negotiations, see also 9.6.35 which demonstrates fields for mapping request and response frames).
13. A method for negotiating traffic-to-link mapping configuration, applied to a multi-link device, the multi-link device comprising a higher-layer management entity and a lower-layer management entity, wherein the method comprises:
receiving, by the lower-layer management entity, a first traffic-to-link mapping request message from a peer device, wherein the first traffic-to-link mapping request message comprises a type of the message, a negotiation session identifier, traffic-to-link mapping configuration information, and an instruction whether to use default configuration, and the peer device is a multi-link device (TIDs are mapped to all setup links using utilizing message frames and control frames between AP-MLD and non-AP MLDs, IEEE, p. 281);
sending, by the lower-layer management entity, a first traffic-to-link mapping indication primitive to the higher-layer management entity, wherein the first traffic-to-link mapping indication primitive comprises an address of the peer device, a negotiation session identifier and traffic-to-link mapping configuration information, and setting the first traffic-to-link mapping indication primitive according to the first traffic-to-link mapping request message (see 35.3.6.1.3 Negotiation of TID-to-link mapping);
sending, by the higher-layer management entity, a traffic-to-link mapping response primitive to the lower-layer management entity, wherein the traffic-to-link mapping response primitive comprises an address of the peer device, a negotiation session identifier and a processing status for a request, and setting the traffic-to-link mapping response primitive according to the first traffic-to-link mapping indication primitive (see 35.3.6.1.3 Negotiation of TID-to-link mapping); and
sending, by the lower-layer management entity, a traffic-to-link mapping response message to the peer device, wherein the traffic-to-link mapping response message comprises a type of the message, a negotiation session identifier and a processing status for a request, and setting the traffic-to-link mapping response message according to the traffic-to-link mapping response primitive (see 35.3.6.1.3 Negotiation of TID-to-link mapping, especially p.282 which defines frame elements for creating the links, see also 9.6.35 which demonstrates fields for mapping request and response frames).
14. The method for negotiating traffic-to-link mapping configuration according to claim 13, wherein the sending, by the lower-layer management entity, a traffic-to-link mapping response message to the peer device comprises:
with the address of the peer device in the traffic-to-link mapping response primitive being an address of the multi-link device, sending the traffic-to-link mapping response message to the peer device on any link (see 35.3.6.1.3 Negotiation of TID-to-link mapping, especially p.282 which defines frame elements for creating the links, see also 9.6.35 which demonstrates fields for mapping request and response frames);
alternatively, with the address of the peer device in the traffic-to-link mapping response primitive being an address of a logical entity belonging to the multi-link device, sending the traffic-to-link mapping response message to the peer device on a link corresponding to the logical entity (see 35.3.6.1.3 Negotiation of TID-to-link mapping, especially p.282 which defines frame elements for creating the links, see also 9.6.35 which demonstrates fields for mapping request and response frames).
15. The method for negotiating traffic-to-link mapping configuration according to claim 13, wherein under the condition that the processing status for the request indicates acceptance of the request or suggestion, the traffic-to-link mapping response primitive and the traffic-to-link mapping response message each further comprise traffic-to-link mapping configuration information, and the traffic-to-link mapping response message further comprises an instruction whether to use default configuration (see 35.3.6.1.3 Negotiation of TID-to-link mapping, especially p.282 which defines frame elements for creating the links, see also 9.6.35 which demonstrates fields for mapping request and response frames).
16. The method for negotiating traffic-to-link mapping configuration according to claim 13, further comprising:
receiving, by the lower-layer management entity, a second traffic-to-link mapping request message or a traffic-to-link mapping termination message from the peer device, wherein the second traffic-to-link mapping request message or the traffic-to-link mapping termination message is used for asking to terminate use of current traffic-to-link mapping configuration (see 35.3.6.1.3 Negotiation of TID-to-link mapping, especially the first four paragraphs of p.283 which defines tearing down links and renegotiation, see also 9.6.35 which demonstrates fields for mapping request and response frames);
sending, by the lower-layer management entity, a traffic-to-link mapping termination indication primitive or a second traffic-to-link mapping indication primitive to the higher-layer management entity, so as to instruct the higher-layer management entity to terminate use of the current traffic-to-link mapping configuration, and setting the traffic-to-link mapping termination indication primitive or the second traffic-to-link mapping indication primitive according to the second traffic-to-link mapping request message or the traffic-to-link mapping termination message (see 35.3.6.1.3 Negotiation of TID-to-link mapping, especially the first four paragraphs of p.283 which defines tearing down links and renegotiation, see also 9.6.35 which demonstrates fields for mapping request and response frames); and
setting, by the higher-layer management entity, the traffic-to-link mapping configuration as default configuration (see 35.3.6.1.3 Negotiation of TID-to-link mapping, especially the first four paragraphs of p.283 which defines tearing down links and renegotiation, see also 9.6.35 which demonstrates fields for mapping request and response frames).
17. The method for negotiating traffic-to-link mapping configuration according to claim 16, wherein the second traffic-to-link mapping request message comprises a type of the message and an instruction to use default configuration (see 35.3.6.1.3 Negotiation of TID-to-link mapping, especially the first four paragraphs of p.283 which defines tearing down links and renegotiation, see also 9.6.35 which demonstrates fields for mapping request and response frames);
the traffic-to-link mapping termination indication primitive comprises an address of the peer device (see generally section 9 which demonstrates the multiple fields and frame formats, including a device address); and
the second traffic-to-link mapping indication primitive comprises an address of the peer device and an instruction whether to use default configuration (see 35.3.6.1.3 Negotiation of TID-to-link mapping, especially the first four paragraphs of p.283 which defines tearing down links and renegotiation, see also 9.6.35 which demonstrates fields for mapping request and response frames).
18. The method for negotiating traffic-to-link mapping configuration according to claim 15 wherein the setting the traffic-to-link mapping response message according to the traffic-to-link mapping response primitive comprises:
setting an instruction whether to use default configuration in the traffic-to-link mapping response message as an instruction not to use default configuration according to a type of the traffic-to-link mapping response primitive or the traffic-to-link mapping configuration information comprised in the traffic-to-link mapping response primitive (see 35.3.6.1.3 Negotiation of TID-to-link mapping, especially the first four paragraphs of p.283 which defines tearing down links and renegotiation, see also 9.6.35 which demonstrates fields for mapping request and response frames).
19. The method for negotiating traffic-to-link mapping configuration according to claim 17, wherein the setting the second traffic-to-link mapping indication primitive according to the second traffic-to-link mapping request message or the traffic-to-link mapping termination message comprises:
setting the instruction whether to use default configuration in the second traffic-to-link mapping indication primitive as an instruction to use default configuration according to a type of the second traffic-to-link mapping request message or the traffic-to-link mapping termination message, or according to the instruction to use default configuration in the second traffic-to-link mapping request message (see 35.3.6.1.3 Negotiation of TID-to-link mapping, especially the first four paragraphs of p.283 which defines tearing down links and renegotiation, see also 9.6.35 which demonstrates fields for mapping request and response frames).
20. A device for negotiating traffic-to-link mapping configuration, comprising a processor and a memory, wherein the memory stores a command executable by the processor, and the command is loaded and executed by the processor to implement the method for negotiating traffic-to-link mapping configuration of any one of claims 1 (see 35.3.6.1.3 Negotiation of TID-to-link mapping).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to PETER G SOLINSKY whose telephone number is (571)270-7216. The examiner can normally be reached M - Th, 6:30 A - 5:00 P.
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, Pankaj Kumar can be reached on 571-272-3011. 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.
PETER G. SOLINSKY
Examiner
Art Unit 2463
/Peter G Solinsky/Primary Examiner, Art Unit 2463