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 .
Response to Amendment
The Amendment filed August 24, 2026 has been entered. Claims 1-7, 9-13, and 15-22 are pending in the application. Applicant has submitted amendments to the claims along with other remarks. Applicant’s amendments regarding 112(b) have overcome the rejection. Applicant’s amendments to the drawings have overcome most of the objections. Claims 1-7, 9-13, and 15-22 are still rejected by prior art references, refer to the following rejection for details.
Response to Arguments
Applicant’s arguments and amendments, see pp. 7-13 of the response, filed August 24, 2026, with respect to the rejection(s) of claim(s) 1-7, 9-13, and 15-22 under § 102 have been fully considered and are persuasive. However, upon further consideration for the amendments, a new ground(s) of rejection is made in view of new reference, please see the rejection for details.
Drawings
The drawings are objected to because they include underlined reference characters that require lead lines (e.g., S501, S502, S504, S802, S804). Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. The figure or figure number of an amended drawing should not be labeled as “amended.” If a drawing figure is to be canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the remaining figures must be renumbered and appropriate changes made to the brief description of the several views of the drawings for consistency. Additional replacement sheets may be necessary to show the renumbering of the remaining figures. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Claim Rejections - 35 USC § 103
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
Claims 1-6, 9-13, and 15-17, 19, and 21-22 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Publication No. 2021/0400492 (hereinafter “Movva”) in view of U.S. Publication No. 2022/0182374 (hereinafter “Peddada”)
Regarding claim 1, Movva teaches: A system, comprising a second electronic device (mobile device 230), and a server (pairing lock server 240), wherein the second electronic device comprises a first application (locator app 310, OS 320), and the first application requests to access a first electronic device ([0043] As shown in FIG. 4A, the operations can begin in response to an app launch action at locator app 310 to add a new item (401)); the second electronic device is configured to: receive identification information of the first electronic device from the first electronic device ([0037] Mobile device 230 can initiate pairing (205), causing accessory 220 to generate pairing data (207) and send the pairing data (209). [0033] During the pairing process with the electronic device, a payload including the secure token can be encrypted using the public key of the server and transmitted to the server to for validation, along with identifying information for the accessory. If the correct keys and secure token are used and the accessory is determined to be a valid and legitimate accessory, the registration server will indicate that the pairing request is valid and allow the pairing to continue.); and send authentication request information of the first application to the server, wherein the authentication request information comprises the identification information of the first electronic device and application information of the first application ([0063] The first electronic device can then generate a parting request including pairing data having a first portion associated with the first electronic device and a second portion associated with the second electronic device (606).); the server is configured to: receive the authentication request information (Step 213); determine an authentication result based on the authentication request information (Step 217); and send the authentication result (Step 221); and the second electronic device is further configured to: receive the authentication result (Step 221); and determine, based on the authentication result, whether the first application accesses the first electronic device (Step 225).
Movva teaches sending a certificate in an authentication request ([0048] the generated payload=(SessionNonce, C1, Software Token, UUID, Serial Number, productId, vendorId, fw_version, E1, SeedK1). The accessory 220 can then generate (423) encrypted pairing data E2, where E2=Encrypt pairing data (Payload). Encrypted pairing data E2 is an encrypted pairing blob that is encrypted for transmission to the pairing lock server 240, where the pairing boob [sic] will be decoded by the pairing lock server 240 and verified. The accessory 220 can then send (424) the encrypted pairing blob (E2) and “Pair” opcode to the wireless logic 330. The wireless logic 330 can then send the (425) encrypted blob received from the accessory 220 to the mobile device OS 320.); and verifying the certificate in the authentication request ([0048] where the pairing boob [sic] will be decoded by the pairing lock server 240 and verified.).
Movva, however, does not explicitly teach: send authentication request information of the first application to the server, wherein the authentication request information comprises a certificate of the first application; the server is configured to: verify whether the certificate of the first application is correct; after verifying the certificate of the first application, determine an authentication result.
However, in the same field of endeavor, Peddada teaches: send authentication request information of the first application to the server, wherein the authentication request information comprises a certificate of the first application ([0049] client digital certificate chain associated with he tenant); the server is configured to: verify whether the certificate of the first application is correct; after verifying the certificate of the first application, determine an authentication result ([0050] validating the digital certificate chain of the client.).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify Movva to include the feature of an application signature and a combination of Movva with Peddada renders the claim prima facie obvious within the described scope of the prior art and any indicated differences within the level of one of ordinary skill in the art (e.g., telecommunications engineer) according to a combination of known prior art elements with known methods to yield predictable results. MPEP 2143(I)(A) (e.g., providing a certificate associated with the application or tenant).
Regarding claim 2, Movva teaches: wherein the second electronic device is configured to: when the first application requests to access the first electronic device, receive the identification information of the first electronic device from the first electronic device ([0037] Mobile device 230 can initiate pairing (205), causing accessory 220 to generate pairing data (207) and send the pairing data (209).).
Regarding claim 3, Movva teaches: wherein the second electronic device is configured to: when the first application requests to access the first electronic device, obtain the identification information that is of the first electronic device and that is on the second electronic device and send the authentication request information of the first application to the server ([0037] Mobile device 230 can then generate (211) a pairing request to send to pairing lock server 240, then send (213) the pairing request to pairing lock server 240.).
Regarding claim 4, Movva teaches: wherein the authentication request information further comprises identification information of the second electronic device ([0063] The first electronic device can then generate a parting request including pairing data having a first portion associated with the first electronic device and a second portion associated with the second electronic device (606).).
Regarding claim 5, Movva teaches: wherein the second electronic device is configured to receive the identification information of the first electronic device through short-range wireless communication , wherein the short-range wireless communication is Wi-Fi, Bluetooth, or ZigBee ([0032] Mobile devices 102A-102B described herein can couple with each other and with wireless accessories to enable short range radio communication.).
Regarding claim 6, Movva teaches: wherein the server comprises access permission information of the first application, the access permission information indicates a model of an electronic device that the first application is allowed to access, and the server is configured to determine the authentication result based on the authentication request information and the access permission information ([0045] The mobile device OS 320 can then confirm the completeness of the list of details to use to complete the pairing process (e.g., Model Info/Product Name, Color, Image URL/Default Image, RoleId mapping)).
Regarding claim 9, Movva teaches: A method performed by a second electronic device (mobile device 230) that comprises a first application (locator app 310, OS 320), the method comprising: receiving identification information of the first electronic device from the first electronic device ([0037] Mobile device 230 can initiate pairing (205), causing accessory 220 to generate pairing data (207) and send the pairing data (209). [0033] During the pairing process with the electronic device, a payload including the secure token can be encrypted using the public key of the server and transmitted to the server to for validation, along with identifying information for the accessory. If the correct keys and secure token are used and the accessory is determined to be a valid and legitimate accessory, the registration server will indicate that the pairing request is valid and allow the pairing to continue.); and sending authentication request information of the first application to the server, wherein the authentication request information comprises the identification information of the first electronic device and application information of the first application ([0063] The first electronic device can then generate a parting request including pairing data having a first portion associated with the first electronic device and a second portion associated with the second electronic device (606).); receiving the authentication result (Step 221); and determining, based on the authentication result, whether the first application accesses the first electronic device (Step 225).
Movva teaches sending a certificate in an authentication request ([0048] the generated payload=(SessionNonce, C1, Software Token, UUID, Serial Number, productId, vendorId, fw_version, E1, SeedK1). The accessory 220 can then generate (423) encrypted pairing data E2, where E2=Encrypt pairing data (Payload). Encrypted pairing data E2 is an encrypted pairing blob that is encrypted for transmission to the pairing lock server 240, where the pairing boob [sic] will be decoded by the pairing lock server 240 and verified. The accessory 220 can then send (424) the encrypted pairing blob (E2) and “Pair” opcode to the wireless logic 330. The wireless logic 330 can then send the (425) encrypted blob received from the accessory 220 to the mobile device OS 320.); and verifying the certificate in the authentication request ([0048] where the pairing boob [sic] will be decoded by the pairing lock server 240 and verified.).
Movva, however, does not explicitly teach: send authentication request information of the first application to the server, wherein the authentication request information comprises a certificate of the first application.
However, in the same field of endeavor, Peddada teaches: send authentication request information of the first application to the server, wherein the authentication request information comprises a certificate of the first application ([0049] client digital certificate chain associated with the tenant).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify Movva to include the feature of an application signature and a combination of Movva with Peddada renders the claim prima facie obvious within the described scope of the prior art and any indicated differences within the level of one of ordinary skill in the art (e.g., telecommunications engineer) according to a combination of known prior art elements with known methods to yield predictable results. MPEP 2143(I)(A) (e.g., providing a certificate associated with the application or tenant).
Regarding claim 10, Movva teaches: wherein the receiving identification information of the first electronic device comprises: when the first application requests to access the first electronic device, receiving the identification information of the first electronic device from the first electronic device ([0037] Mobile device 230 can initiate pairing (205), causing accessory 220 to generate pairing data (207) and send the pairing data (209).).
Regarding claim 11, Movva teaches: wherein the sending the authentication request information of the first application to the server comprises: when the first application requests to access the first electronic device, obtaining the identification information that is of the first electronic device and that is on the second electronic device and sending the authentication request information of the first application to the server ([0037] Mobile device 230 can then generate (211) a pairing request to send to pairing lock server 240, then send (213) the pairing request to pairing lock server 240.).
Regarding claim 12, Movva teaches: wherein the authentication request information further comprises identification information of the second electronic device ([0063] The first electronic device can then generate a parting request including pairing data having a first portion associated with the first electronic device and a second portion associated with the second electronic device (606).).
Regarding claim 13, Movva teaches: wherein the receiving the identification information of the first electronic device comprises: obtaining the identification information of the first electronic device through short-range wireless communication ([0032] Mobile devices 102A-102B described herein can couple with each other and with wireless accessories to enable short range radio communication.).
Regarding claim 15, Movva teaches: A method performed by a server (pairing lock server 240), the method comprising: receiving authentication request information (Step 213) of a first application (locator app 310, OS 320) from a second electronic device (mobile device 230), wherein the first application (locator app 310, OS 320) is installed on the second electronic device (mobile device 230), the first application requests to access a first electronic device ([0043] As shown in FIG. 4A, the operations can begin in response to an app launch action at locator app 310 to add a new item (401)), the authentication request information comprises identification information of the first electronic device ([0037] Mobile device 230 can initiate pairing (205), causing accessory 220 to generate pairing data (207) and send the pairing data (209). [0033] During the pairing process with the electronic device, a payload including the secure token can be encrypted using the public key of the server and transmitted to the server to for validation, along with identifying information for the accessory. If the correct keys and secure token are used and the accessory is determined to be a valid and legitimate accessory, the registration server will indicate that the pairing request is valid and allow the pairing to continue.) and application information of the first application ([0063] The first electronic device can then generate a parting request including pairing data having a first portion associated with the first electronic device and a second portion associated with the second electronic device (606).), and the identification information of the first electronic device indicates a model of the first electronic device ([0045] The mobile device OS 320 can then confirm the completeness of the list of details to use to complete the pairing process (e.g., Model Info/Product Name, Color, Image URL/Default Image, RoleId mapping).); determining an authentication result based on the authentication request information (Step 217); and sending the authentication result to the second electronic device (Step 221).
Movva teaches sending a certificate in an authentication request ([0048] the generated payload=(SessionNonce, C1, Software Token, UUID, Serial Number, productId, vendorId, fw_version, E1, SeedK1). The accessory 220 can then generate (423) encrypted pairing data E2, where E2=Encrypt pairing data (Payload). Encrypted pairing data E2 is an encrypted pairing blob that is encrypted for transmission to the pairing lock server 240, where the pairing boob [sic] will be decoded by the pairing lock server 240 and verified. The accessory 220 can then send (424) the encrypted pairing blob (E2) and “Pair” opcode to the wireless logic 330. The wireless logic 330 can then send the (425) encrypted blob received from the accessory 220 to the mobile device OS 320.); and verifying the certificate in the authentication request ([0048] where the pairing boob [sic] will be decoded by the pairing lock server 240 and verified.).
Movva, however, does not explicitly teach: send authentication request information of the first application to the server, wherein the authentication request information comprises a certificate of the first application; the server is configured to: verify whether the certificate of the first application is correct; after verifying the certificate of the first application, determine an authentication result.
However, in the same field of endeavor, Peddada teaches: send authentication request information of the first application to the server, wherein the authentication request information comprises a certificate of the first application ([0049] client digital certificate chain associated with he tenant); the server is configured to: verify whether the certificate of the first application is correct; after verifying the certificate of the first application, determine an authentication result ([0050] validating the digital certificate chain of the client.).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify Movva to include the feature of an application signature and a combination of Movva with Peddada renders the claim prima facie obvious within the described scope of the prior art and any indicated differences within the level of one of ordinary skill in the art (e.g., telecommunications engineer) according to a combination of known prior art elements with known methods to yield predictable results. MPEP 2143(I)(A) (e.g., providing a certificate associated with the application or tenant).
Regarding claim 16, Movva teaches: wherein the authentication request information further comprises identification information of the second electronic device ([0063] The first electronic device can then generate a parting request including pairing data having a first portion associated with the first electronic device and a second portion associated with the second electronic device (606).).
Regarding claim 17, Movva teaches: wherein the server comprises access permission information of the first application, the access permission information indicates a model of an electronic device that the first application is allowed to access ([0045] The mobile device OS 320 can then confirm the completeness of the list of details to use to complete the pairing process (e.g., Model Info/Product Name, Color, Image URL/Default Image, RoleId mapping).), and the determining the authentication result based on the authentication request information comprises: determining the authentication result based on the authentication request information and the access permission information (Step 217).
Regarding claim 19, Movva teaches: wherein the determining the authentication result based on the authentication request information and the access permission information comprises: determining the model of the first electronic device based on the identification information of the first electronic device ([0045] The mobile device OS 320 can then confirm the completeness of the list of details to use to complete the pairing process (e.g., Model Info/Product Name, Color, Image URL/Default Image, RoleId mapping).); and determining the authentication result based on the model of the first electronic device and the application information and the access permission information of the first application (Step 217).
Regarding claim 21, Movva teaches: wherein the authentication request information further comprises operating system information of the second electronic device ([0046] In one embodiment, mobile device OS 320 can add the owner device attestation public key into E1 to bind session to the specific mobile device that has initiated the pairing.).
Regarding claim 22, Movva teaches: wherein the authentication request information further comprises operating system information of the second electronic device ([0046] In one embodiment, mobile device OS 320 can add the owner device attestation public key into E1 to bind session to the specific mobile device that has initiated the pairing.).
Claims 7, 18, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Movva in view of Peddada and further in view of U.S. Publication No. 2018/0288208 (hereinafter “Lee”).
Regarding claim 7, Movva teaches authentication based on the model number of the first electronic device ([0045]), but the combination of Movva and Peddada does not teach authentication based on the model number of the second electronic device.
However, in the same field of endeavor, Lee teaches: wherein the server comprises access permission information of the first application, the access permission information indicates a model of an electronic device that the first application is allowed to access ([0384] e.g., For example, the processor 610 may transmit the accessory ID of the first accessory device 2310-1) and a model of the second electronic device on which the first application is installed ([0384] For example, the processor 610 may transmit the accessory ID of the second accessory device 2310-2), and the server is configured to determine the authentication result based on the authentication request information and the access permission information ([0384-385]).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of Movva and Peddada to include the feature of authenticating model information for two devices and a combination of Movva and Peddada with Lee renders the claim prima facie obvious within the described scope of the prior art and any indicated differences within the level of one of ordinary skill in the art (e.g., telecommunications engineer) according to a combination of known prior art elements with known methods to yield predictable results. MPEP 2143(I)(A) (e.g., authenticating model information for two devices).
Regarding claim 18, Movva teaches authentication based on the model number of the first electronic device ([0045]), but the combination of Movva and Peddada does not teach authentication based on the model number of the second electronic device.
However, in the same field of endeavor, Lee teaches: wherein the server comprises access permission information of the first application, the access permission information indicates a model of an electronic device that the first application is allowed to access ([0384] e.g., For example, the processor 610 may transmit the accessory ID of the first accessory device 2310-1) and a model of the second device on which the first application is installed ([0384] For example, the processor 610 may transmit the accessory ID of the second accessory device 2310-2), and the server is configured to determine the authentication result based on the authentication request information and the access permission information ([0384-385]).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of Movva and Peddada to include the feature of authenticating model information for two devices and a combination of Movva and Peddada with Lee renders the claim prima facie obvious within the described scope of the prior art and any indicated differences within the level of one of ordinary skill in the art (e.g., telecommunications engineer) according to a combination of known prior art elements with known methods to yield predictable results. MPEP 2143(I)(A) (e.g., authenticating model information for two devices).
Regarding claim 20, Movva teaches: wherein the determining the authentication result based on the authentication request information and the access permission information comprises: determining the model of the first electronic device based on the identification information of the first electronic device ([0045] The mobile device OS 320 can then confirm the completeness of the list of details to use to complete the pairing process (e.g., Model Info/Product Name, Color, Image URL/Default Image, RoleId mapping).); and determining the authentication result based on the model of the first electronic device and the application information and the access permission information of the first application (Step 217).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
U.S. Publication No. 2018/0225900 (Wishne) related to electronic access control
U.S. Patent No. 10,805,799 (Bilger) related to a system and method for providing authenticated identity of mobile phones
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
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
