DETAILED ACTION
Notice of Pre-AIA or AIA Status
1.The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
2. A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 02/11/2026 has been entered.
Response to Arguments
3. According to applicant's arguments filed on 01/12/2026; claims 1,4-5 and 7-10 have been amended, and claim 3 has been cancelled, hereby acknowledged.
4. Regarding 103 rejection, applicant argues that the prior art of record (Fox in view of Van Duren) fails to teach the amended claim limitation of independent claims , which recites: “sharing a same message authentication code (MAC) key and a same session key between the user terminal and the UAV, based on the first information and the second information”.
5 . Examiner would like to point out that, the new secondary reference Baskaran (US Pub.No.2023/0284030) teaches the above claimed limitation (see, the rejection below).
Double Patenting
6. The non-statutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper time wise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A non-statutory obviousness-type double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on a nonstatutory double patenting ground provided the conflicting application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement.
Effective January 1, 1994, a registered attorney or agent of record may sign a terminal disclaimer. A terminal disclaimer signed by the assignee must fully comply with 37 CFR 3.73(b).
7. Claims 1-2 and 4-10 of the instant application are provisionally rejected on the ground of non-statutory double patenting as being unpatentable over claims 1-10 of the co-pending application 18/038,844. Although the claims at issue are not identical, they are not patentably distinct from each other because the claims of the current application encompass the same subject matter as the co-pending application claims, but with obvious wording variations such as [a method of operating an electronic device that provides a key agreement protocol. The method may include obtaining at least one of an ID of user, a first anonymous ID of the user corresponding to the ID of the user and a first temporary authentication value of the user, from a user terminal, obtaining at least one of an ID of an unmanned aerial vehicle (UAV), a first anonymous ID of the UAV corresponding to the ID of the UAV and a first temporary authentication value of the UAV, from the UAV, and in response to a key agreement request of the user terminal or a key agreement request of the UAV, intermediating key agreement between the UAV and the user terminal based on first information including information obtained from the user terminal and second information including information obtained from the UAV]. This is a provisional non-statutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
Claim Rejections - 35 USC § 103
8.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.
9. Claim(s) 1-2 and 4-10 are rejected under 35 U.S.C. 103 as being unpatentable over Fox (US Pub.No.2018/0103036) in view of Van Duren (US Pub.No.2022/0345453) and in view of Baskaran (US Pub.No.2023/0284030) .
10. Regarding claim 1 Fox teaches a method of operating an electronic device, comprising: obtaining first information including an ID of a user and a first temporary authentication value of the user, from a user terminal; obtaining second information including an ID of an unmanned aerial vehicle (UAV), a first temporary authentication value of the UAV, from the UAV (Para:0031 teaches the drone/CPV management authority (DMA) for managing drone operator licenses (DOLs), which contain identifying information about a drone operator and the drone itself. DOLs are useful for enforcing legal restrictions on operation and ensuring safe movement and operation of drones. Para:0083-0085 teaches in order to prove its identity, the drone/CPV has to first register its license with the DMA 405. The DMA 405 returns a cryptographically signed drone token (CSDT), which allows for the drone/CPV to prove its identity in the future. Once the CSDT has been received by the drone it can be used to verify its identity.
Para:108-0109 teaches the DOL may be a license linked to digital drone operator attributes. The drone operator attributes can include, but are not limited to, the drone operator's name, the drone operator's home address and the drone operator's date of birth. In addition to the attributes, the DOL may include, but is not limited to, a class of license, the expiration date of the license, the issue date of the license, unique identifier, restrictions, and special exemptions. The drone/CPV and DOL should be generated by a trusted third-party organization such as a government agency, for example the FAA, or an independent organization.
Fig.3, Para:0079-0081 and Para:0091 teaches CPV/ drone 305 may be one of a plurality of vehicles, each vehicle including a computing device having a unique identity and an operator associated with the vehicle. Drone authentication component 310 may include drone attributes 315, drone license 320, drone public key 325, drone private key 330, and drone DMA token 335); and
in response to a key agreement request of the user terminal or of the UAV, intermediating key agreement between the UAV and the user terminal based on the first information from the user terminal and the second information obtained from the UAV (Fig.1 and Para:0060 teaches the relay node 135 can be fixed stationary (e.g., ground station) or mobile (e.g., UAV, handheld device, or temporary ground station). The relay node 135 establishes mutually authenticated communications with CPV 105 requesting connection. Para:0259 teaches the relay nodes can be installed or operated by governmental agencies as a part of the nation's critical infrastructure, known as public relay nodes. Private relay nodes can be owned by individuals or private organizations and may exist as open or closed relay nodes. A closed relay node is a node that has restrictive access requirements based on specific drone license attributes. An individual can set up her own closed relay node to enhance her own flight. The relay node in this case would provide data to a drone/CPV with the correct ID, namely her ID.
Para:0268-0269 teaches For local authorization, the relay node has a set of rules to determine which drones are allowed to connect. These rules could restrict connection to a particular type of license, a particular amount of use, or a particular class of owners. The specifications are left to an implementation decision. For external authorization, the cryptographically signed drone token is sent to an authorization server over a secure connection. The authorization server maintains a list of authorized users or a set of rules to validate users. The authorization server uses these rules to provide a yes/no authorized decision which is returned to the relay node. The relay node provides services based on this yes/no decision. Once the drone/CPV has been authenticated and authorized properly the relay node and drone have shared public/private keys. These public/private key pairs allow for the bi-directional exchange of encrypted and authenticated messages between drone and relay node. One possible approach would be for the relay node and drone to exchange encrypted private keys allowing for future symmetric cryptography. Now that cryptographic keys have been securely distributed, bi-directional, authenticated, and encrypted communications can occur).
Fox teaches all the above claimed limitations but does not expressly teach obtaining a first anonymous ID of the user corresponding to the ID of the user; and a first anonymous ID of the UAV corresponding to the ID of the UAV
.
Van Duren teaches obtaining a first anonymous ID of the user corresponding to the ID of the user; and a first anonymous ID of the UAV corresponding to the ID of the UAV (para:0043-0045 teaches generate an anonymity token that is associated with a digital certificate of a UAV, provide the anonymity token to the UAV for use in operations. The anonymity token may include an indication that the UAV (and/or the UAV operator) is entitled to perform operations anonymously.Para:0051 teaches each of the plurality of anonymity tokens may be limited to use in a single transmission (i.e., one-time-use). In this manner, the UAV may transmit messages that are authenticatable and anonymous as to the identity of the UAV and/or its operator).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the invention was filed to modify the teachings of Fox to include obtaining an anonymous ID of the user corresponding to the ID of the user; and an anonymous ID of the UAV corresponding to the ID of the UAV as taught by Van Duren such a setup will give a predictable result of protect the identity and personal information from being exposed.
Baskaran teaches sharing a same message authentication code (MAC) key and a same session key between the user terminal and the UAV, based on the first information and the second information (Figs.1,5 and Para:0005-0008, Para:0191-0198 teaches sharing message authentication code (MAC) key and session key between the unmanned aerial vehicle (UAV, 106) and a user equipment device (UAV-C, 108)).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the invention was filed to modify the teachings of Fox in view of Van Duren to include sharing a same message authentication code (MAC) key and a same session key between the user terminal and the UAV as taught by Baskaran such a setup will ensure the integrity of data being transmitted.
11. Regarding claim 2 Fox in view of Van Duren teaches the method, wherein the key agreement request of the UAV corresponds to transmitting the first anonymous ID of the UAV from the UAV to the user terminal, and wherein the key agreement request of the user terminal corresponds to transmitting the first anonymous ID of the user terminal from the user terminal to the UAV (Fox: Para:0268-0269; Van Duren :Para:0043-0045 and Para:0051-0053).
12. Regarding claim 4 Van Duren teaches the method wherein the first anonymous ID of the user and the first temporary authentication value of the user are randomly generated regardless of the ID of the user (Para:0051-0053).
13. Regarding claim 5 Fox teaches the method, wherein the first information comprises at least one of a second anonymous ID different from the first anonymous ID of the user, a second temporary authentication value different from the first temporary authentication value of the user and a random number value of the user (Para:0079-0081, Para:0091 and Para:108-0109).
14. Regarding claim 6 Van Duren teaches the method, wherein the first anonymous ID of the UAV and the first temporary authentication value of the UAV are randomly generated regardless of the ID of the UAV (Para:0051-0053).
15. Regarding claim 7 Fox in view of Van Duren teaches the method, wherein the second information further comprises at least one of a second anonymous ID different from the first anonymous ID of the UAV, a second temporary authentication value different from the first temporary authentication value of the UAV and a random number value of the UAV (Fox: Para:0268-0269; Van Duren :Para:0043-0045 and Para:0051-0053).
16. Regarding claim 8 Fox teaches a method of operating a user terminal, comprising: identifying first information including an ID of a user that is input from the user, and a first temporary authentication value of the user (Para:0031 teaches the drone/CPV management authority (DMA) for managing drone operator licenses (DOLs), which contain identifying information about a drone operator and the drone itself. DOLs are useful for enforcing legal restrictions on operation and ensuring safe movement and operation of drones. Para:0083-0085 teaches in order to prove its identity, the drone/CPV has to first register its license with the DMA 405. The DMA 405 returns a cryptographically signed drone token (CSDT), which allows for the drone/CPV to prove its identity in the future. Once the CSDT has been received by the drone it can be used to verify its identity.
Para:108-0109 teaches the DOL may be a license linked to digital drone operator attributes. The drone operator attributes can include, but are not limited to, the drone operator's name, the drone operator's home address and the drone operator's date of birth. In addition to the attributes, the DOL may include, but is not limited to, a class of license, the expiration date of the license, the issue date of the license, unique identifier, restrictions, and special exemptions. The drone/CPV and DOL should be generated by a trusted third-party organization such as a government agency, for example the FAA, or an independent organization.
Fig.3, Para:0079-0081 and Para:0091 teaches CPV/ drone 305 may be one of a plurality of vehicles, each vehicle including a computing device having a unique identity and an operator associated with the vehicle. Drone authentication component 310 may include drone attributes 315, drone license 320, drone public key 325, drone private key 330, and drone DMA token 335); and
generating an encryption key and a first secret key by using the first temporary authentication value; and generating a same second secret key and a same session key shared between the user terminal and the UAV based on at least one piece of information related to the user and at least one piece of information related to the UAV (Fig.1 and Para:0060 teaches the relay node 135 can be fixed stationary (e.g., ground station) or mobile (e.g., UAV, handheld device, or temporary ground station). The relay node 135 establishes mutually authenticated communications with CPV 105 requesting connection. Para:0259 teaches the relay nodes can be installed or operated by governmental agencies as a part of the nation's critical infrastructure, known as public relay nodes. Private relay nodes can be owned by individuals or private organizations and may exist as open or closed relay nodes. A closed relay node is a node that has restrictive access requirements based on specific drone license attributes. An individual can set up her own closed relay node to enhance her own flight. The relay node in this case would provide data to a drone/CPV with the correct ID, namely her ID.
Para:0268-0269 teaches For local authorization, the relay node has a set of rules to determine which drones are allowed to connect. These rules could restrict connection to a particular type of license, a particular amount of use, or a particular class of owners. The specifications are left to an implementation decision. For external authorization, the cryptographically signed drone token is sent to an authorization server over a secure connection. The authorization server maintains a list of authorized users or a set of rules to validate users. The authorization server uses these rules to provide a yes/no authorized decision which is returned to the relay node. The relay node provides services based on this yes/no decision. Once the drone/CPV has been authenticated and authorized properly the relay node and drone have shared public/private keys. These public/private key pairs allow for the bi-directional exchange of encrypted and authenticated messages between drone and relay node. One possible approach would be for the relay node and drone to exchange encrypted private keys allowing for future symmetric cryptography. Now that cryptographic keys have been securely distributed, bi-directional, authenticated, and encrypted communications can occur);
Fox teaches all the above claimed limitations but does not expressly teach identifying first information including a first anonymous ID of the user corresponding to the ID of the user; from a UAV requesting key agreement, obtaining second information including a first anonymous ID of the UAV corresponding an ID of the UAV.
Van Duren teaches identifying first information including a first anonymous ID of the user corresponding to the ID of the user; from a UAV requesting key agreement, obtaining second information including a first anonymous ID of the UAV corresponding an ID of the UAV;
generating a second anonymous ID different from the first anonymous ID of the user and a second temporary authentication value different from the first temporary authentication value of the user (Para:0043-0045 teaches generate an anonymity token that is associated with a digital certificate of a UAV, provide the anonymity token to the UAV for use in operations. The anonymity token may include an indication that the UAV (and/or the UAV operator) is entitled to perform operations anonymously.Para:0051 teaches each of the plurality of anonymity tokens may be limited to use in a single transmission (i.e., one-time-use). In this manner, the UAV may transmit messages that are authenticatable and anonymous as to the identity of the UAV and/or its operator).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the invention was filed to modify the teachings of Fox to include obtaining a first anonymous ID of the UAV corresponding an ID of the UAV and a first anonymous ID of the user corresponding to the ID of the user as taught by Van Duren such a setup will give a predictable result of protect the identity and personal information from being exposed.
Fox in view of Van Duren teaches all the above claimed limitations, but does not expressly teach the method generating a MAC key and a same session key shared between the user terminal and the UAV based on at least one piece of information related to the user terminal and at least one piece of information related to the UAV.
Baskaran teaches generating a MAC key and a same session key shared between the user terminal and the UAV based on at least one piece of information related to the user terminal and at least one piece of information related to the UAV (Figs.1,5 and Para:0005-0008, Para:0191-0198 teaches sharing message authentication code (MAC) key and session key between the unmanned aerial vehicle (UAV, 106) and a user equipment device (UAV-C, 108)).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the invention was filed to modify the teachings of Fox in view of Van Duren to include sharing a same message authentication code (MAC) key and a same session key between the user terminal and the UAV as taught by Baskaran such a setup will ensure the integrity of data being transmitted.
17. Regarding claim 9 Fox teaches a method of operating a UAV, comprising: obtaining first information including a first anonymous ID of a user terminal corresponding to an ID of the user terminal from the user terminal requesting key agreement; identifying second information including an ID of the UAV, a first anonymous ID of the UAV corresponding to the ID of the UAV, and a first temporary authentication value of the UAV; generating an encryption key and a first MAC key using the first temporary authentication value; generating a second anonymous ID different from the first anonymous ID of the UAV and a second temporary authentication value different from the first temporary authentication value of the UAV; and generating a same second MAC key and a same session key shared between the user terminal and the UAV based on the first information and the second information (see, the rejection for claim 8).
18. Regarding claim 10 Fox teaches an electronic device comprising: a communication device; a memory for storing at least one instruction; and a controller configured to: obtain first information including an ID of a user, a first anonymous ID of the user corresponding to the ID of the user and a first temporary authentication value of the user, from a user terminal;
obtain second information including an ID of an unmanned aerial vehicle (UAV), a first anonymous ID of the UAV corresponding to the ID of the UAV and a first temporary authentication value of the UAV, from the UAV; and in response to a key agreement request of the user terminal or a key agreement request of the UAV, intermediate key agreement between the UAV and the user terminal based on first information including information obtained from the user terminal and second information including information obtained from the UAV; and share a same message authentication code (MAC) key and a same session key between the user terminal and the UAV, based on the first information and the second information (see, the rejection for claim 1).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DEREENA T CATTUNGAL whose telephone number is (571)270-0506. The examiner can normally be reached Mon-Fri : 7:30 AM-5 PM EST.
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, Lynn Field can be reached on 571-272-2092. 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.
/DEREENA T CATTUNGAL/Primary Examiner, Art Unit 2431