Prosecution Insights
Last updated: April 19, 2026
Application No. 18/519,521

Dynamically Allocated Memory-Backed Traversal Stack for Ray Tracing Hardware

Final Rejection §103
Filed
Nov 27, 2023
Examiner
TRUONG, KARL DUC
Art Unit
2614
Tech Center
2600 — Communications
Assignee
Advanced Micro Devices, Inc.
OA Round
2 (Final)
52%
Grant Probability
Moderate
3-4
OA Rounds
2y 7m
To Grant
83%
With Interview

Examiner Intelligence

Grants 52% of resolved cases
52%
Career Allow Rate
15 granted / 29 resolved
-10.3% vs TC avg
Strong +31% interview lift
Without
With
+31.0%
Interview Lift
resolved cases with interview
Typical timeline
2y 7m
Avg Prosecution
45 currently pending
Career history
74
Total Applications
across all art units

Statute-Specific Performance

§101
3.2%
-36.8% vs TC avg
§103
85.3%
+45.3% vs TC avg
§102
9.5%
-30.5% vs TC avg
§112
2.1%
-37.9% vs TC avg
Black line = Tech Center average estimate • Based on career data from 29 resolved cases

Office Action

§103
DETAILED ACTION Notice of Pre-AIA or AIA Status The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . Response to Amendment This action is in response to the amendment filed on 10th November, 2025. Claims 1, 5, 9, and 16 have been amended. Claim 20 has been cancelled. Claims 1-19 and 21 remain rejected in the application. Applicant's amendments to the claims have overcome each and every objection previously set forth in the non-final office action mailed 10th July, 2025. Response to Arguments Applicant's arguments with respect to Claims 1, 9, and 16 filed on 10th November, 2025, with respect to the rejection under 35 U.S.C. § 103, regarding that the prior art does not teach the limitation(s): "each allocated memory block is linked to one or more other memory blocks associated with the ray to form a linked memory stack" has been fully considered, but are moot because of new grounds for rejection. It has now been taught by the combination of Rabbani and Goudie. Regarding arguments to Claims 2-8, 10-15, 17-19, and 21, they directly/indirectly depend on independent Claims 1, 9, and 16 respectively. Applicant does not argue anything other than independent Claims 1, 9, and 16. The limitations in those claims, in conjunction with combination, was previously established as explained. Claim Objections Claims 10-15, 17-18, and 21 are objected to because of the following informalities: Claim 10 recites the limitation(s): "The method as claimed in claim 8" on PG(s). 3, Line(s) 14; examiner suggests amending this to "The method as claimed in claim 9"; Claim 11 recites the limitation(s): "The method as claimed in claim 8" on PG(s). 3, Line(s) 16; examiner suggests amending this to "The method as claimed in claim 10"; see Claim 2; Claim 12 recites the limitation(s): "The method as claimed in claim 8" on PG(s). 3, Line(s) 21; examiner suggests amending this to "The method as claimed in claim 9"; Claim 13 recites the limitation(s): "The method as claimed in claim 8" on PG(s). 3, Line(s) 23; examiner suggests amending this to "The method as claimed in claim 9"; Claim 14 recites the limitation(s): "The method as claimed in claim 8" on PG(s). 4, Line(s) 1; examiner suggests amending this to "The method as claimed in claim 9"; Claim 15 recites the limitation(s): "The method as claimed in claim 8" on PG(s). 4, Line(s) 3; examiner suggests amending this to "The method as claimed in claim 9"; Claim 17 recites the limitation(s): "The system as claimed in claim 15" on PG(s). 4, Line(s) 16; examiner suggests amending this to "The system as claimed in claim 16"; Claim 18 recites the limitation(s): "The system as claimed in claim 15" on PG(s). 4, Line(s) 18; examiner suggests amending this to "The system as claimed in claim 16"; and Claim 21 recites the limitation(s): "The system as claimed in claim 15" on PG(s). 5, Line(s) 1; examiner suggests amending this to "The system as claimed in claim 16".For the purposes of compact prosecution, the proposed corrections are being used. Appropriate correction is required. 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, 4, 6-7, 9, 12-14, 16, 18 and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Rabbani Rankouhi et al. (US 20220036637 A1, previously cited), hereinafter referenced as Rabbani, in view of Goudie (US 20220114013 A1). Regarding Claim 1, Rabbani discloses a system (Rabbani, [0228]: teaches a system/device 2700) comprising: ray tracing circuitry configured to assign, to a ray, at least one ray stack [[in a first memory]] (Rabbani, [0169]: teaches a ray intersection circuitry (e.g., a Ray Intersection Accelerator (RIA)) <read on ray tracing circuitry> including a grouping control circuitry 1910 that is configured to assign rays to groups of rays <read on ray stack>); and [[memory allocation]] circuitry configured to allocate at least one memory block to the ray from a memory stack in a second memory, responsive to intersection testing of the ray against one or more nodes of a hierarchical acceleration structure (Rabbani, [0093]: teaches the organization of a ray shader core space (SCS) for storing ray data, where "the ray SCS is a private memory space <read on second memory> that may be dynamically allocated and may allow sharing of data between different thread groups"; [0095]: teaches the SCS including "regions for ray core data 820, ray stack data 830 <read on memory stack>, ray extended data 840, and token buffers 810" as shown in FIG. 8; [0163]: teaches a single-instruction multiple-data (SIMD) group including "an instruction to allocate memory space for the set of rays <read on allocate memory block to ray from memory stack> in the shader memory space prior to executing the ray intersection instruction"; FIG. 14B teaches an example method for forming SIMD groups for primitive testing, where between steps 1410-1430, the ray intersect circuitry receives a ray intersect instruction <read on responsive to intersection testing of ray against nodes> for a first SIMD group, which then traverses multiple nodes of a spatially organized acceleration data structure, which then forms a second SIMD group in response to reaching a node in the acceleration data structure <read on node of hierarchical acceleration structure>), wherein PNG media_image1.png 562 155 media_image1.png Greyscale PNG media_image2.png 333 452 media_image2.png Greyscale [[each allocated memory block is linked to one or more other memory blocks associated with the ray to form a linked memory stack.]] However, Rabbani does not expressly disclose ray tracing circuitry configured to assign, to a ray, at least one ray stack in a first memory; and memory allocation circuitry configured to allocate at least one memory block to the ray from a memory stack in a second memory, responsive to intersection testing of the ray against one or more nodes of a hierarchical acceleration structure, wherein each allocated memory block is linked to one or more other memory blocks associated with the ray to form a linked memory stack. Goudie discloses ray tracing circuitry configured to assign, to a ray, at least one ray stack in a first memory (Goudie, FIG. 3 teaches allocating a block of memory <read on first memory> for a primary ray tracing task); and PNG media_image3.png 629 447 media_image3.png Greyscale memory allocation circuitry configured to allocate at least one memory block to the ray from a memory stack in a second memory, responsive to intersection testing of the ray against one or more nodes of a hierarchical acceleration structure (Goudie, [0064]: teaches a block of memory being allocated in off-chip memory <read on memory allocation circuitry>), wherein each allocated memory block is linked to one or more other memory blocks associated with the ray to form a linked memory stack (Goudie, FIG. 3 teaches allocating blocks of memory from a heap <read on linked memory stack> for both primary and secondary ray tracing tasks; Note: it should be noted that a heap is a tree-based data structure that links nodes to each, including allocated memory, where each memory block shares the same heap). Goudie is analogous art with respect to Rabbani because they are from the same field of endeavor, namely performing ray tracing intersection tests. Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to implement a system that allocates blocks of memory on a per-instance or per-task basis as taught by Goudie into the teaching of Rabbani. The suggestion for doing so would allow for a dynamic memory allocation system that uses sufficient memory whilst reducing overall memory usage. Therefore, it would have been obvious to combine Goudie with Rabbani. Regarding Claim 9, it recites the limitations that are similar in scope to Claim 1, but in a method. As shown in the rejection, the combination of Rabbani and Goudie discloses the limitations of Claim 1. Additionally, Rabbani discloses a method (Rabbani, [0060]: teaches a method for detecting ray intersection using ray intersection circuitry) comprising:… Thus, Claim 9 is met by Rabbani according to the mapping presented in the rejection of Claim 1, given the system corresponds to a method. Regarding Claim 16, it recites the limitations that are similar in scope to Claim 1. As shown in the rejection, the combination of Rabbani and Goudie discloses the limitations of Claim 1. Additionally, Rabbani discloses a system (Rabbani, [0228]: teaches a system/device 2700) comprising: a local buffer (Rabbani, [0096]: teaches the RIA 190 populating a buffer <read on local buffer> with thread data needed by the SIMD group); and processing circuitry configured to (Rabbani, [0061]: teaches a graphics shader circuitry <read on processing circuitry>):… Thus, Claim 16 is met by Rabbani according to the mapping presented in the rejection of Claim 1. Regarding Claims 4, 12, and 18, the combination of Rabbani and Goudie discloses the system, the method, and the system of Claims 1, 9, and 16 respectively. Additionally, Rabbani further discloses wherein the memory allocation circuitry is further configured to associate the ray with the at least one memory block (Rabbani, [0178]: teaches "the ray intersect circuitry (e.g. using grouping circuitry 1910 <read on memory allocation circuitry>) groups portions of the set of rays <read on associate ray with memory block> into multiple groups based on the node of the data structure that they target next"; [0182]: teaches the groups being specified by a linked list, where "entries in a ray queue <read on memory block> include a field that points to a next ray in the linked list for the corresponding ray's current group"). Regarding Claims 6 and 13, the combination of Rabbani and Goudie discloses the system and the method of Claims 1 and 9 respectively. Additionally, Rabbani further discloses wherein the memory allocation circuitry is configured to identify the at least one memory block using a free-list structure (Rabbani, [0169]: teaches "each time the top of the traversal stack changes for a given ray, the RIA searches allocated groups to find a match for the corresponding key," where the "RIA may include grouping control circuitry 1910 <read on memory allocation circuitry> as shown in FIG. 19B configured to assign rays to groups"; [0172]: teaches "the matching group determined by grouping circuitry 1910 is an index into dedicated circuitry configured to store lists of rays for each allocated group <read on identify memory block>," where "the matching group may be indicated using attributes of a data structure <read on free-list structure>"; Note: it should be noted that a free-list structure is commonly known as a linked list that manages a pool of available memory blocks in preparation for memory allocation). PNG media_image4.png 144 366 media_image4.png Greyscale Regarding Claims 7 and 14, the combination of Rabbani and Goudie discloses the system and the method of Claims 1 and 9 respectively. Additionally, Rabbani further discloses wherein the memory stack comprises a plurality of memory blocks in a linked list data structure (Rabbani, [0173]: teaches a linked list implementation <read on linked list data structure> for grouping rays <read on memory stack>, where "each ray queue entry <read on memory blocks> indicates a ray ID (e.g., for rays A, C, and E), a stack top field that indicates the next target node (e.g., where 0x2C is a node identifier that identifies node 1 in the example of FIG. 19A), and a next ray field that indicates the location of the next ray in the list"; Note: it should be noted that the memory blocks are being interpreted as nodes of a linked list data structure). PNG media_image5.png 144 452 media_image5.png Greyscale Regarding Claim 21, the combination of Rabbani and Goudie discloses the system of Claim 16. Additionally, Rabbani further discloses wherein the memory device comprises a plurality of memory blocks in a linked list data structure associated with a ray stack (Rabbani, [0169]: teaches "each time the top of the traversal stack changes for a given ray, the RIA searches allocated groups to find a match for the corresponding key," where the "RIA may include grouping control circuitry 1910 <read on memory device> as shown in FIG. 19B configured to assign rays to groups"; [0173]: teaches a linked list implementation <read on linked list data structure> for grouping rays, where "each ray queue entry <read on memory blocks> indicates a ray ID (e.g., for rays A, C, and E), a stack top field that indicates the next target node (e.g., where 0x2C is a node identifier that identifies node 1 in the example of FIG. 19A), and a next ray field that indicates the location of the next ray in the list"; [0098]: teaches ray core data 820 being indexed using a ray identifier, which corresponds to the ray ID of a queue entry of the linked list implementation <read on linked list data structure associated with ray stack>; Note: it should be noted that it is being interpreted that there is an association between a given ray core data and a respective ray stack data). Claims 2-3, 5, 8, 10-11, 15, 17, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Rabbani Rankouhi et al. (US 20220036637 A1, previously cited), hereinafter referenced as Rabbani, in view of Goudie (US 20220114013 A1) as applied to Claims 1, 9, and 16 above respectively, and further in view of Majewski et al. (US 20230359496 A1, previously cited), hereinafter referenced as Majewski. Regarding Claims 2 and 10, the combination of Rabbani and Goudie discloses the system and the method of Claims 1 and 9 respectively. The combination does not expressly disclose the limitations of Claims 2 and 10; however, Majewski discloses wherein the ray stack has a fixed size (Majewski, [1031]: teaches "the ray tracing hardware unit manages the ray tracing stack allocation counters to keep the active set size <read on fixed size> within the predefined or limit—e.g., so that it fits into the L1 data cache/LSC") and the memory stack has a variable size (Majewski, [0686]: teaches "in top-down BVH builds, it is necessary to partition/sort the list of integer indices <read on memory stack> in order to recurse during the build and for the index ordering to reflect the tree structure"; Note: it should be noted that it is common in the art to have a BVH tree vary in size). Majewski is analogous art with respect to Rabbani, in view of Goudie because they are from the same field of endeavor, namely efficient processing of ray-traced BVH data structures. Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to have the ray stack stored on local L1 cache memory as taught by Majewski into the teaching of Rabbani, in view of Goudie. The suggestion for doing so would allow for faster processing of ray-traced BVH data structures, thereby improving overall rendering performance. Therefore, it would have been obvious to combine Majewski with Rabbani, in view of Goudie. Regarding Claims 3 and 11, the combination of Rabbani, Goudie, and Majewski discloses the system and the method of Claims 2 and 10 respectively. Additionally, Rabbani further discloses wherein the memory allocation circuitry is configured to: store, in the at least one memory block, data associated with a current node of the hierarchical acceleration structure being traversed by the ray (Rabbani, FIG. 19A teaches an example situation with different rays currently targeting different nodes <read on current node> in an ADS <read on hierarchical acceleration structure> during tree traversal; [0166]: teaches "the graphics processor is configured to group rays to increase the number of rays testing against a node at a given time"; [0167]: teaches "the graphics processor allocates each ray to a group before the ray is allowed to test"; [0168]: teaches "information for each group indicates a list of rays in that group," where "dedicated circuitry is configured to store the list of rays for each bin" and "various numbers of entries may be used for grouping in various implementations, e.g., 64, 128, 256, or 512 groups with 4, 8, 16, 32, or 64 entries each"; [0173]: teaches the linked list implementation for grouping rays as ray queue entries <read on store in memory block data>, where a ray ID is used for each ray queue to indicate their respective ray from the ray stack); and PNG media_image6.png 208 324 media_image6.png Greyscale create a link between the at least one memory block and one or more other memory blocks in the memory stack associated with the ray (Rabbani, [0173]: teaches a linked list implementation for grouping rays, where each "when a ray is grouped, it may be added to the end of the group list <read on creating a link between memory blocks in memory stack> and a tail pointer maintained by the grouping circuitry 1910 may be updated"). Regarding Claim 5, the combination of Rabbani and Goudie discloses the system of Claim 1. The combination of Rabbani and Goudie does not expressly disclose the limitations of Claim 5; however, Majewski discloses wherein the ray stack is in a memory local to the ray tracing circuitry (Majewski, [1023]: teaches the RT Stack 9300 <read on ray stack> being stored in a local cache, such as LSC 9202A, to reduce access latency and increase bandwidth as shown in FIG. 92B; FIG. 92B teaches L1/LSC 9202A and RT HW 9203A <read on ray tracing circuitry> being located in core 9211A of slice 9201A <read on memory being local to ray tracing circuitry>, which communicates data with L2/L3 9210 cache memory as shown in FIG. 92A), and PNG media_image7.png 308 395 media_image7.png Greyscale the memory stack is in a memory that is not local to the ray tracing circuitry (Majewski, FIG. 92A teaches memory 9298 <read on memory stack> communicating with memory interface 9215 of L2/L3 9210 cache memory, where memory 9298 is located outside <read on memory not being local to ray tracing circuitry> of slice 9201A, which contains RT HW 9203A <read on ray tracing circuitry>). PNG media_image8.png 300 563 media_image8.png Greyscale Majewski is analogous art with respect to Rabbani, in view of Goudie because they are from the same field of endeavor, namely efficient processing of ray-traced BVH data structures. Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to have the ray stack stored on local L1 cache memory as taught by Majewski into the teaching of Rabbani, in view of Goudie. The suggestion for doing so would allow for faster processing of ray-traced BVH data structures, thereby improving overall rendering performance. Therefore, it would have been obvious to combine Majewski with Rabbani, in view of Goudie. Regarding Claims 8 and 15, the combination of Rabbani and Goudie discloses the system and the method of Claims 1 and 9 respectively. The combination of Rabbani and Goudie does not expressly disclose the limitations of Claims 8 and 15; however, Majewski discloses a plurality of ray stacks, each associated with a separate memory stack (Majewski, FIG. 52A teaches traversal 5002, where rays are allocated by allocator 5205 to either ray bank 0 or ray bank 1 <read on ray stacks>, which corresponds to stack 0 and stack 1 <read on separate memory stacks>). PNG media_image9.png 334 556 media_image9.png Greyscale Majewski is analogous art with respect to Rabbani, in view of Goudie because they are from the same field of endeavor, namely efficient processing of ray-traced BVH data structures. Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to have the ray stack stored on local L1 cache memory as taught by Majewski into the teaching of Rabbani, in view of Goudie. The suggestion for doing so would allow for faster processing of ray-traced BVH data structures, thereby improving overall rendering performance. Therefore, it would have been obvious to combine Majewski with Rabbani, in view of Goudie. Regarding Claim 17, the combination of Rabbani and Goudie discloses the system of Claim 16. The combination of Rabbani and Goudie does not expressly disclose the limitations of Claim 17; however, Majewski discloses wherein the local buffer comprises a plurality of ray stacks, each having a fixed size (Majewski, [1031]: teaches "the ray tracing hardware unit manages the ray tracing stack allocation counters to keep the active set size <read on fixed size> within the predefined or limit—e.g., so that it fits into the L1 data cache/LSC"; [1023]: teaches "both rays to be traversed and traversal results are passed through these ray tracing stack 9300 allocations <read on plurality of ray stacks>"). Majewski is analogous art with respect to Rabbani, in view of Goudie because they are from the same field of endeavor, namely efficient processing of ray-traced BVH data structures. Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to have the ray stack stored on local L1 cache memory as taught by Majewski into the teaching of Rabbani, in view of Goudie. The suggestion for doing so would allow for faster processing of ray-traced BVH data structures, thereby improving overall rendering performance. Therefore, it would have been obvious to combine Majewski with Rabbani, in view of Goudie. Regarding Claim 19, the combination of Rabbani, Goudie, and Majewski discloses the system of Claim 17. Additionally, Rabbani further discloses wherein the processing circuitry is configured to store data that identifies a memory block in the memory device that remains to be processed (Rabbani, [0172]: teaches "the matching group determined by grouping circuitry 1910 is an index into dedicated circuitry configured to store lists of rays for each allocated group <read on identify memory block>," where "the matching group may be indicated using attributes of a data structure"). Conclusion The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Lee et al. (US 20200264970 A1) discloses a system that manages the allocation of memory to an application program using a dependency tree; and Zirr et al. (US 20230297508 A1) discloses a system that includes hardware acceleration and memory allocation blocks for performing texture lookups and ray-tracing. 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 KARL TRUONG whose telephone number is (703)756-5915. The examiner can normally be reached 7:30 AM - 5:00 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, Kent Chang can be reached at (571) 272-7667. 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. /K.D.T./Examiner, Art Unit 2614 /KENT W CHANG/Supervisory Patent Examiner, Art Unit 2614
Read full office action

Prosecution Timeline

Nov 27, 2023
Application Filed
Jul 03, 2025
Non-Final Rejection — §103
Nov 10, 2025
Response Filed
Dec 01, 2025
Final Rejection — §103
Mar 06, 2026
Applicant Interview (Telephonic)
Mar 06, 2026
Examiner Interview Summary
Apr 07, 2026
Request for Continued Examination
Apr 11, 2026
Response after Non-Final Action

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12573149
DATA PROCESSING METHOD AND APPARATUS, DEVICE, COMPUTER-READABLE STORAGE MEDIUM, AND COMPUTER PROGRAM PRODUCT
2y 5m to grant Granted Mar 10, 2026
Patent 12561875
ANIMATION FRAME DISPLAY METHOD AND APPARATUS, DEVICE, AND STORAGE MEDIUM
2y 5m to grant Granted Feb 24, 2026
Patent 12494013
AUTODECODING LATENT 3D DIFFUSION MODELS
2y 5m to grant Granted Dec 09, 2025
Patent 12456258
SYSTEMS AND METHODS FOR GENERATING A SHADOW MESH
2y 5m to grant Granted Oct 28, 2025
Patent 12444020
FLEXIBLE IMAGE ASPECT RATIO USING MACHINE LEARNING
2y 5m to grant Granted Oct 14, 2025
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

3-4
Expected OA Rounds
52%
Grant Probability
83%
With Interview (+31.0%)
2y 7m
Median Time to Grant
Moderate
PTA Risk
Based on 29 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month