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 .
Claims 1-18 and 42-43 are pending.
Claims 1, 8, 11 and 16 are amended.
Claim 43 is added.
No claims are cancelled. Claims 19-41 were previously cancelled.
Response to Arguments
Applicant’s arguments with respect to Section 103 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Information Disclosure Statement
The information disclosure statement filed June 11, 2026 fails to comply with 37 CFR 1.98(a)(2), which requires a legible copy of each cited foreign patent document; each non-patent literature publication or that portion which caused it to be listed; and all other information or that portion which caused it to be listed. The copy of JP2016511847A, other than the English abstract provided, is a wholly illegible random collection of reference numbers and acronyms. Other documents are missing. It has been placed in the application file, but the stricken information referred to therein has not been considered.
Claim Rejections - 35 USC § 103
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 1-7, 9, 11-15, 17, and 42 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Application Publication No. 20170050617 to Penilla et al. in view of U.S. Patent Application Publication No. 20180075677 to Campero et al. and U.S. Patent Application Publication No. 20160049033 to Sigal et al.
With regards to claims 1 and 11, Penilla et al. teaches
a smart device configured to generate an encrypted code (paragraph [0019], “In some implementations, the device is one of a smartphone, or a smartwatch, or smart glasses, or a portable device, or a computer, or a digital assistant, or a key fob.”);
a key fob configured to receive the encrypted code from the smart device and to transmit the encrypted code to a computing device incorporated into property via wireless communication (paragraph [0048], “The method further includes encrypting the access code and at least part of the metadata to generate encrypted e-keys and sending the encrypted e-keys to a device of the recipient. The encrypted e-keys are configured for wireless transfer to the vehicle from the device of the recipient. The wireless transfer includes transfer of a device ID of the device of the recipient, and the encrypted e-keys are configured to be decrypted by the vehicle and the access code is associated with the device ID on the vehicle.”; paragraph [0285], “In some embodiments, the e-keys when active will provide a graphical user interface on the device of the recipient, which may allow access, such as icon buttons to unlock, lock, start and stop the vehicle. The app can also send notifications to the recipient, if for example, the user wishes to provide the recipient with more time or less time. While the e-keys are active, in one embodiment, the vehicle can report back activity of the vehicle, while under the care/use of the recipient.”); and
a server configured to update an access log of the key fob … (paragraph [0049], “In some embodiments, the server receives data during the use of the e-keys, the data including at least use metrics of the vehicle, the use metrics being stored by the server as history of use for the e-keys.”; paragraph [0050], “In some embodiments, the server, upon receiving a request to cancel the e-keys, sends deactivation instructions to one or both of the devices of the recipient and the vehicle.”), wherein the computing device includes a validation module configured to validate the received encrypted code (paragraph [0080], “For example, the user-owner of the vehicle can assign a valet with access to the vehicle by going on an application (App or website) on a computing device (e.g., mobile or non-mobile device), identifying the recipient, identifying a mode for communicating with the recipient (e.g., text, email, message, notification, etc.), selecting the account privileges (e.g., what type of access, speed limits, geographic restrictions, amount of time the e-keys will be valid (or else expire)), and requesting that e-keys be sent to the recipient.”), wherein the computing device grants a user of the key fob access to the property when the validation module validates the encrypted code (paragraph [0039], “The method then encrypts the access code, at the server, using a vehicle public key associated with the vehicle; the vehicle public key is associated with the user account. The method includes sending the encrypted access code to the recipient for receipt by a device of the recipient. The encrypted access code is defined for transmission to the vehicle by way of the device of the recipient, and the encrypted access code is associated with instructions to cause the vehicle to decrypt the access code using a private key of the vehicle and to transmit the access code after decryption back to the device of the recipient along with privilege settings for the use of the vehicle.”),
wherein the computing device transmits the access log, which includes information regarding whether the key fob is granted or denied access to the property, as the access log, to the smart device via the wireless communication (paragraph [0150], “In operation 378, a report sent back to the server regarding the use of the vehicle and the charges to the users account for the use. In one embodiment, the use reporting can occur continuously while the user is driving vehicle. In operation 380, the driver's session log can be saved user profile, keeping a history of the user's travels.”; paragraph [0221], “In one embodiment, these methods/systems provide ways to share specific vehicle maintenance data with select entities. The reporting by the car can be saved to a log/database of events that are reported, and the adviser/dealer can reply to the notices to communicate instructions or recommendations.”; paragraph [0258], “Information regarding data reporting can be set, remote access privileges can be set, local access can be set for using the vehicle (such as starting the vehicle opening the vehicle, locking the vehicle, unlocking the vehicle, restricting speeds, restricting distances, etc.). In operation 636, the advisor account is generated.”), and the smart device relays the access log to the server (paragraph [0186], “FIG. 15 describes further example ways an APP 104 may take, process and produce results 2100. FIG. 14 shows a way to interact with an APP 104 locally but a vehicle computer system may relay data, inputs and information to the APP while connected to a wide area network, local area network, cloud process 120 or private cloud. A remote action to invoke change on an APP 1808 may be initiated via a network and pass to the APP running on the vehicle 160 using the vehicle's antenna 1928 or wired interface. An APP 104 running virtually on a network or cloud services 120 may also take input remotely and process the results accordingly.”), wherein the smart device relays the access log to the server when a network connection is established between the smart device and the server (paragraph [0186], “FIG. 15 describes further example ways an APP 104 may take, process and produce results 2100. FIG. 14 shows a way to interact with an APP 104 locally but a vehicle computer system may relay data, inputs and information to the APP while connected to a wide area network, local area network, cloud process 120 or private cloud. A remote action to invoke change on an APP 1808 may be initiated via a network and pass to the APP running on the vehicle 160 using the vehicle's antenna 1928 or wired interface. An APP 104 running virtually on a network or cloud services 120 may also take input remotely and process the results accordingly.”),
…,
wherein, when the user of the key fob selects one of a plurality of buttons of the key fob (paragraph [0038], “In some embodiments, the e-keys when active will provide a graphical user interface on the device of the recipient, which may allow access, such as icon buttons to unlock, lock, start and stop the vehicle. The app can also send notifications to the recipient; if for example, the user wishes to provide the recipient with more time or less time. While the e-keys are active, in one embodiment, the vehicle can report back activity of the vehicle, while under the care/use of the recipient.”),
the key fob generates, based on the selected button (paragraph [0084], “The use metrics can include use of APPS, use be of system components of the vehicle, use of the vehicle, environment conditions, and historical actions taken by the user via the input/output controls of the vehicle (e.g., buttons, levers, keys, fobs, display selections, display interface actions, communication actions, etc.).”), an encrypted code corresponding to a requested operation of the property, wherein the key fob transmits the encrypted code corresponding to the requested operation to the computing device (paragraph [0039], “The method further includes generating a unique access code, at the server, in response to receiving the request. The method then encrypts the access code, at the server, using a vehicle public key associated with the vehicle; the vehicle public key is associated with the user account. The method includes sending the encrypted access code to the recipient for receipt by a device of the recipient. The encrypted access code is defined for transmission to the vehicle by way of the device of the recipient, and the encrypted access code is associated with instructions to cause the vehicle to decrypt the access code using a private key of the vehicle and to transmit the access code after decryption back to the device of the recipient along with privilege settings for the use of the vehicle.”),
wherein the validation module validates the encrypted code before authorizing performance of the requested operation, wherein the validation module decrypts the encrypted code with a private key saved in the validation module and validates the encrypted code independently of any network connection between the computing device and the server (paragraph [0271], “At the vehicle, the vehicle will receive the encrypted e-keys and the device ID of Bob's device 704. The vehicle will hold a private key to unlock and un-encrypt the encrypted e-keys 720.”; paragraph [0272], “The encryption by the server of the-keys utilize a public key that is associated with John's car, and held in or associated with an account managed for John. In this manner, John's car, holding the private key in memory can decrypt the encrypted e-keys 720. At the vehicle, the decrypted e-keys will be bound, associated, or paired with the device ID that transferred the e-keys in operation 730.”; paragraph [0273], “The target device that receives the e-keys is the recipient device that is identified by the user that requested that the e-keys be provided to the recipient. In operation 732, as mentioned above, the vehicle private key is used to decrypt the e-keys to get access to an access code. The access code is the code that will enable the e-keys to be activated e-keys 724.”), …
However, Penilla et al does not expressly disclose any use of blockchain but Campero et al. discloses a server configured to update an access log of the key fob in a blockchain (paragraph [0022], “One such approach discussed in detail in below uses access badges 12 a, 12 b, each with embedded credentials 13 a, 13 b in conjunction with a distributed ledger 14 back-end that replaces the typical centralized database (not shown). The access badges 12 a, 12 b are used with access card readers 15, in which a user will swipe or otherwise allow the card readers to read the credential on the user's badge.”; see also paragraphs [0024]-[0031] including teaching blockchain as known type of distributed ledger), …
wherein the computing device transmits the access log (paragraph [0040], “With either result (allowing access or denying access) the card reader sends a corresponding transaction message to the distributed ledger 14 that logs the result in the distributed ledger 14. Also, various other access control decisions can be made based on the result.”), which includes information regarding whether the key fob is granted or denied access to the property (paragraph [0040], “With either result (allowing access or denying access) the card reader sends a corresponding transaction message to the distributed ledger 14 that logs the result in the distributed ledger 14.”), to the smart device via the wireless communication, and the smart device relays the access log to the server, (paragraph [0038], “In either case, the card reader 150 generates from the data received from the distributed ledger 14, a result. The reader generates a message according to the result. Thus, if the result is to allow access, the reader generated message is a control message that grants 176 a access, e.g., unlocks an electronic lock on a door, etc., e.g., the door lock of FIG. 9.”; paragraph [0039], “If the result is to deny access 176 b then another action can occur such as a retry action that is communicated to the user or an action that is not discernible to the user, but which denies access.”)
…
wherein the server generates a block to save the access log therein and adds the block to the blockchain (paragraph [0024], “The distributed ledger system 14 interacts with a security system, e.g., a third party system 18 to allow access to users to otherwise locked facilities. While sharing some similarities to the Blockchain as well as other known types of sequential transaction databases, the distributed ledger 14 has some significant differences.”; paragraph [0040], “With either result (allowing access or denying access) the card reader sends a corresponding transaction message to the distributed ledger 14 that logs the result in the distributed ledger 14. Also, various other access control decisions can be made based on the result.”; it is noted that adding a block is a way to save something to a blockchain and blockchain is taught to be a known type of distributed ledger),
…. wherein the access log includes information identifying the requested operation (paragraph [0040], “With either result (allowing access or denying access) the card reader sends a corresponding transaction message to the distributed ledger 14 that logs the result in the distributed ledger 14. Also, various other access control decisions can be made based on the result.”)
wherein when the code is not valid, the selected function is not performed by the property (paragraph [0038], “In either case, the card reader 150 generates from the data received from the distributed ledger 14, a result. The reader generates a message according to the result. Thus, if the result is to allow access, the reader generated message is a control message that grants 176 a access, e.g., unlocks an electronic lock on a door, etc., e.g., the door lock of FIG. 9.”; paragraph [0039], “If the result is to deny access 176 b then another action can occur such as a retry action that is communicated to the user or an action that is not discernible to the user, but which denies access.”).
It would have been obvious to one of ordinary skill in the art at to create the invention as claimed for the following reasons. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Penilla et al by certifying a record, for the purpose of keeping track of changes or updates, based upon the enhanced user experience, security, compliance as discussed in Campero et al. (see for example paragraph [0022]). These modifications would result in ease of use and increased security, both of which are obvious benefits to the skilled artisan. Additionally, the cited references are in the field of computer security, as is the current application, and thus, are in analogous arts.
However, Penilla et al. does not expressly disclose but Sigal et al. discloses
wherein the computing device transmits the access log, which includes information regarding whether the key fob is granted or denied access to the property (paragraph [0061], “If the key fob is not placed at the base station a deny request message is sent to the nomadic device in operation 316.”), as the access log, to the smart device via the wireless communication (paragraph [], “”), and the smart device relays the access log to the server (paragraph [], “”), wherein the smart device relays the access log to the server when a network connection is established between the smart device and the server (paragraph [0016], “This invention disclosure proposes a key fob base station at a physical location such as the user's home. The base station may receive a key fob and wirelessly communicate the key fob security codes to a nomadic device via a computer network (e.g., server). The key fob base station may transmit the information and data to mimic the key fob (RF frequency, key, etc.) to the server.”; paragraph [0030], “Further, the CPU could be in communication with a variety of other auxiliary devices 65. These devices can be connected through a wireless 67 or wired 69 connection. Auxiliary device 65 may include, but are not limited to, personal media players, wireless health devices, portable computers, and the like.”),
wherein, when the user of the key fob selects one of a plurality of buttons of the key fob, the key fob generates, based on the selected button, an encrypted code corresponding to a requested operation of the property (paragraph [0044], “For example, if the nomadic device 53 is assigned as a primary user, the encrypted data transmitted to the nomadic device 53 may enable all functions and features of the VCS 1. If the nomadic device 53 is assigned as a secondary user at the key fob base station 212, the nomadic device 53 may have restrictions on features and functions of the VCS 1. For example, if the nomadic device 53 is sent encrypted data identifying the device as a secondary user, the VCS 1 may limit speed of the vehicle 31, limit volume control of the radio, and/or limit use of cellular phone activity while the vehicle 31 is moving.”; paragraph [0048], “The nomadic device 53 may communicate with the VCS 1 using the ignition key application 101 allowing the VCS 1 to recognize a keyless entry operation. The VCS 1 may determine based on the encrypted data received from the nomadic device 53 if the one or more operations are approved to be executed at the one or more vehicle systems.”; paragraph [0049], “Prior to starting the vehicle, the nomadic device may transmit the key fob serial number and the encrypted data to the VCS 1, which are then compared to known key fob numbers and/or encrypted data in a PEPS look up table in a manner similar to that described above.”; paragraph [0055], “In another example, the nomadic device 53 may request to start the vehicle 31 via a keyless push button ignition switch 19. The VCS 1 may require additional security data from the key fob 202 via the nomadic device 53 before enabling the start request. The nomadic device 53 may select a start request at the ignition key application 101.”),
wherein the key fob transmits the encrypted code corresponding to the requested operation to the computing device (paragraph [0034], “For example, the key fob base station system 200 may transmit key fob functions to a preregistered nomadic device 53 including, but not limited to, unlocking the door, a trunk opening request, an enabling an alarm, and starting the vehicle.”; paragraph [0036], “The key fob 202 or nomadic device 53 each include an ignition key device and/or application 101 embedded within for communicating with the PEPS controller 223. In one example, the transponder of the key fob 202 and/or nomadic device 53 may be adapted to send the key number and encrypted data on a signal KEY_ID as an RF signal to the PEPS controller 223.”),
wherein the validation module validates the encrypted code before authorizing performance of the requested operation (paragraph [0041], “For example, the signal KEY_ID generally comprises RF data that corresponds to a manufacturer code, a corresponding key fob serial number and encrypted data. The key fob serial number and the encrypted data are used to authorize the engine controller to start the vehicle in the event the encrypted data corresponds to predetermined encrypted data stored in a look up table (LUT) of the PATS controller 222. The PATS controller 222 may use the key fob identifier and/or the encrypted data transmitted on the signal KEY_ID to determine if the key fob is approved to communicate with the VCS 1.”), …, and
wherein, when the encrypted code is not valid, the requested operation is not performed by the property (paragraph [0042], “To start the vehicle, the PATS controller 222 decodes the key serial number, the manufacturing code, and corresponding encrypted data received on the signal KEY_ID and compares such data to the key serial number and the encrypted data in the LUT to determine whether such data match prior to starting the vehicle for anti-theft purposes.”, paragraph [0075], “If the VCS detects an error during the security handshake process, the VCS may transmit an error message to the nomadic device in operation 516. The error message may include an unauthorized access message notifying the user at the nomadic device of their denied access to the vehicle. In other examples, the error messages may be customized to include personal message for an identified user.”).
It would have been obvious to one of ordinary skill in the art at to create the invention as claimed for the following reasons. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Penilla et al by certifying a record, for the purpose of enabling communication with the new smart device and enable a key fob function if authentication is approved as discussed in Sigal et al. (see for example paragraph [0006]). These modifications would result in ease of use and increased security, both of which are obvious benefits to the skilled artisan. Additionally, the cited references are in the field of remote function authorization device, as is the current application, and thus, are in analogous arts.
With regards to claims 2 and 12, Penilla et al. further disclose wherein the wireless communication is Bluetooth communication (paragraph [0092], “Other types of communication can include radio frequency communication, such as 802.11.ac, 802.11ad and subsequent wireless networking protocols, Bluetooth communication or combinations of Wi-Fi and Bluetooth.
With regards to claims 3 and 13, Penilla et al. further disclose wherein the mobile device and the key fob are paired according to a Bluetooth protocol (paragraph [0226], “The communication by the guest to the vehicle can be performed using any number of wireless communications, such as radio communication, Wi-Fi communication, Bluetooth communication, etc. The device of the guest, who is the recipient of the electronic keys can be of any type of the device. Example devices can include smart phones, tablet computers, computer glasses, wristwatch computers, computer chips, thumb drive computers, or any other device having the capability of storing data, processing data, and exchanging data either wirelessly or via some wired connection.”).
With regards to claims 4 and 14, Penilla et al. further disclose wherein the computing device of the property and the key fob are paired according to a Bluetooth protocol (paragraph [0226], “The communication by the guest to the vehicle can be performed using any number of wireless communications, such as radio communication, Wi-Fi communication, Bluetooth communication, etc. The device of the guest, who is the recipient of the electronic keys can be of any type of the device. Example devices can include smart phones, tablet computers, computer glasses, wristwatch computers, computer chips, thumb drive computers, or any other device having the capability of storing data, processing data, and exchanging data either wirelessly or via some wired connection.”).
With regards to claims 5, Penilla et al. disclose wherein the validation module is constantly powered by the property (paragraph [0174], “FIG. 13A describes how vehicle on board computer with input out put system 1900 useful for accepting input, processing input and displaying results in conjunction with stored computer readable programs or functions in the forms of APPs 104 may be structured. Although system 1900 describes one way to provide vehicle on board computing power to run APPs 104, the arrangement of the vehicle computer 1906 may be altered or arranged in differing fashions with differing connection routing in order to achieve the same.”).
With regards to claims 6, Penilla et al. further disclose wherein the validation module is an electronic circuit (paragraph [0174], “FIG. 13A describes how vehicle on board computer with input out put system 1900 useful for accepting input, processing input and displaying results in conjunction with stored computer readable programs or functions in the forms of APPs 104 may be structured. Although system 1900 describes one way to provide vehicle on board computing power to run APPs 104, the arrangement of the vehicle computer 1906 may be altered or arranged in differing fashions with differing connection routing in order to achieve the same.”).
With regards to claims 7 and 15, Penilla et al. further disclose the code is encrypted with a public key by the mobile device (paragraph [0039], “The method then encrypts the access code, at the server, using a vehicle public key associated with the vehicle; the vehicle public key is associated with the user account. The method includes sending the encrypted access code to the recipient for receipt by a device of the recipient. The encrypted access code is defined for transmission to the vehicle by way of the device of the recipient, and the encrypted access code is associated with instructions to cause the vehicle to decrypt the access code using a private key of the vehicle and to transmit the access code after decryption back to the device of the recipient along with privilege settings for the use of the vehicle.”; paragraph [0278], “The unique access code can be generated by a number generator, and alphanumeric random generator, in incremental number generator, or any other generation device that can generate codes that are unique or substantially unique. In operation 744, the access code is encrypted using the vehicles public key, which is held by the server. The public key held by the server enables encryption of the access code and any associated metadata, privileges, or communication data or codes, which will be sent to the recipient device for accessing of the vehicle. In operation 745, the encrypted e-keys are sent to the recipient. In this example, the encrypted e-keys 720 are sent to Bob and received by device 704.”)
With regards to claims 9 and 17, Penilla et al. further does not expressly disclose but Campero et al. further disclose wherein the validation module transmits the access log to the server when a network connection is established with the server (paragraph [0027], “The distributed databases are controlled by a distributed database management system that controls storage of data over a network 38 of the interconnected computers and execute corresponding replication and duplication processes.”; paragraph [0031], “As shown in FIG. 3, the broker system 16 can be a compilation of many such broker systems 16 a-16 n. Each of the broker systems 16 a-16 n can comprise computer systems and associated distributed databases. The broker systems 16 a-16 n are distributed over a network of servers that act together to manage the distributed ledger 14.”).
It would have been obvious to one of ordinary skill in the art at to create the invention as claimed for the following reasons. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Penilla et al by certifying a record, for the purpose of keeping track of changes or updates, based upon the enhanced user experience, security, compliance as discussed in Campero et al. (see for example paragraph [0022]). These modifications would result in ease of use and increased security, both of which are obvious benefits to the skilled artisan. Additionally, the cited references are in the field of computer security, as is the current application, and thus, are in analogous arts.
With regards to claim 42, Penilla et al. teaches:
the wireless communication is near field communication (paragraph [0209], “In some embodiments, the vehicles may establish peer-to-peer links to facilitate fast transfer of data. In other embodiments, vehicles may link to each other using pairing algorithms that allow the vehicles to exchange data using WiFi, Bluetooth, near field communication (NFC), or some other short range communication protocol.”),
wherein the smart device generates the encrypted code, which works as an authorized key to an entry of the property (paragraph [0039], “The method then encrypts the access code, at the server, using a vehicle public key associated with the vehicle; the vehicle public key is associated with the user account. The method includes sending the encrypted access code to the recipient for receipt by a device of the recipient. The encrypted access code is defined for transmission to the vehicle by way of the device of the recipient, and the encrypted access code is associated with instructions to cause the vehicle to decrypt the access code using a private key of the vehicle and to transmit the access code after decryption back to the device of the recipient along with privilege settings for the use of the vehicle.”; paragraph [0278], “The unique access code can be generated by a number generator, and alphanumeric random generator, in incremental number generator, or any other generation device that can generate codes that are unique or substantially unique. In operation 744, the access code is encrypted using the vehicles public key, which is held by the server. The public key held by the server enables encryption of the access code and any associated metadata, privileges, or communication data or codes, which will be sent to the recipient device for accessing of the vehicle. In operation 745, the encrypted e-keys are sent to the recipient. In this example, the encrypted e-keys 720 are sent to Bob and received by device 704.”); and
wherein the key fob is paired with the property so that the key fob communicates with the property via Bluetooth communication and no Internet connection is necessary in the communication between the property and the key fob (paragraph [0211], “In one embodiment, the vehicles can communicate directly with each other via a temporary pairing process. The temporary pairing process can be automatically enabled when vehicles become too close to each other, for example. When this happens, local communication between the vehicles, such as a peer-to-peer connection, Wi-Fi connection, NFC connection, or Bluetooth connection can be established to enable the vehicles to share information concerning their proximity to one another.”).
Claims 10 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Application Publication No. 20170050617 to Penilla et al. and U.S. Patent Application Publication No. 20180075677 to Campero et al. and U.S. Patent Application Publication No. 20160049033 to Sigal et al. further in view of U.S. Patent Application Publication No. 2017/0257358 to Ebrahimi et al.
With regards to claims 10 and 18, Penilla et al. further does not expressly disclose but Ebrahimi et al further disclose the property is an aircraft, watercraft, hovering vehicle, land vehicle, or building (paragraph [0089], “The user typically wishes to gain access to particular service or product, as is described throughout this specification. The term “service provider” refers to an entity to which a user wishes to gain access. For example, the service provider may be a website, a physical building, an employer, a club with membership privileges, an automobile, an airline, or any other service or product.”).
It would have been obvious to one of ordinary skill in the art at to create the invention as claimed for the following reasons. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Penilla et al by certifying a record, for the purpose of keeping track of changes or updates, based upon the beneficial teachings provided by Ebrahimi et al, see for example [0089]. These modifications would result in ease of use and increased security, both of which are obvious benefits to the skilled artisan. Additionally, the cited references are in the field of computer security, as is the current application, and thus, are in analogous arts.
Subject Matter Free of Prior Art
Claims 8, 16, and 43 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims. As noted above, Penilla et al. teaches providing codes to access property based on encrypted data, but fails to explicitly teach the key fob combines the encrypted code received from the smart device, without decrypting the encrypted code, with a function corresponding to the selected button to generate the encrypted code corresponding to the requested operation, and wherein the validation module decrypts only the encrypted code with the private key, which corresponds to the public key, and validates the decrypted code, as recited in claims 8 and 16, or to explicitly teach the key fob decrypts the encrypted code received from the smart device, combines the decrypted code with a function corresponding to the selected button, and encrypts the combined decrypted code and function to generate the encrypted code corresponding to the requested operation, and wherein the validation module decrypts the encrypted code, separates the code and the function, and validates the separated code, as recited in claim 43.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
U.S. Patent Application Publication No. 20180077124 to Ramoutar discusses a method for secure wireless communication between a secure wireless device and a mobile device using NFC. The devices have a common seed value, which may be provided to the secure wireless device by the mobile device when they are is physical contact. During contact the mobile device sends a pairing request and credentials to the secure device. After the credentials are validated, the devices are paired and can exchange encrypted messages via a suitable wireless interface such as Bluetooth, the messages being encrypted initially based on the common seed value and the encryption key being regenerated by each device after message transmission by the secure device and reception by the mobile device. The secure device stores confidential data, which can be sent in encrypted messages to the mobile device.
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 Joshua D Schneider whose telephone number is (571)270-7120. The examiner can normally be reached on Monday - Friday, 9am-5pm.
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, Jessica Lemieux can be reached on (571)272-6782. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/J.D.S./Examiner, Art Unit 3626
/JESSICA LEMIEUX/Supervisory Patent Examiner, Art Unit 3626
