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 .
Status of Claims
This Office Action is in response to the application filed on 08/13/2026. Claims 1, 9, and 17 amended, claims 2, 10, and 18 cancelled. Thus, Claims 1, 3-9, 11-17, and 19-20 have been examined.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 07/16/2025 filed in accordance with the provisions of 37 CFR 1.97. Accordingly, it is being considered by the examiner.
Specification
The specification has not been reviewed in detail to determine the presence of all possible minor errors. Applicant's attention is directed to the specification, and applicant is requested to make any necessary corrections of which applicant is aware.
Response to Arguments
Applicant’s arguments, see Remarks, Pages 9-10, filed August 13, 2025, with respect to the rejection(s) of claim(s) 1, 9, and 17 have been fully considered. However, upon further consideration of the amended subject matter, a new ground of rejection is made in view of Hinds et al. (US-20250119588-A1).
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.
The factual inquiries for establishing a background for determining obviousness under 35
U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness
Claims 1, 3-4, 9, 11-12, 17, and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Hendry et al (US-20150271513-A1) “Hendry” in view of Hinds et al. (US-20250119588-A1) hereinafter “Hinds” further in view of Benedikt Meyer-Schwickerath “Analysis of adaptive streaming technologies for segmented multimedia transport of high-resolution videos for 360° playback on multiple devices” hereinafter “Meyer”.
Regarding Claim 1 Hendry-Hinds-Meyer
Hendry-Hinds-Meyer discloses 1. A method performed by at least one processor in a decoder, (Hendry, Fig. 1A-3B “ video decoder 30” [0216] “…the determination may be made by a processor or controller, such as processor/controller device 13 of FIG. 1B or one or more components of the video decoder 30 or a processor…”) the method comprising:
receiving a bitstream comprising visual media data, a supplementary enhancement information (SEI) message, and a first identifier included in a payload of the SEI message; (Hendry provides the received video bitstream and SEI message. Hendry also discloses an identifier used to determine whether the SEI message belongs to a first or second SEI-message category; ¶[0007] Meyer strengthens the receiving limitation by disclosing that received video includes metadata signaled as high level syntax via SEI messages of a payload, the metadata is metadata of content or metadata of period level information (identifier) See Mayer p.53, sec 4.1.2 3rd para; p.69, 4th para and p.72, sec 4.2)
. . .
decoding the visual media data in accordance with the metadata, (Hendry [0118] “The video decoder 30 may receive a bitstream that comprises encoded video data. The bitstream may include a plurality of syntax elements…entropy decoding unit 150 may entropy decode entropy encoded syntax elements in the bitstream. Prediction processing unit 152, inverse quantization unit 154, inverse transform unit 156, reconstruction unit 158, and filter unit 159 may perform a reconstruction operation that generates decoded video data based on the syntax elements extracted from the bitstream.”)
Hendry does not expressly disclose
determining a value of the first identifier;
in response to determining the value of the first identifier is a first value,
extracting the metadata from the payload of the SEI message;
in response to determining the value of the first identifier is a second value, referencing the metadata through use of the URI included in the payload of the SEI message; and
wherein the metadata comprises binary data,
wherein referencing the metadata by the SEI message is performed through use of a Uniform Resource Identifier (URI) in the payload of the SEI message,
wherein interpretation of the first identifier is defined externally to the payload of the SEI message.
However, in the same field of endeavor Hinds discloses more explicitly the following
determining a value of the first identifier; (Hinds, [0095] “EXIF mode ID 1303 can indicate whether the payload of the SEI message is the EXIF metadata itself or a URI for the location of the EXIF metadata”)
in response to determining the value of the first identifier is a first value,
extracting the metadata from the payload of the SEI message; (Hinds, ¶¶[0095], [0100], Fig. 13: when exif_mode_id/ mode ID 1303 is equal to ZERO, the EXIF data payload bype 1304 receives a byte of data from the SEI payload. “if mode ID 1303 is equal to ZERO, then EXIF data payload byte 1304 receives a byte of data from the SEI payload.”)
in response to determining the value of the first identifier is a second value, referencing the metadata through use of the URI included in the payload of the SEI message; (Hinds, ¶¶[0095], [0100] Fig. 13; Hinds discloses when exif_mode_id/mode ID 1303 is ONE, EXIF data URI 1305 receives a string of data from the SEI payload, wherein the URI identifies the location of the EXIF metadata. “…a URI for the location of the EXIF metadata.” “If mode ID 1303 is equal to ONE, then EXIF data URI 1305 receives a string of data from the SEI payload.”)
wherein the metadata comprises binary data, (Hind’s syntax expressly represents the metadata payload as bytes. Fig. 13 identifies exif_data_payload_byteas b(8). Thus, the metadata is carried as binary payload bytes.
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Hendry with Hinds to configure the system of Hendry to determine a value of the first identifier, in response to determining the value of the first identifier is a first value, extracting the metadata from the payload of the SEI message and in response to determining the value of the first identifier is a second value, referencing the metadata through use of the URI included in the payload of the SEI message as taught by Hinds. One of ordinary skill in the art would have been motivated to incorporate Hinds teachings into Hendry in order to provide signaling of image-format metadata within SEI message using a universal resource identifier flag, whereby the image-format metadata associated with the current image may be obtained from a payload of the SEI message. (Hinds, Abstract)
Hendry-Hinds does not expressly disclose
wherein referencing the metadata by the SEI message is performed through use of a Uniform Resource Identifier (URI) in the payload of the SEI message,
wherein interpretation of the first identifier is defined externally to the payload of the SEI message.
However, Meyer, which is in the same field of endeavor discloses
wherein referencing the metadata by the SEI message is performed through use of a Uniform Resource Identifier (URI) in the payload of the SEI message, (Meyer disclose OMAF-related metadata is signaled as SEI messages; DASH delivery of OMAF-specific information is extended by additional MPD DASH descriptors accessible by urn: mpeg: mpegI: omaf:
(Meyer p. 69, last para “OMAF-related metadata is signaled as SEI messages; DASH delivery of OMAF-specific information is extended by additional MPD DASH descriptors accessible by urn: mpeg: mpegI: omaf: (“OMAF-related metadata may be signalled as high level syntax via
SEI messages of the H.264 or HEVC _le. Information about the use of equirectangular
projection, cubemap projection, sphere rotation, region-wise packing and the viewport
location may be signalled as SEI. For speci_c SEI parameters of OMAF the reader is
referred to 5.5.2 of [52] and [51]. According to [51], for DASH delivery of OMAF-speci_c
information the MPD is extended by additional MPD DASH descriptors, accessible by
the URN `urn:mpeg:mpegI:omaf:2017' (hereinafter referred to as namespace a) and
`urn:mpeg:mpegI:omaf:2018' (hereinafter referred to as namespace b), de_ning the
namespaces for the XML elements and attributes.” see also page l04, Listing 5.18 “OMAF-conform schemes in MPD, of created DASH stream”).
wherein interpretation of the first identifier is defined externally to the payload of the SEI message. (Meyer discloses the hypertext links to other files are processed by requests of the client and responses of the server externally to the payload of the SEI message extracted by a decoder, shown in fig. 3.12;
(Meyer, p. 36, sec 3.2 “Constant quality and constant playback are a key for video streaming of an immersive audiovisual experience. As a consequence, the main demands on streaming scenarios and
the prior coding, are handling the varying network coverage and transmission quality,
saving computing power and hereby energy consumption and simultaneously maintain
adequate subjective and objective video quality … Regarding streaming scenarios most
important for a constant fluent playback is to control the transfer rate to let the data arrive
before it has to be displayed. This section first treats basic HTTP streaming roughly
and outlines streaming technologies, … the approach of adaptive streaming using tiles is introduced
and approaches of predicting the ROI and FOV are presented. Afterwards MPEG
Dynamic Adaptive Streaming over HTTP (DASH) as a common and e_ective streaming
standardization over HTTP is explained in Section 4.1.2. It has been developed by MPEG
and published in 2012. Unlike as in traditional broadcast scenario, for streaming per internet a direct connection
between each client and server, hosting the video content is established. For the
data transfer several transport protocols are used, to standardize the communication, i.e.
requests of the client and responses of the server. It is useful to distinguish between
on-demand and live streaming, to select the respective streaming enviroment, i.e. protocols,
speci_cations etc. Popular protocols for on-demand access are HTTP and FTP,
whereas protocols for live streaming are RTP, RTCP, RTSP, SIP [81]. Figure 3.12…” see also page 37, sec 3.2.1; page 68, sec 4.1.5.4).
Therefore, it would have been obvious to a person having ordinary skill in the art before
the effective filing date of the application to modify the teachings of Hendry’s SEI message framework with Meyer’s URI-based metadata referencing, as outlined above, in order to provide that referencing the metadata by the SEI message is performed through the use of a Uniform Resource Identifier (URI) in the payload of the SEI message, and that interpretation of the first identifier is defined externally to the payload of the SEI message.
A person of ordinary skill in the art would have been motivated to incorporate Meyer’s URI-based metadata identification into Hendry’s SEI message framework to allow metadata associated with video data to be identified, referenced, and interpreted according to an externally defined scheme, thereby improving clarity and consistency in the decoder’s interpretation and treatment of SEI messages. Hendry recognizes that ambiguity in SEI message semantics can cause different encoder/decoder implementations to behave inconsistently (Hendry ¶[0142]) and further teaches that clarifying SEI semantics makes the behavior of encoders/decoders more predictable and the treatment of SEI messages more consistent ( Hendry ¶[0145])
Note: The motivation set forth with respect to claim 1 is equally applicable to 3-4, 9, 11-12, 17, and 19-20
Regarding Claim 2 Cancelled
Regarding Claims 3, 11 and 19 Hendry-Hinds-Meyer
Hendry-Hinds-Meyer discloses 3. The method according to claim 1,
wherein the bitstream further includes a payload size, and wherein in response to determining the value of the first identifier is the first value, an amount of the metadata extracted from the payload of the SEI message is in accordance with the payload size. (Hendry discloses that the bitstream further includes a payload size. Specifically, Hendry discloses that the SEI message syntax includes payloadType 502 and payloadSize 504 and that payloadSize 504 is equal to the number of raw byte sequences payload bytes in the SEI message payload (Hendry ¶[0169]). Hendry further discloses extracting SEI data from NAL units during parsing of the bitstream (Hendry ¶[0119]). Thus, the amount of SEI metadata extracted from payload is in accordance with the payload size because the payloadSize identifies the number of payloadize bytes to be extracted from the SEI message payload.)
Regarding Claims 4, 12, 20 Hendry-Hinds-Meyer
Hendry-Hinds-Meyer disclose 4. The method according to claim 1,
wherein the bitstream includes a second identifier that indicates a type of the binary metadata. (Meyer discloses referencing metadata through use of a URI. Essential Property scheme ld Uri is binary data; “Listing 5.6: …MPD XML. as an example for the base-tile-track….
” listing 5.6 page 88)
Regarding Claim 9 Hendry-Hinds-Meyer
Hendry discloses 9. A method performed by at least one processor in an encoder, (Hendry, [0075] FIG. 2A is a block diagram illustrating an example of the video encoder 20 that may…the video encoder 20 may be configured to process a single layer of a video frame, ….to perform … various components of the video encoder 20…additionally or alternatively, a processor…the method comprising:
receiving visual media data; ( Hendry, [0043] “FIG. 1A, the source device 12 includes a video source 18, video encoder 20 …the video source 18 may include a source such as a video capture device, e.g., a video camera, a video archive containing previously captured video, a video feed interface to receive video from a video content provider,…”)
. . .
encoding the visual media data in accordance with the metadata, (Hendry, [0055] “…the video encoder 20 performs an encoding operation on a slice, the video encoder 20 may generate encoded data associated with the slice…” [0056] “To generate a coded slice, the video encoder 20 may perform encoding operations on each treeblock in a slice…”)
The remaining limitations of claim 9 substantially correspond to those of independent claim 1, except that claim 9 is directed to an encoder rather than a decoder. As recognized in the art, video encoders and decoders perform corresponding complementary operations. Accordingly, the reference teaches the remaining limitations for the reasons discussed above with respect to claim 1.
Regarding Claim 10 and 18 Cancelled
Regarding Claim 17 Hendry-Hinds-Meyer
Claim 17 recites processing a bitstream of visual data according to a format rule. Meyer teaches processing a bitstream according to a format rule by disclosing SEI message signaling rules including “geometry type”, projection type,” coordinate-system parameters, yaw/pitch ranges, viewport information and region-wise quality indications for an HEVC-conforming bitstream (Mayer, p. 72, sec 4.2. 3rd para)
( “As proposed in [29] and [30], the ‘geometry_type’ informs about the coordinate
system used for projection, i.e. spherical coordinates or cartesian coordinates. The ‘projection_type’ SEI message indicates whether equirectangular projection, cubemap projection or rectilinear projection is set, i.e. type 0, 1, 2. The coordinate-system center position is defined by yaw, pitch and roll center values. The coordinate-system expan-sion, i.e. the ranges, for the yaw and pitch values are determined by ‘yaw_range’ and ‘pitch_range’ respectively. The rectilinear projection type indicates a predetermined viewport, as an extracted region of an entire spherical video bitstream, with its corre-sponding position and size. In this case, first the region is extracted and afterwards rectilinear projection is used. The omnidirectional viewport SEI message, can be used for definition of at least one certain viewport, represented by spherical coordinates. If the bitstream is encoded with quality grades, a corresponding indication for the quality of a certain region is necessary, which can be signalled as region-wise quality indication SEI message. The RWP can also be signalled as SEI message,…” see also p. 53, sec 4.1.2.)
The remaining limitations of claim 17 substantially correspond to those discussed above with respect to claims 1and 9. Accordingly, the references teach the limitations of claim 17 for the reasons discussed above.
Claim Rejections - 35 USC § 103
Claims 5-6 and 13-14 are rejected under 35 U.S.C. 103 as being unpatentable over Hendry-Hinds-Meyer further in view DE LAGRANGE PHILIPPE (WO-2025149264-A1) hereinafter “De Lagrange”
Regarding Claims 5 and 13 Hendry-Hinds-Meyer-De Lagrange
Hendry-Hinds-Meyer discloses 5. The method according to claim 4,
Hendry-Hinds-Meyer does not explicitly disclose
wherein the second identifier has a first value that indicates the type of the binary metadata is Exchangeable Image File (Exif), a second value that indicates the type of the binary metadata is JFXX, and a third value that indicates the type of the binary metadata is Extreme Memory Profile (XMP).
However, in the same field of endeavor De Lagrange discloses more explicitly the following:
wherein the second identifier has a first value that indicates the type of the binary metadata is Exchangeable Image File (Exif), a second value that indicates the type of the binary metadata is JFXX, and a third value that indicates the type of the binary metadata is Extreme Memory Profile (XMP). (De Lagrange teaches that the type of binary metadata is indicated by an identifier associated with a JPEG segment, such as an App marker and/or the character string at the beginning of the payload. In particular, De Lagrange teaches that JPEG metadata structures may include EXIF, JFIF, and XMP metadata. See De Lagrange, P. 13, lines 18-21. “…JPEG File Interchange Format, as specified…can also carry metadata and embed externally defined structures like EXIF, JFIF, XMP, IPTC or ICC color profiles.” (P. 13, lines 18-21 ) De Lagrange further teaches that APPO followed by “JFIF” or “JFXX” is used to identify JPEG container information, and that APP1 followed by “EXIF” is commonly used to carry “EXIF” metadata. See De Lagrange, p. 14, lines 2-10, “...APPO followed by “JFIF” or “JFXX” is used to carry supplementary specifications for the container format that contains the image data encoded with the JPEG algorithm. This is illustrated by the element 660 where the marker (661) is set of OxFFEO to identify APPO. The first bytes of the payload are set to “JFIF” (663) to select the JFIF format. The length parameter (662) is used to determine the length of the payload. It equals to the total segment payload length. …The payload (664) carries the data. In a second example, APP1 followed by “EXIF” string is commonly used to carry EXIF metadata. A JPEG file can also contain other types of payloads for other applications” P.17, lines 14-17, “In at least one embodiment, a PNG SEI message is used to embed pictures or part of picture files encoded in PNG format. …Some metadata formats (e.g. Exif, XMP) can be embedded in text fields, using specific leading keywords..”)
Therefore, it would have been obvious to a person having ordinary skill in the art before
the effective filing date of the application to modify the teachings of Hendry-Hinds-Meyer with De Lagrange so that the second identifier has a first value indicating EXIF metadata, a second value indicating JFXX metadata, and a third value indicating XMP as suggested by De Lagrange.
One of ordinary skill in the art would have been motivated to incorporate De Lagrange’s known JPEG metadata identifier into Hendry-Hinds-Meyer to identify the type of binary metadata carried in the SEI payload and to enable standardized extraction at p. 12, lines 14-23 and p. 13, lines 18-21.
Note: The motivation set forth with respect to claim 5 is equally applicable to claim 13.
Regarding Claim 6 and 14 Hendry-Hinds-Meyer-De Lagrange
Hendry-Hinds-Meyer-De Lagrange discloses 6. The method according to claim 5,
wherein the second identifier has a fourth value that indicates the type of the binary metadata is a JPEG File Interchange Format (JFIF) header only, a fifth value that indicates the type of the binary metadata is a JFIF extension only, and a sixth value that indicates the type of the binary metadata is both the JFIF header and the JFIF extension. (De Lagrange teaches that APPO followed by “”JFIF” or “JFXX” is used to identify JPEG container information, See De Lagrange p. 14, lines 1-8 “…APPO followed by “JFIF” or “JFXX” is used to carry supplementary specifications for the container format that contains the image data encoded with the JPEG algorithm. This is illustrated by the element 660 where the marker…identify APPO. The first bytes of the payload are set to “JFIF” (663) to select the JFIF format. The length parameter (662) is used to determine the length of the payload. It equals to the total segment payload length…”)
Note: The motivation set forth with respect to claim 6 is equally applicable to claim 14.
Claim Rejections - 35 USC § 103
Claims 7 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Hendry-Hinds-Meyer further in view of Boyce (US-20210014467-A1) hereinafter “Boyce”.
Regarding Claims 7 and 15 Hendry-Hinds-Meyer-Boyce
Hendry-Hinds-Meyer discloses 7. The method according to claim 1,
wherein the bitstream further comprises a cancel flag, and wherein the first identifier is extracted in accordance with a value of the cancel flag. (Boyce, [0041] “omni_viewport_cancel_flag equal to 1 indicates that the SEI message cancels the persistence of any previous omnidirectional viewport SEI message in output order. omni_viewport_cancel_flag equal to 0 indicates that omnidirectional viewport information follows. This may be used so that a viewport SEI is used only when there is a change in the viewport.”)
Therefore, it would have been obvious to a person having ordinary skill in the art before
the effective filing date of the application to modify the teachings of Hendry-Hinds-Meyer with Boyce so that the bitstream further comprises a cancel flag and the first identifier is extracted in accordance with a value of the cancel flag, as suggested by Boyce.
Once of ordinary skill in the art would have been motivated to incorporate Boyce’s cancel-flag based SEI message into Hendry-Hinds-Meyer to allow each scene and region-of-interest change to be flagged with a different SEI message, thereby, changing the viewport for the correspondence frame as described by Boyce in ¶[0076].
Note: The motivation set forth with respect to claim 7 is equally applicable to claim 15.
Claim Rejections - 35 USC § 103
Claims 8 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Hendry-Hinds-Meyer further in view of Gaddy et al. (US-8836716-B1) hereinafter “Gaddy”.
Regarding Claims 8 and 16 Hendry-Hinds-Meyer-Gaddy
Hendry-Hinds-Meyer discloses 8. The method according to claim 1,
Hendry-Hinds-Meyer does not explicitly disclose
wherein the SEI message is an International Color Consortium (ICC) profile SEI message.
However, in the same field of endeavor Gaddy discloses more explicitly the following:
wherein the SEI message is an International Color Consortium (ICC) profile SEI message. (Col. 16, lines 31-40, “The JPEG File Interchange Format (hereinafter, JFIF) is commonly used to encapsulate JPEG compressed imagery, and JFIF specifies well-known metadata extensions in many formats including EXIF, ICC profile, and Picture Info, any of which can be used to convey information about the presence and values …. H264 encoded bitstreams support the inclusion of optional supplemental enhancement information (SEI) headers…”)
Therefore, it would have been obvious to a person having ordinary skill in the art before
the effective filing date of the application to modify the teachings of Hendry-Hinds-Meyer with Gaddy so that the SEI message is an International Color Consortium (ICC) profile SEI message, as suggested by Gaddy.
One of ordinary skill in the art would have been motivated to incorporate Gaddy’s ICC profile metadata into Hendry-Hinds-Meyer’s SEI message to convey color-profile information in the encoded video bitstream, thereby improving perceptual quality and encoding efficiency of image and video compression systems.
Note: The motivation set forth with respect to claim 8 is equally applicable to 16.
Pertinent Prior Art
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
A. Kondrad et al. (US-20250274611-A1)
Conclusion
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 ASTEWAYE GETTU ZEWEDE whose telephone number is (703)756-1441. The examiner can normally be reached Mo-Fr 8:30 am to 5:30 pm.
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, William Vaughn can be reached at (571)272-3922. 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.
/ASTEWAYE GETTU ZEWEDE/Examiner, Art Unit 2481 /WILLIAM C VAUGHN JR/Supervisory Patent Examiner, Art Unit 2481
Prosecution Insights