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 .
Information Disclosure Statement
The information disclosure statements (IDSs) submitted on February 12, 2024, September 1, 2024, and October 27, 2025 were filed in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner except were stricken. The Report on Patentability dated August 28, 2025 was not provided in the information disclosure statement.
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.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-6, 17-23, and 33-44 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by U.S. Publication No. 2022/0200789 (hereinafter “Lalande”) with priority to WIPO Publication No. 2020/214701, which names PrestaCom Services LLC as the inventive entity, WIPO Publication No. 2020/214701 was also published in 2020 and is prior art under 102(a)(1).
Regarding claim 1, Lalande teaches: A method for managing delegation of location services, the method comprising: receiving, at a delegate server from a delegate device (1402), authentication credentials ([0180] The identity server 2320 includes one or more networked server devices that provide services related to acquiring information relating to users, user accounts, and/or devices associated with users and user accounts. . . . The identification token can be based on one or more user or account identifiers and a unique entity or device identifier, which can be combined to generate an entity or device token that at least quasi-uniquely identifies each device. The identification token can be used by the owner device 1402 and delegate device 1904 to register for various services provided via the identity management infrastructure.) for a sub-delegate (1904) of a delegate entity ([0180] The identification token for each device can be associated with an online user account associated with the device.); determining at least one locator service (0170) for an accessory device (201), the at least one locator service accessible to the delegate device with the received authentication credentials ([0044] device locator service 170 can each be associated with a cloud service provider, where the various services are facilitated via a cloud services account associated with the mobile devices 102A-102B.); receiving, from the delegate device, a request for the at least one locator service ([0003] Current security features in handheld and portable products allow the location of the product to be identified when requested by the user); evaluating a set of inputs to determine if a set of conditions corresponding to the at least one locator service and the delegate device are satisfied ([0198] The sharee/delegate can also use the beacon UUID to request a new set of keys if the pre-determined period of time expires before new keys are sent by the owner. [0199] The share capability field 2524 can be used to specify the set of capabilities that will be shared with the sharee/delegate. The capabilities granted to a sharee or delegate can be determined based on the set of keys that are shared.); upon determination that the set of conditions are satisfied, sending the request for the at least one locator service to a device locator server ([0062] The mobile device 102, upon loading the device locator UI 204, can send a request (330) for location data to the device locator server 203.); and decrypting a response ([0051] The device locator server 203 can then return any stored location data that corresponds with the public encryption key. The location data returned to the mobile device 102 can be encrypted data that is encrypted by the finder device 202 using the public encryption key.) to the request received from the device locator server using one or more encryption keys stored for the delegate entity ([0051] The mobile device 102 can use an associated private key to decrypt the encrypted location data.).
Regarding claim 2, Lalande teaches: sending, to the delegate device, a set of locator services permitted with a role for the sub-delegate with the received authentication credentials ([0157] Delegation can be performed by the owner device 1402 by generating keys in the third set of keys (owner & delegate keys) depicted in FIG. 15 for a predetermined number of privacy windows and providing those keys to the delegate device 1904 via the transfer 1905 of delegate keys.).
Regarding claim 3, Lalande teaches: wherein at least one condition from the set of conditions is that the sub-delegate is associated with the delegate entity ([0157] The transferred delegate keys can enable the delegate device 1904, via a delegate UI 1906, to perform a set of operations including but not limited to tracking, accessing, using, or controlling the wireless accessory 1430.).
Regarding claim 4, Lalande teaches: wherein at least one condition from the set of conditions is that a status of the accessory device is not at least one of a near owner status or a near sharee status ([0157] Delegation can be performed by the owner device 1402 by generating keys in the third set of keys (owner & delegate keys) depicted in FIG. 15 for a predetermined number of privacy windows and providing those keys to the delegate device 1904 via the transfer 1905 of delegate keys.).
Regarding claim 5, Lalande teaches: wherein the near owner status includes that an owner device is within beacon signal range of the accessory device ([0057]).
Regarding claim 6, Lalande teaches: sending, to the delegate device, the response to the request, wherein the response is encrypted with a cryptographic key generated with a shared secret between the delegate device and a device paired with the accessory device ([0069] After generating the public/private keypair and one or more additional shared secrets, the mobile device can store public/private key pair to a keystore (block 404). In one embodiment the keystore is a cloud-based keystore that can be synchronized with other devices associated with the same cloud services account, or family of cloud services accounts, to which the mobile device and wireless accessory are associated. [0078], [0136]).
Regarding claim 17, Lalande teaches: A method for a delegate device (1402) for accessing location services (170) for an accessory device (201), the method comprising: sending, to a delegate server, authentication credentials ([0180] The identity server 2320 includes one or more networked server devices that provide services related to acquiring information relating to users, user accounts, and/or devices associated with users and user accounts. . . . The identification token can be based on one or more user or account identifiers and a unique entity or device identifier, which can be combined to generate an entity or device token that at least quasi-uniquely identifies each device. The identification token can be used by the owner device 1402 and delegate device 1904 to register for various services provided via the identity management infrastructure.) for a sub-delegate (1904) of a delegate entity ([0180] The identification token for each device can be associated with an online user account associated with the device.) and information on at least one condition for accessing location services for the accessory device ([0199] The share capability field 2524 can be used to specify the set of capabilities that will be shared with the sharee/delegate. The capabilities granted to a sharee or delegate can be determined based on the set of keys that are shared; [0203] The owner device 2603 then performs operation 2604 to create a shared beacon record for the share recipient and set the accepted state to false. The shared beacon record can be written to a local container that is synchronized with a remote container on a server associated with a cloud datastore.); receiving information on a set of location services accessible for the authentication credentials satisfying the at least one condition ([0086] In one embodiment, when a user launches a device locator UI and communicates with the locator service front-end 803, the locator service front-end can communicate with the account database 825 and provide a current or last known location for each device that is associated with a requesting user, including devices and/or wireless accessories associated with other users that are in a family of accounts associated with the requesting user.); sending, to the delegate server, a request for locator services for the accessory device ([0062] The mobile device 102, upon loading the device locator UI 204, can send a request (330) for location data to the device locator server 203.); and receiving an encrypted response for the request ([0051] The device locator server 203 can then return any stored location data that corresponds with the public encryption key. The location data returned to the mobile device 102 can be encrypted data that is encrypted by the finder device 202 using the public encryption key.).
Regarding claim 18, Lalande teaches: receiving, from an electronic device, a set of delegate keys (Fig. 15) and metadata, the metadata indicating an event with the delegate entity ([0056] In one embodiment the wireless accessory 201 can transmit the beacon signal 301 every two seconds, although other beacon rates can be used, and the beacon rate can vary under certain circumstances. For example, the wireless accessory 201 can decrease a beacon rate when in a near owner state. Beacon rate can also vary based on accelerometer triggered events.).
Regarding claim 19, Lalande teaches: receiving, from an electronic device, a delegate shared secret ([0069] After generating the public/private keypair and one or more additional shared secrets, the mobile device can store public/private key pair to a keystore (block 404). In one embodiment the keystore is a cloud-based keystore that can be synchronized with other devices associated with the same cloud services account, or family of cloud services accounts, to which the mobile device and wireless accessory are associated. [0078], [0136]); and decrypting the encrypted response with decryption keys generated in part using the delegate shared secret ([0051] The mobile device 102 can use an associated private key to decrypt the encrypted location data.).
Regarding claim 20, Lalande teaches: wherein the at least one condition for accessing location services is determined based on a sub-delegate role of the sub-delegate at the delegate entity ([0157] Delegation can be performed by the owner device 1402 by generating keys in the third set of keys (owner & delegate keys) depicted in FIG. 15 for a predetermined number of privacy windows and providing those keys to the delegate device 1904 via the transfer 1905 of delegate keys.).
Regarding claim 21, Lalande teaches: wherein satisfying the at least one condition comprises: sending, to the delegate server, location information for the delegate device ([0048] If the wireless accessory lacks access to a network to send a location to the device locator server 203, the wireless accessory can encode encrypted location data within the beacon signal 301. Finder device 202 can then relay the encrypted location data to the device locator server 203.); and receiving an indication that the delegate device with the authenticated authentication credentials for the sub-delegate is located in at least one delegate entity location authorized for the request ([0142] In one embodiment, a primary device 1602 can place a secondary device 1630 into a near owner state when the primary device 1602 detects the nearby presence of the secondary device 1630. In one embodiment, the secondary device 1630 is placed into the near owner state before certain commands may be issued. The secondary device 1630 can be placed into the near owner state using a token that is derived in part based on a command key CKi and a diversified public key Pi.).
Regarding claim 22, Lalande teaches: detecting, from the accessory device, a beacon signal ([0157] beacon signal); and transmitting location information for the accessory device to at least one of an owner device or a location server ([0157] For example, the owner device 1402 can delegate to the delegate device 1904 the ability to detect 1933 the wireless accessory via a beacon signal 1431 transmitted by the wireless accessory 1430 in the same manner in which the owner can detect 1932 the wireless device. The owner device 1402 can also delegate the ability to query 1922 a location of the wireless accessory 1430 via the device locator server 1920 in the same manner as the owner device 1402 can query 1921 the location of the wireless accessory 1430.).
Regarding claim 23, Lalande teaches: wherein the location information is encrypted using encryption keys generated using at least a shared secret between the delegate device and a device paired with the accessory device ([0069] After generating the public/private keypair and one or more additional shared secrets, the mobile device can store public/private key pair to a keystore (block 404). In one embodiment the keystore is a cloud-based keystore that can be synchronized with other devices associated with the same cloud services account, or family of cloud services accounts, to which the mobile device and wireless accessory are associated. [0078], [0136]).
Regarding claim 33, Lalande teaches: One or more non-transitory computer-readable media comprising computer-executable instructions that, when executed by one or more processors of a delegate server, cause the delegate server to perform operations comprising: receiving, at a delegate server from a delegate device (1402), authentication credentials ([0180] The identity server 2320 includes one or more networked server devices that provide services related to acquiring information relating to users, user accounts, and/or devices associated with users and user accounts. . . . The identification token can be based on one or more user or account identifiers and a unique entity or device identifier, which can be combined to generate an entity or device token that at least quasi-uniquely identifies each device. The identification token can be used by the owner device 1402 and delegate device 1904 to register for various services provided via the identity management infrastructure.) for a sub-delegate (1904) of a delegate entity ([0180] The identification token for each device can be associated with an online user account associated with the device.); determining at least one locator service (0170) for an accessory device (201), the at least one locator service accessible to the delegate device with the received authentication credentials ([0044] device locator service 170 can each be associated with a cloud service provider, where the various services are facilitated via a cloud services account associated with the mobile devices 102A-102B.); receiving, from the delegate device, a request for the at least one locator service ([0003] Current security features in handheld and portable products allow the location of the product to be identified when requested by the user); evaluating a set of inputs to determine if a set of conditions corresponding to the at least one locator service and the delegate device are satisfied ([0198] The sharee/delegate can also use the beacon UUID to request a new set of keys if the pre-determined period of time expires before new keys are sent by the owner. [0199] The share capability field 2524 can be used to specify the set of capabilities that will be shared with the sharee/delegate. The capabilities granted to a sharee or delegate can be determined based on the set of keys that are shared.); upon determination that the set of conditions are satisfied, sending the request for the at least one locator service to a device locator server ([0062] The mobile device 102, upon loading the device locator UI 204, can send a request (330) for location data to the device locator server 203.); and decrypting a response ([0051] The device locator server 203 can then return any stored location data that corresponds with the public encryption key. The location data returned to the mobile device 102 can be encrypted data that is encrypted by the finder device 202 using the public encryption key.) to the request received from the device locator server using one or more encryption keys stored for the delegate entity ([0051] The mobile device 102 can use an associated private key to decrypt the encrypted location data.).
Regarding claim 34, Lalande teaches: sending, to the delegate device, a set of locator services permitted with a role for the sub-delegate with the received authentication credentials ([0157] Delegation can be performed by the owner device 1402 by generating keys in the third set of keys (owner & delegate keys) depicted in FIG. 15 for a predetermined number of privacy windows and providing those keys to the delegate device 1904 via the transfer 1905 of delegate keys.).
Regarding claim 35, Lalande teaches: wherein at least one condition from the set of conditions is that the sub-delegate is associated with the delegate entity ([0157] The transferred delegate keys can enable the delegate device 1904, via a delegate UI 1906, to perform a set of operations including but not limited to tracking, accessing, using, or controlling the wireless accessory 1430.).
Regarding claim 36, Lalande teaches: wherein at least one condition from the set of conditions is that a status of the accessory device is not at least one of a near owner status or a near sharee status ([0157] Delegation can be performed by the owner device 1402 by generating keys in the third set of keys (owner & delegate keys) depicted in FIG. 15 for a predetermined number of privacy windows and providing those keys to the delegate device 1904 via the transfer 1905 of delegate keys.).
Regarding claim 37, Lalande teaches: wherein the near owner status includes that an owner device is within beacon signal range of the accessory device ([0057]).
Regarding claim 38, Lalande teaches: sending, to the delegate device, the response to the request, wherein the response is encrypted with a cryptographic key generated with a shared secret between the delegate device and a device paired with the accessory device ([0069] After generating the public/private keypair and one or more additional shared secrets, the mobile device can store public/private key pair to a keystore (block 404). In one embodiment the keystore is a cloud-based keystore that can be synchronized with other devices associated with the same cloud services account, or family of cloud services accounts, to which the mobile device and wireless accessory are associated. [0078], [0136]).
Regarding claim 39, Lalande teaches: A server system, comprising: memory configured to store computer-executable instructions; and a processor configured to access the memory and execute the computer- executable instructions to at least: receive, at a delegate server from a delegate device (1402), authentication credentials ([0180] The identity server 2320 includes one or more networked server devices that provide services related to acquiring information relating to users, user accounts, and/or devices associated with users and user accounts. . . . The identification token can be based on one or more user or account identifiers and a unique entity or device identifier, which can be combined to generate an entity or device token that at least quasi-uniquely identifies each device. The identification token can be used by the owner device 1402 and delegate device 1904 to register for various services provided via the identity management infrastructure.) for a sub-delegate (1904) of a delegate entity ([0180] The identification token for each device can be associated with an online user account associated with the device.); determine at least one locator service (0170) for an accessory device (201), the at least one locator service accessible to the delegate device with the received authentication credentials ([0044] device locator service 170 can each be associated with a cloud service provider, where the various services are facilitated via a cloud services account associated with the mobile devices 102A-102B.); receive, from the delegate device, a request for the at least one locator service ([0003] Current security features in handheld and portable products allow the location of the product to be identified when requested by the user); evaluate a set of inputs to determine if a set of conditions corresponding to the at least one locator service and the delegate device are satisfied ([0198] The sharee/delegate can also use the beacon UUID to request a new set of keys if the pre-determined period of time expires before new keys are sent by the owner. [0199] The share capability field 2524 can be used to specify the set of capabilities that will be shared with the sharee/delegate. The capabilities granted to a sharee or delegate can be determined based on the set of keys that are shared.); upon determination that the set of conditions are satisfied, send the request for the at least one locator service to a device locator server ([0062] The mobile device 102, upon loading the device locator UI 204, can send a request (330) for location data to the device locator server 203.); and decrypting a response ([0051] The device locator server 203 can then return any stored location data that corresponds with the public encryption key. The location data returned to the mobile device 102 can be encrypted data that is encrypted by the finder device 202 using the public encryption key.) to the request received from the device locator server using one or more encryption keys stored for the delegate entity ([0051] The mobile device 102 can use an associated private key to decrypt the encrypted location data.).
Regarding claim 40, Lalande teaches: sending, to the delegate device, a set of locator services permitted with a role for the sub-delegate with the received authentication credentials ([0157] Delegation can be performed by the owner device 1402 by generating keys in the third set of keys (owner & delegate keys) depicted in FIG. 15 for a predetermined number of privacy windows and providing those keys to the delegate device 1904 via the transfer 1905 of delegate keys.).
Regarding claim 41, Lalande teaches: wherein at least one condition from the set of conditions is that the sub-delegate is associated with the delegate entity ([0157] The transferred delegate keys can enable the delegate device 1904, via a delegate UI 1906, to perform a set of operations including but not limited to tracking, accessing, using, or controlling the wireless accessory 1430.).
Regarding claim 42, Lalande teaches: wherein at least one condition from the set of conditions is that a status of the accessory device is not at least one of a near owner status or a near sharee status ([0157] Delegation can be performed by the owner device 1402 by generating keys in the third set of keys (owner & delegate keys) depicted in FIG. 15 for a predetermined number of privacy windows and providing those keys to the delegate device 1904 via the transfer 1905 of delegate keys.).
Regarding claim 43, Lalande teaches: wherein the near owner status includes that an owner device is within beacon signal range of the accessory device ([0057]).
Regarding claim 44, Lalande teaches: sending, to the delegate device, the response to the request, wherein the response is encrypted with a cryptographic key generated with a shared secret between the delegate device and a device paired with the accessory device ([0069] After generating the public/private keypair and one or more additional shared secrets, the mobile device can store public/private key pair to a keystore (block 404). In one embodiment the keystore is a cloud-based keystore that can be synchronized with other devices associated with the same cloud services account, or family of cloud services accounts, to which the mobile device and wireless accessory are associated. [0078], [0136]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
WIPO Publication No. 2020/214701 related to sharing keys for a wireless accessory
U.S. Publication No. 2021/0400492 related to secure pairing and pairing lock for accessory devices
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JUSTIN BARRY whose telephone number is (571)272-0201. The examiner can normally be reached 8:00am EST to 5:00pm 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, Jinsong HU can be reached at (571) 272-3965. 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.
/JAB/ Examiner, Art Unit 2643
/JINSONG HU/ Supervisory Patent Examiner, Art Unit 2643
Prosecution Insights