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 .
The following is a Final Office Action is response to communications received on August 18, 2025. Claims 1 – 24 are amended and pending in rejected status.
Claim Objections
Claim 17 is objected to for reciting limitation “can” that appears to have no positive recitation. Claims 4, 9, 12, 17, and 20 has similar issue.
Response to Amendment
The 101 rejection to claims 9-24 is withdrawn in view of the applicant’s amendment.
Applicant’s arguments regarding the newly amended limitations to the independent clams are moot in view of the new ground of rejection.
Applicant argues:
“ …the combinations fail to teach or suggest generating a temporary session key for the purpose of temporarily sharing a first video captured from a first network-connected IoT camera of the plurality of network-connected IoT cameras with a third party data processing device or an IoT service.” “…While some of the cited references, such as Ivanchykin, generally describe the use of a symmetric key with a time-based nonce for encrypting video, these references fail to teach or suggest details related to the context of the video sharing as recited in the present claims…”
Argument is not persuasive because Ivnchykin teaches restricted sharing of media content using a symmetric key and a time restriction mechanism tied to reply protection and limited duration access. Ivanchykin teaches generation and use of a symmetric key associated with a user and/or content combination, transmission of encrypted media content and an associated encryption envelope, and time limited playback such that access is only available during a specified duration, teaching use of a temporary session key for temporarily sharing video content. Newly added prior art Dell further teaches the use of time based session key generation for encrypted IoT communications, in which a time based input is used on both the sending and receiving sides to generate a matching session key for encryption and decryption within a limited time window, additional teaching of a temporary, time limited session key. Newly added prior art Bart provides the IoT context, including IoT devices, and IoT service, mobile app access and secure device and service communication. Thus, the combination of Ivanchykin, Dell, and Bart taches IoT camera/device associated with a user account, video capture and encrypted storage, secure share/playback of encrypted video using a temporary time limited crypto key.
Applicant argues:
“…While some of the cited references, such as Ivanchykin, generally describe the use of a symmetric key with a time-based nonce for encrypting video, these references fail to teach or suggest details related to the context of the video sharing as recited in the present claims…”
Argument is not persuasive because the cited references do not rely only on generic encryption; they disclose time restricted access and session based encryption/decryption, which is the same functional purpose as the claimed temporary session key. The fact that applicant’s claim applies this mechanism to a first video captured from an IoT camera does not render the claimed use patentably distinct, because the references collectively teach the same crypto and access control principles in the context of media delivery and IoT communication.
Drawings
For the record, Examiner acknowledges that the Drawings submitted on December 16, 2022 have been accepted
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1 - 2, 4-5, 7, 9 - 10, 12-13, 15, 17 - 18, 20-21, and 23 are rejected under 35 U.S.C. 103 as being unpatentable over Ivanchykin et al. CA 2865548 A in view of US 20190013945 A1 (herein after Dell) and further in view of US 20200336895 A1 (herein after Bart).
As to claim 1, Ivanchykin et al. discloses a method comprising:
associating a plurality of network-connected internet-of-things (IoT) [cameras] with a user account on an IoT service, each network-connected IoT [camera to capture] and encrypt video with a unique(fig. 1 and its disclosure: user devices capable of taking pictures including smart phones or laptops interconnected in the network with distribution center 100; pars. 4-5, 85 fig. 8: encrypting the media content with the symmetric key; and … the association encryption envelope includes a symmetric key associated with a combination of the user identifier and the content identifier, … encrypted video stream or container could be handled by the crypto engine 121 … encrypted media content and symmetric keys associated with a user/content combination), [camera]-specific session key to generate [camera]- specific encrypted video (pars. 4a- 4b: receiving an association encryption envelope for the requested media content from the media distribution center …and forwarding the received association encryption envelope to the display device…. A user device receiving the association envelope and forwarding it to the display device; par. 0013: crypto engine decrypting encrypted media content data and displaying), each [camera]-specific session key to be shared with an IoT app installed on a mobile device of the user(pars. 4a- 4b: receiving an association encryption envelope for the requested media content from the media distribution center …and forwarding the received association encryption envelope to the display device…. A user device receiving the association envelope and forwarding it to the display device; see fig. 4 element 440: devices using shared symmetric key to decrypt and display);
persistently storing the [camera]-specific encrypted video on the IoT service(Fig. 5a-b, pars. 4c-d: A media content storage of the media distribution 100 is provided to store the media content. A crypt engine is coupled to the communication interface and the media content storage. The crypt engine is configured to: obtain a symmetric key associated with the user and media content; retrieve the requested media content from the media content storage; encrypt the media content retrieved from the media content storage using the symmetric key : storage of encrypted media/video content at a media distribution center/server);
streaming a [camera]-specific encrypted video from the IoT service or directly from a user- specified IoT [camera] responsive to user input on the mobile device(pars. 59-61, 4: encrypting the media content with the symmetric key; and transmitting the encrypted media content and the association encryption envelope to the user device… At step 575, the local device 110 may transmit at least a portion of the encrypted media content to the display device 120. As the display device 120 receives encrypted content, at step 580 its crypto engine 121 may decrypt the content using the user/content symmetric key previously obtained, transmits encrypted media/video content to the user device and subsequent display playback), the IoT app to securely access a corresponding [camera]-specific session key to decrypt and render the [camera]-specific encrypted video on the mobile deice (par 64: When the user attempts to play back the media content, the display device 120 may decrypt the association encryption envelope, extract the symmetric key, and decrypt, decode and play back the media content … pars. 19, 12-13: display device 120 wired/wireless);
generating a temporary session key to be used to share video content with a third-party data processing device or a service (Ivanchykin et al. teaches a temporary crypto-safe symmetric key to encrypt content (content consists of movies or video clips) and later transmit to a display device (i.e. third-party data processing device). [Sections [0014], [0060], [0057]]) generating a time-based nonce which is valid for a duration of time (Ivanchykin et al. teaches a device that generates a nonce that is attached to a time-limited association request. [Section [0041]]);
encrypting using temporary session key (Ivanchykin et al. teaches of encrypting content by a temporary crypto-safe symmetric key [Section [0087]]) and the time-based nonce (Ivanchykin et al. teaches a nonce saved in conjunction with a counter value (i.e. time-based nonce) [Section [0041]]);
transmitting the encrypted video content to the third-party data processing device or service (Ivanchykin et al. teaches a local device transmitting encrypted media content to a display device (third-party data processing device). [Section [0060]]);
wherein, within the duration of time, using a temporary session key (Ivanchykin et al. teaches of encrypting content by a temporary crypto-safe symmetric key [Section [0087]]) and a copy of the time-based nonce (Ivanchykin et al. teaches of a two nonce that are the same (copy of a nonce) associated with a time restriction (i.e. time-based nonce) [Claim 21 and 22]);
encrypting the video content using the session key [and the nonce] to generate encrypted video content which can only be decrypted using the session key [and the nonce] (Ivanchykin et al. teaches on pars. 4-5, 85 fig. 8: encrypting the media content with the symmetric key; and … the association encryption envelope includes a symmetric key associated with a combination of the user identifier and the content identifier, … encrypted video stream or container could be handled by the crypto engine 121 … encrypted media content and symmetric keys associated with a user/content combination));
wherein, the third-party data processing device or service are to decrypt the
encrypted video using [a combination of] the session key [and a time-based nonce] (see pars. 18, crypto engine 102 of the Media distribution: performing symmetric encryption and performing decryption of movie/video)).
Ivanchykin et al. does not explicitly disclose encrypting using session key and time-based nonce.
Dell teaches encrypting using session key and time-based nonce (see pars. 11 and 40-49: Dell discloses encrypting sensor data using session key derived from a time-based one time password, such that the same time-based input must be used by both sender and receiver to generate the matching session key for decryption. In Dell, “time information”/ “time based onetime password TOTP” is required in addition to the session key in order to encrypt or decrypt; par. 33 of Dell teaches IoT sensors 206 of fig. 2 being light-triggered camera, motion-triggered camera).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Dell’s time-based onetime password/session-key technique with Ivanchykin’s encryption, time-restricted media delivery system to enhance security by making decryption dependent on time sensitive cryptographic material, thereby reducing reply and unauthorized access risks while maintaining limited duration playback.
Ivanchykin et al. teaches user, device and content association for media playback devices including smartphones and laptops, see abstract and fig. 1 discussion of ‘receiving request for the media content from a user… a user identifier… a display device identifier… playback. Ivanchykin et al. further teaches time-limited playback. Dell teaches IoT sensors 206 of fig. 2 being light-triggered camera and/or motion-triggered camera. However, Ivanchykin et al and Dell fails to explicitly IoT cameras and IoT apps.
Bart teaches:
associating a plurality of network-connected internet-of-things (IoT) cameras with a user account on an IoT service (see figs 1A-B & par. 48: an IoT platform… included an IoT service… and connected devices; par. 261: IoT device such as video cameras may transmit a significantly greater amount of data … IoT devices are video cameras), each network-connected IoT camera to capture and encrypt video with a unique camera-specific session key (par. 153: “IoT device key” associated with each IoT devices) to generate camera- specific encrypted video (par. 111: each IoT device 101, 102 includes a secure key storage 1001, 1003, respectively, for security storing each device's private key. Security logic 1002, 1304 then utilizes the securely stored private keys to perform the encryption/decryption operations described herein; par. 112: … symmetric key exchange/encryption techniques may be used instead of public/private key encryption…; pars. 113-114: each IoT device 101 using symmetric key, entering into a secure key exchange protocol to exchange a symmetric key with the IoT hub 110; pars. 111-114: each IoT device using symmetric key to encrypt/decrypt data; par. 261: IoT devices being video cameras; see further pars. 148-150: encryption/decryption using shared key and/or session secret), each camera-specific session key to be shared with an IoT app installed on a mobile device of the user(par. 52 and 304: IoT app on user devices accessing information from IoT devices; pars. 139-150, 160-208: an IoT app on a user device, secure session key exchange between IoT service and IoT devices);
persistently storing the camera-specific encrypted video on the IoT service(par. 48, 318-321: IoT device data/video stored in server side database of IoT service; par. 261: IoT devices are video cameras; see fig. 11 IoT service and par. 112: encrypted content in 1021);
streaming a camera-specific encrypted video from the IoT service or directly from a user- specified IoT camera responsive to user input on the mobile device(pars. 112-119, 138-150, 222-230: encrypted data and communication between IoT service, hub and devices; par. 71: bi-directional stream of encrypted data; pars. 52, 83-85: user app for accessing IoT devices; par. 261: IoT devices are video cameras), the IoT app to securely access a corresponding camera-specific session key to decrypt and render the camera-specific encrypted video on the mobile deice(pars. 52, 304: IoT app on user device; pars. 139-150, 160-170, 222-230, 113-114: secure key exchange/session secrete/symmetric key; pars. 141, 143, 225: decryption of encrypted communications).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Bart’s IoT device/service/app architecture with Ivanchykin’s restricted media content delivery and Dell’s time-based session key technique to provide secure, time-limited encrypted media access in an IoT environment, thereby improving protection against unauthorized reuse, reply, and continued access while preserving the benefits of user specific device association and remote playback.
Independent claims 9 and 17 recite substantially similar subject matter to claim 1 and are therefore, rejected for similar reasons as applied to claim 1 above.
As to claim 2, Ivanchykin et al., Dell and Bart teach the method of claim 1 wherein the time-based nonce used for encrypting the first video is to be generated by a first nonce generator on a data processing device or camera from which the first encrypted video content is transmitted, and the time-based nonce used for decrypting the first encrypted video is to be generated by a [second nonce generator] on the third party data processing device or the IoT service. (Ivanchykin et al. teaches generating a first nonce by a display device (i.e. third-party data processing device) which is stored with a counter value and a second nonce generated by a media distribution outlet (i.e. service) [Claim 21 / Sections [0041], [0045], [0046]]; Par. 41 teaches generation of a nonce by the local/display device in connection with a time limited association request – the display device generates a nonce and stores it with the counter value… pars. 50, 57-61: Ivanchykin teaches the receiving/display device using the nonce contained in the association encryption envelope and compares it against the stored nounce to enforce time limited playback)
Ivanchykin et al. does not disclose a separate nonce generation.
However, Dell does disclose a second nonce generator (Dell pars. 11-12, 40-49: time sensitive crypto material used on both ends of the communication, where the same time based input must be used by sender and receiver to derive the session key.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine to implement nonce generation on both the transmitting and receiving sides to support synchronized, time based decryption and reply protection.
Dependent claims 10 and 18 recite substantially similar subject matter to claim 2 and are therefore, rejected for similar reasons as applied to claim 2 above.
As to claim 4, Ivanchykin et al., Dell and Bart discloses the method of claim 1 wherein,
when after the duration of time, the time-based nonce in combination with the temporary session key can no longer be used to decrypt the first encrypted video content. (Ivanchykin teaches of an expiration time for media content, if the time does expire, stored temporary symmetric key and a nonce with a counter value are removed to prevent user to access media content. [Sections [0037], [0039], [0040],57-61, 64-69: media content is playback only during the restricted time period and playback stops after expiration). Dell also teaches session key derived from time based one time password logic, where the time dependent input is required to derive the key on both sides (see Dell pars. 11-12, and 40-49).
Dependent claims 12 and 20 recite substantially similar subject matter to claim 4 and are therefore, rejected for similar reasons as applied to claim 4 above.
As to claim 5, Ivanchykin et al., Dell and Bart discloses the method of claim 1. Bart further teaches wherein the first video comprises a video segment captured by the first network-connected IoT camera and encrypted with a corresponding camera-specific session key and stored in a persistent storage on the service, the method further comprising: decrypting the first video using the camera-specific session key prior to encrypting the first video using the temporary session key to generate the first encrypted video (Bart par. 141: The encryption engine 1661 on the IoT device 101 may then decrypt the message using the secret and process the message contents; par. 223: the IoT device uses the session secret to decrypt the encrypted device packet; par. 143: If a response is required, the encryption engine 1661 on the IoT device 101 uses the secret or a derived key stream to encrypt the response and transmits the encrypted response; par. 230: the IoT device re-encrypts the packet using the session secret at 2329; pars. 153-154: IoT device key – device specific key).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Brat’s to enable secure temporary access to encrypted data/video while preserving end to end confidentiality.
Dependent claims 13 and 21 recite substantially similar subject matter to claim 5 and are therefore, rejected for similar reasons as applied to claim 5 above.
As to claim 7, Ivanchykin et al., Dell and Bart disclose the method of claim 5. Dell further teaches wherein the IoT service or the third party data processing device is to decrypt the first encrypted video using the temporary session key and the time-based nonce to generate unencrypted video content (par. 43: the sender device may encrypt the sensor data using the session key generated at block 308; par. 44: the session key used to encrypt the data is generated by further hashing the TOTP; par. 48: the receiver device may further hash the time-based one-time password to produce a session key; par. 49: the receiver device may decrypt the sensor data using the session key generated at block 316; par. 47: time-based one-time password in an embodiment may be used to generate a session key that may only remain valid for a preset period of time between the sending device encrypting a data communication, and a receiving device decrypting the data communication received from the sending device).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Dell to enable controlled, time limited access to encrypted content and to permit temporary decryption by an IoT service/third-party.
Dependent claims 15 and 23 recite substantially similar subject matter to claim 7 and are therefore, rejected for similar reasons as applied to claim 7 above.
Claims 3, 11, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Ivanchykin et al., Dell and Bart, and further in view of Steinberg et al. (5862217 and hereinafter referred to as Steinberg et al.).
As to claim 3, Ivanchykin et al. and Dell discloses the method of claim 1
wherein a time-based nonce is generated (Ivanchykin et al. teaches generating a nonce in conjunction with a counter value (i.e. time-based nonce) [Sections [0041]]).
Ivanchykin et al. does not disclose:
single time-based nonce is generated by a single nonce generator and shared for both the encrypting of the first video content and the decrypting of the first encrypted video.
However, Steinberg et al. does disclose:
single time-based nonce is generated by a single nonce generator and shared for both the encrypting of the first video and the decrypting of the first encrypted video (Steinberg et al. teaches a single password (seed, i.e. nonce) generated in a camera (i.e. single nonce generator) that is shared for the encryption and decryption of an image. [Figure 4 / Column 4, Lines: 1 – 17]).
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 invention of Ivanchykin et al., Dell and Bart with the teachings of Steinberg et al. for generating a single time-based nonce for shared encryption and decryption to increase efficiency in sharing video content.
Dependent claims 11 and 19 recite substantially similar subject matter to claim 3 and are therefore, rejected for similar reasons as applied to claim 3 above.
Claims 6, 14, and 22 are rejected under 35 U.S.C. 103 as being unpatentable over Ivanchykin et al., Dell, and Bart and further in view of Aghdasi et al. US 10491936 B2 (herein after Aghadisi et al.).
As to claim 6, Ivanchykin et al., Dell, and Bart discloses the method of claim 5. Bart
further teaches wherein [the video segment is stored with a plurality of other video segments captured] by the plurality of network-connected internet-of-things (IoT) cameras, each video segment of the plurality of video segments encrypted with a camera-specific key unique to one of the plurality of network-connected internet-of-things (IoT) cameras which captured the video segment (Bart par. 318: Referring to FIG. 40, in one embodiment, an over-the-air (OTA) update service 4050 on the IoT cloud service 120 tracks the firmware versions loaded on each IoT device 101 and maintains a user/device database 4010 containing the firmware versions; par. 319: … the IoT devices are registered and updated, the IoT cloud service 120 will know exactly what app images and profile images are stored on the IoT device 101, and whether they are in a particular storage slot within the IoT device's 101's non-volatile memory (e.g., slot 1 or slot 2). … the OTA update service 4050 will also track ancillary bits which are stored on the IoT device 101.; pars. 139, 147, 148 & 321 teach each IoT device having device session keys and data be encrypted using current session key. Bart also discusses IoT device key for encryption).
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 invention of Ivanchykin et al. and Dell to securely organize and store data from multiple IoT devices while maintaining device specific confidentiality. Applying the teachings of Barts would have been a routine and predictable design choice.
Ivanchykin et al., Dell and Bart fail to explicitly teach plural camera video segments stored.
the video segment is stored with a plurality of other video segments captured by a plurality of other cameras, each video segment of the plurality of video segments encrypted to the camera of the plurality of cameras which captured the video segment (Aghdasi et al. teaches of captured plurality of video segments by a plurality of cameras storing the videos segments in video servers and encrypted in the video servers. [Claim 1 / Column 5, Lines 42 - 53]).
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 invention of Ivanchykin et al., Dell and Bart. with the teachings of Aghdasi et al. for encryption of plurality of video segments from a plurality of cameras to increase security disbursement for video content.).
Dependent claims 14 and 22 recite substantially similar subject matter to claim 6 and are therefore, rejected for similar reasons as applied to claim 6 above.
Claims 8, 16 and 24 are rejected under 35 U.S.C. 103 as being unpatentable over Ivanchykin et al., Dell, Bart and Steinberg et al. as applied to claims 7, 15 and 23 above, and further in view of Dalley, JR. et al. (US 2020/0125838 A1 hereinafter referred to as Dalley, JR et al.).
As to claim 8, Ivanchykin et al., Dell, and Steinberg et al. do not disclose:
The method of claim 7 wherein the IoT service is to perform one or more object recognition operations and/or facial recognition operations on the unencrypted video content to identify objects and/or individuals, respectively, in the encrypted video content,
the method further comprising: generating metadata indicating the identity of the objects and/or individuals; and
associating the metadata with the first encrypted video and/or the unencrypted video content.
However, Dalley, JR. et al. do disclose:
The method of claim 7 wherein the service is to perform one or more object recognition operations and/or facial recognition operations on the unencrypted video content to identify objects and/or individuals, respectively, in the first encrypted video content, (Dalley, JR. et al. teaches a cloud-based facial recognition software (i.e. service) processing live or captured videos that can be encrypted for identifying individuals [Section [0076], [0077]])
the method further comprising: generating metadata indicating the identity of the objects and/or individuals; and (Dalley, JR. et al. teaches a descriptive metadata that identifies objects and locations within video streams [Section [0081]])
associating the metadata with the encrypted video content and/or the unencrypted video content. (Dalley, JR. et al. teaches an association between metadata and video feed for determine time and location of video that can be encrypted [Sections [0080], [0092]])
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 invention of Ivanchykin et al., Dell, and Steinberg et al. with the teachings of Dalley, JR. et al. for performing object and/or facial recognition on unencrypted video content in identifying objects and/or individuals associated with metadata to increase efficiency in identifying objects and/or individuals in video content.
Dependent claims 16 and 24 recite substantially similar subject matter to claim 8 and are therefore, rejected for similar reasons as applied to claim 8 above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
KR 20070032885 A: use symmetric key authentication using time stamp information and nonce information… Time stamps and nonce are introduced for the freshness of messages in a ubiquitous network environment, which can prevent response attacks. The time stamp also uses nonce as an additional countermeasure, ie nonce, since synchronized clocks may be needed for both communications. In addition, the security model of the present invention is a passive and active attacker to disguise the credentials of another person when accessing ubiquitous services in another network area by using tickets and session keys to verify the possession of the credentials
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 ELENI A SHIFERAW whose telephone number is (571)272-3867. The examiner can normally be reached 7-3:30 M-F.
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.
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.
/ELENI A SHIFERAW/Supervisory Patent Examiner, Art Unit 2497
Prosecution Insights