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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 12/18/2024, 01/27/2025, 03/18/2025, and 08/19/2025 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
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.
Claims 1-2, 4-11, and 13-16 are rejected under 35 U.S.C. 102 (a)(1) as being anticipated by Tomida et al. (US 20190297481 A1), hereinafter, Tomida.
Regarding Claim 1, Tomida discloses, a method, comprising:
receiving, by a first device, a basic broadcast frame sent by a second device (Fig. 1, see also, "...According to this embodiment, based on the BLE, the beacon device 100 operates as a slave that transmits advertisement packets to be described later, and the smartphone 200 operates as a master that receives the advertisement packets." [¶0028], see also, Fig. 7, "First, the CPU 110 of the beacon device 100 executes the extended advertisement setting (step S10). When the extended advertisement setting is executed in the step S10, the communicator 103 transmits the advertisement packets that have a type which is “ADV_IND” at a set transmission time interval Ti (step S11)"). [¶0063], and a non-transitory memory storage comprising instructions ("...a Random Access Memory (RAM) 111 as a memory apparatus..." [¶0030]); and one or more processors in communication with the memory, wherein the one or more processors execute the instructions to ("The CPU 110 is a processor that executes various arithmetic processes and comprehensively controls the entire operation of the beacon device 100..." [¶0031]). Here, “advertisement packets” is interpreted as “basic broadcast frame”.
parsing, by the first device, the basic broadcast frame to obtain indication information, wherein the indication information comprises at least one of the following:
first indication information, wherein the first indication information indicates whether content of an extended broadcast frame changes;
second indication information, wherein the second indication information indicates a broadcast type (Fig. 2, "For example, the CPU 110 executes a setting (extended advertisement setting) for specifying the type of the advertisement packets to be transmitted, a transmission time interval of the advertisement packets, and information to be delivered on the advertisement packets. In this example, the CPU 110 sets “ADV_IND” as the type of the advertisement packets. “ADV_IND” is a type of the advertisement packets to notify many and unspecified devices of the presence of the beacon device, and to accept, when a connection request is received, such a connection request..." [¶0051]); “Please note that only one of the claimed features to be mapped because of the presence of “at least one of the following” and “or” in the limitation”. or
third indication information, wherein the third indication information indicates whether content of a scanning response frame changes; and
determining, by the first device based on the indication information, whether to receive the extended broadcast frame (Fig. 7, "As described above, the beacon device 100 has the extended information contained in the advertisement packets which have a type that is “ADV_IND”. This enables the smartphone 200 to determine whether or not the extended advertisement packets are receivable when receiving the advertisement packets that have a type which is “ADV_IND”..."[¶0085], see also, Fig. 9, "When determining that the extended advertisement notification is received (step S205: YES), the CPU 210 displays the data contained in the extended advertisement on the display 206 (Step S206)..." [¶0077]).
Regarding Claim 2, Tomida disclose the method according to claim 1.
Tomida also discloses, wherein the indication information is comprised in a physical layer frame header of the basic broadcast frame (FIG. 4 illustrates an example of a structure of the advertisement packets according to this embodiment. As illustrated in FIG. 4, the Protocol Data Unit (PDU) of the advertisement packets in a link layer is in a size of 2 to 39 bytes, and includes a header (Header) of 2 bytes, and a payload (Payload) of 6 to 37 bytes. The type “ADV_IND” of the advertisement packets is specified by the header[¶0052]; FIG. 6 illustrates an example of a structure of the extended advertisement packets according to this embodiment. As illustrated in FIG. 6, the PDU of the extended advertisement packets in a link layer is in a size that is 2 to 257 bytes, and contains a header (Header) that is 2 bytes and a payload (Payload) that is 255 bytes at maximum..." [¶0057]), and parsing, by the first device, the basic broadcast frame to obtain the indication information comprises ("The CPU 210 as the advertisement receiving controller 221 controls the communicator 203, and receives the advertisement packets broadcasted from the beacon device 100. The CPU 210 controls the communicator 203, and transmits a scan request in response to the received advertisement packets..." [¶0059]):
parsing, by the first device, the physical layer frame header of the basic broadcast frame (See [¶0052] & [¶0057]; Fig. 6, "... Subsequently, when receiving the scan request from the beacon device 100, the communicator 203 outputs, to the CPU 210, an advertisement notification indicating that the advertisement packets has been received. When receiving the advertisement notification from the communicator 203, the CPU 210 obtains data on the scan response received by the communicator 203, and determines whether or not the extended information is contained. When the scan response contains the extended information, the CPU 210 continues the scanning, and waits for an extended advertisement notification from the communicator 203." [¶0060]); and
obtaining, by the first device, the indication information from the physical layer frame header of the basic broadcast frame ("FIG. 6 illustrates an example of a structure of the extended advertisement packets according to this embodiment. As illustrated in FIG. 6, the PDU of the extended advertisement packets in a link layer is in a size that is 2 to 257 bytes, and contains a header (Header) that is 2 bytes and a payload (Payload) that is 255 bytes at maximum..." [¶0057], see also, Fig. 9, "When receiving the advertisement notification (step S202: YES), the CPU 210 obtains the data on the scan response received by the communicator 203 (step S203). Next, the CPU 210 determines whether or not the data obtained in the step S203 contains the extended information (step S204). When determining that the extended information is contained (step S204: YES), the CPU 210 determines whether or not the extended advertisement notification is received from the communicator 203 (step S205). Conversely, when determining that the extended information is not contained (step S204: NO), the CPU 210 returns the process to the step S202, and stands by until receiving the advertisement notification. When determining that the extended advertisement notification is received (step S205: YES), the CPU 210 displays the data contained in the extended advertisement on the display 206 (Step S206). Next, the CPU 210 instructs the communicator 203 to terminate the extended scanning (step S208), and completes this process." [¶0075-¶0077]).
Regarding Claim 4, Tomida disclose the method according to claim 1.
Tomida also teaches, wherein when the indication information comprises the first indication information, determining, by the first device based on the indication information, whether to receive the extended broadcast frame ("...when receiving the scan request received notification from the communicator 103, the CPU 110 executes again the extended advertisement setting. In this example, the CPU 110 sets the type of the advertisement packets as “AUX_ADV_IND” applied for the extended advertisement packets, and sets data to be delivered on the extended advertisement packets..." [¶0056]) comprises:
determining, by the first device based on the first indication information, that the content of the extended broadcast frame changes, and receiving the extended broadcast frame ("FIG. 6 illustrates an example of a structure of the extended advertisement packets according to this embodiment. As illustrated in FIG. 6, the PDU of the extended advertisement packets in a link layer is in a size that is 2 to 257 bytes, and contains a header (Header) that is 2 bytes and a payload (Payload) that is 255 bytes at maximum. Moreover, the payload contains an extended header (Extended Header) that is 64 bytes at maximum and advertising data (AdvData) that is 254 bytes at maximum. Regarding the size of the advertising data, the maximum size varies depending on the size of the extended header, and is 254 bytes (a second maximum size) at maximum." [¶0057]. Please note that only one of the claimed features to be mapped because of the presence of “or” in the limitation); or
determining, by the first device based on the first indication information, that the content of the extended broadcast frame is not changed, and skipping receiving the extended broadcast frame.
Regarding Claim 5, Tomida disclose the method according to claim 1.
Tomida also discloses, wherein when the indication information comprises the second indication information, determining, by the first device based on the indication information, whether to receive the extended broadcast frame comprises ("...The CPU 210 controls the communicator 203, and transmits a scan request in response to the received advertisement packets. Next, the CPU 210 controls the communicator 203, and receives the extended advertisement packets from the beacon device 100 that has received the scan request." [¶0059]):
determining, by the first device based on the broadcast type indicated by the second indication information, whether to receive the extended broadcast frame ("Conversely, after receiving the scan response, the communicator 203 receives, through the channels “37” to “39”, the advertisement packets transmitted from the beacon device 100 and having a type that is “ADV_EXT_IND”. Next, the communicator 203 receives, through the channel specified by the received advertisement packets, the extended advertisement packets that have a type which is “AUX_ADV_IND”. When receiving the extended advertisement packets, the communicator 203 outputs, to the CPU 210, the advertisement notification indicating that the advertisement packets has been received. When receiving the extended advertisement notification from the communicator 203, the CPU 210 obtains data on the extended advertisement packets which has been received by the communicator 203, and displays the data on the display 206." [¶0061]).
Regarding Claim 6, Tomida disclose the method according to claim 1.
Tomida also disclose, wherein when the indication information comprises the third indication information, determining, by the first device based on the indication information, whether to receive the extended broadcast frame comprises (Fig. 5, see also, "...the AD Data contains the “Company ID” and also predetermined information that is extended information (more_data). When, for example, “1” is set in the field of the extended information, this indicates the presence of data to be delivered on the advertisement packets and to be transmitted." [¶0055], see also, "When receiving the scan response received notification from the communicator 103 in the step S14, the CPU 110 of the beacon device 100 executes again the extended advertisement setting (step S17). Next, when the extended advertisement setting is executed again in the step S17, the communicator 103 transmits, through the channels “37” to “39”, the advertisement packets that have a type which is “ADV_EXT_IND” that specifies the channels for transmitting the extended advertisement packets (step S18)..." [¶0067]):
determining, by the first device based on the third indication information, that the content of the scanning response frame has changed, and receiving the extended broadcast frame (Fig. 5, see also, "...the AD Data contains the “Company ID” and also predetermined information that is extended information (more_data). When, for example, “1” is set in the field of the extended information, this indicates the presence of data to be delivered on the advertisement packets and to be transmitted." [¶0055], see also, "When receiving the scan response received notification from the communicator 103 in the step S14, the CPU 110 of the beacon device 100 executes again the extended advertisement setting (step S17). Next, when the extended advertisement setting is executed again in the step S17, the communicator 103 transmits, through the channels “37” to “39”, the advertisement packets that have a type which is “ADV_EXT_IND” that specifies the channels for transmitting the extended advertisement packets (step S18)..." [¶0067]. Please note that only one of the claimed features to be mapped because of the presence of “or” in the limitation), or
determining, by the first device based on the third indication information, that the content of the scanning response frame is not changed, and skipping receiving the extended broadcast frame.
Regarding Claim 7, Tomida disclose the method according to claim 1.
Tomida also discloses, further comprising: determining, by the first device, to receive the extended broadcast frame, and receiving, by the first device, the scanning response frame based on the basic broadcast frame and the extended broadcast frame (Fig 5 & 6, "...when receiving the scan request from the beacon device 100, the communicator 203 outputs, to the CPU 210, an advertisement notification indicating that the advertisement packets has been received. When receiving the advertisement notification from the communicator 203, the CPU 210 obtains data on the scan response received by the communicator 203, and determines whether or not the extended information is contained. When the scan response contains the extended information, the CPU 210 continues the scanning, and waits for an extended advertisement notification from the communicator 203." [¶0060], see also, Fig. 8, "First, the CPU 110 executes the extended advertisement setting (step S101). Next, the CPU 110 determines whether or not the scan request received notification is received from the communicator 103 (step S102). The CPU 110 stands by until the scan request received notification is received (step S102: NO). When receiving the scan request received notification (step S102: YES), the CPU 110 executes the extended advertisement setting again (step S103)." [¶0070-¶0071]); “Please note that only one of the claimed features to be mapped because of the presence of “at least one of the following” and “or” in the limitation; or
determining, by the first device, not to receive the extended broadcast frame, and receiving, by the first device, the scanning response frame based on the basic broadcast frame.
Regarding Claim 8, Tomida discloses a method, comprising:
sending, by a second device, a basic broadcast frame to a first device (Fig. 1, see also, "...According to this embodiment, based on the BLE, the beacon device 100 operates as a slave that transmits advertisement packets to be described later, and the smartphone 200 operates as a master that receives the advertisement packets." [¶0028], see also, Fig. 7, "First, the CPU 110 of the beacon device 100 executes the extended advertisement setting (step S10). When the extended advertisement setting is executed in the step S10, the communicator 103 transmits the advertisement packets that have a type which is “ADV_IND” at a set transmission time interval Ti (step S11)"). [¶0063], Here, “advertisement packets” is interpreted as “basic broadcast frame”.
wherein the basic broadcast frame comprises indication information, the indication information is obtained by the first device by parsing the basic broadcast frame, and the indication information comprises at least one of the following:
first indication information, wherein the first indication information indicates whether content of an extended broadcast frame changes;
second indication information, wherein the second indication information indicates a broadcast type (Fig. 2, "For example, the CPU 110 executes a setting (extended advertisement setting) for specifying the type of the advertisement packets to be transmitted, a transmission time interval of the advertisement packets, and information to be delivered on the advertisement packets. In this example, the CPU 110 sets “ADV_IND” as the type of the advertisement packets. “ADV_IND” is a type of the advertisement packets to notify many and unspecified devices of the presence of the beacon device, and to accept, when a connection request is received, such a connection request..." [¶0051]); “Please note that only one of the claimed features to be mapped because of the presence of “at least one of the following” and “or” in the limitation”; or
third indication information, wherein the third indication information indicates whether content of a scanning response frame changes.
Regarding Claim 9, Tomida discloses the method according to claim 8,
Tomida also discloses, wherein the indication information is comprised in a physical layer frame header of the basic broadcast frame (FIG. 4 illustrates an example of a structure of the advertisement packets according to this embodiment. As illustrated in FIG. 4, the Protocol Data Unit (PDU) of the advertisement packets in a link layer is in a size of 2 to 39 bytes, and includes a header (Header) of 2 bytes, and a payload (Payload) of 6 to 37 bytes. The type “ADV_IND” of the advertisement packets is specified by the header[¶0052]; FIG. 6 illustrates an example of a structure of the extended advertisement packets according to this embodiment. As illustrated in FIG. 6, the PDU of the extended advertisement packets in a link layer is in a size that is 2 to 257 bytes, and contains a header (Header) that is 2 bytes and a payload (Payload) that is 255 bytes at maximum..." [¶0057]), and parsing, by the first device, the basic broadcast frame to obtain the indication information comprises ("The CPU 210 as the advertisement receiving controller 221 controls the communicator 203, and receives the advertisement packets broadcasted from the beacon device 100. The CPU 210 controls the communicator 203, and transmits a scan request in response to the received advertisement packets..." [¶0059]. Please note that only one of the claimed features to be mapped because of the presence of “or” in the limitation). or
a physical layer payload header of the basic broadcast frame.
Regarding Claim 10 “Apparatus”, is rejected under the same reasoning as Claim 1 “Method”, where Tomida teaches Method/Apparatus.
Regarding Claim 11 “Apparatus”, is rejected under the same reasoning as Claim 2 “Method”, where Tomida teaches Method/Apparatus.
Regarding Claim 13 “Apparatus”, is rejected under the same reasoning as Claim 4 “Method”, where Tomida teaches Method/Apparatus.
Regarding Claim 14 “Apparatus”, is rejected under the same reasoning as Claim 5 “Method”, where Tomida teaches Method/Apparatus.
Regarding Claim 15 “Apparatus”, is rejected under the same reasoning as Claim 6 “Method”, where Tomida teaches Method/Apparatus.
Regarding Claim 16 “Apparatus”, are rejected under the same reasoning as Claim 7 “Method”, where Takahashi teaches Method/Apparatus.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 3 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Tomida in view of Batra et al. (US 20200059784 A1, hereinafter, Batra).
Regarding Claim 3, Tomida disclose the method according to claim 1.
Tomida doesn’t explicitly teach, wherein the indication information is comprised in a physical layer payload header of the basic broadcast frame, and parsing, by the first device, the basic broadcast frame to obtain the indication information comprises:
parsing, by the first device, the physical layer payload header of the basic broadcast frame and
obtaining, by the first device, the indication information from the physical layer payload header of the basic broadcast frame.
Batra, in analogous art discloses, wherein the indication information is comprised in a physical layer payload header of the basic broadcast frame, and parsing, by the first device, the basic broadcast frame to obtain the indication information comprises:
parsing, by the first device, the physical layer payload header of the basic broadcast frame (Fig. 15, see also, "...Each BR packet (for example, in the form of a protocol data unit (PDU)) generally includes three portions: an access code, a header and a payload (which may have zero length)...The packet header includes the link control information including a logical transport address and a packet type identification. In master-to-slave transmissions, the logical transport address indicates the destination slave STA 404 (or multiple slaves in the case of broadcast transmissions) by which the packet is intended to be received, while in slave-to-master transmissions, the logical transport address indicates the source STA 404 transmitting the packet." [¶0061], see also, "... an access address (including an access code), a PDU header and a PDU payload. LE packets may also include a message integrity check (MIC) and a cyclic redundancy check (CRC) following the payload." [¶0062]) and
obtaining, by the first device, the indication information from the physical layer payload header of the basic broadcast frame (“FIG. 15 shows an example protocol data unit (PDU) 1500 usable for communicating via a backchannel according to some implementations. For example, the PDU 1500 may be used by the first wireless communication device (the receiving device) to transmit the challenge request including the authentication token to the second wireless communication device...The PDU 1500 includes a header 1502 and a data field 1504 that includes the authentication token in the case of a challenge request, and a secret code in the case of a challenge response. The header 1502 includes a transmit address field 1506 identifying the transmitter of the PDU 1500. The header 1502 also may include a receive address field 1508 identifying a target of the PDU 1500. In some implementations, the data field 1504 itself includes a number of fields (or “sub-fields”) as well including, for example, a timing field 1510, an encryption field 1512 and an authentication field 1514. The timing field 1510 may include a timestamp, for example, identifying the current date and time, and in some instances, the current time zone." [¶0134]).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to combine the teaching of Tomida with the idea that the process of obtaining indication information from a basic broadcast frame involves parsing technique at the physical layer as disclosed by Batra. The rationale for placing indication information within the physical layer (PHY) payload header of a basic broadcast frame and having the first device parse it directly from there offers several significant advantages in wireless communications, primarily focusing on efficiency, speed, and reduced power consumption.
Regarding Claim 12 “Apparatus”, is rejected under the same reasoning as Claim 3 “Method”, where Batra teaches Method/Apparatus.
Conclusion
References cited but not used: TAKAHASHI et al. (US 20200037229 A1) can be used for independent claims 1, 8 and 10 in addition to the one used.
References cited but not used: ERICKSEN et al. (US 20220210650 A1) can be used for independent claims 1, 8 and 10 in addition to the one used.
References cited but not used: Liu et al. (US 20190174401 A1) can be used for independent claims 4 and 13 in addition to the one used.
References cited but not used: INOUE et al. (US 20230061186 A1) can be used for independent claims 6 and 15 in addition to the one used.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MUHAMMAD AINUL HUDA whose telephone number is (703)756-1594. The examiner can normally be reached M-F 8:30 - 6:30 ET.
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, HASSAN PHILLIPS can be reached on (571)272-3940. 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.
/MUHAMMAD AINUL HUDA/Examiner, Art Unit 2467
/MOHAMMED S CHOWDHURY/Primary Examiner, Art Unit 2467
Prosecution Insights