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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on February 5, 2026 has been entered.
Response to Amendment
The amendment filed on February 5, 2026, cancelled claims 22 and 23. Claims 1-2, 4-7, 9, 12-13, and 17-21 were amended and new claims 24-25 were added. Thus, the currently pending claims addressed below are claims 1-2, 4-7, 9-13, 15-21, and 24-25.
Claim Interpretation
The following terms have been interpreted in light of the specification:
Promotion data of the item: describe text-based parameters of the item such as promotion start date, promotion end date, and/or item discount amount (Based on at least paragraph 3, 20, 26, 28-32 and 85-92 of the applicant’s specification and the applicant’s arguments dated September 5, 2025);
Promotion data of the emblem: describe parameters/properties of the emblem such as size, placement, and/or rotation of the emblem relative to the digital image of the item that are stored in a promotion dataset. (Based on at least paragraph 28, 81-84, and 93-94 of the applicant’s specification)
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-2, 6-7, 9-13, and 15-21 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s), as amended and based on the applicant’s arguments, contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
As to claims 1, 12, and 18, the specification does not describe the invention in sufficient detail to enable one of ordinary skill in the art to recognize that the inventor invented what is claimed. The test for sufficiency is whether the disclosure of the application relied upon reasonably conveys to those skilled in the art that the inventor had possession of the claimed subject matter as of the filing date. Claim 1, 12, and 18 recite: “generating, by the computing device, a promotion emblem image including one or more graphical promotion data fields and one or more embedded encoding elements configured to target data and populate the one or more graphical promotion data fields with information from the targeted data when processed” and “populating, by the computing device, the one or more graphical promotion data fields with information from the promotion data of the item through processing the one or more embedded encoding elements”; “generating, by the computing device, a promotion emblem image including one or more graphical promotion data fields and one or more embedded encoding elements configured to target data and populate the one or more graphical promotion data fields with information from the targeted data when processed” and “processing, by the computing device, the one or more embedded encoding elements to populate the one or more graphical promotion data fields with information from the promotion data”; and “generating a promotion emblem image including one or more graphical promotion data fields and one or more embedded encoding elements configured to target data and populate the one or more graphical promotion data fields with information from the targeted data when processed” and “populating the one of more graphical promotion data fields with information from the promotion data of the item through processing the one or more embedded encoding elements”, respectively. Based on the applicant’s disclosure in at least paragraphs 3, 25, 40, and 68, as well as, figures 3-5, the promotion emblem is a graphic emblem with a graphical promotion data field. Thus, the scope of the invention presented in the independent claims is broad enough to encompass any type of executable encoding embedded within a graphical promotion emblem that is capable of populating any text-based promotion data in any type of graphical promotion data field. However, the specification does not describe in sufficient species of executable encoding embedded within a graphical promotion emblem that is capable of populating text-based promotion data in a graphical promotion data field, to prove that the applicant has support for the claimed genus. A description that merely renders the invention obvious does not satisfy the requirement, Lockwood v. Am. Airlines, 107 F.3d 1565, 1571-72 (Fed. Cir. 1997). The claims are a genus claim using functional language that claim an expected result and are directed towards executing code embedded within a graphical promotional emblem to populate a graphical promotion data field with text-based promotion data. While the applicant appears to have support for the functionality of genus and the claimed result, the requirements of MPEP 2106.01 require that the specification must demonstrate that the applicant has made a generic invention that achieves the claimed result and do so by showing that the applicant has invented species sufficient to support a claim to the functionally-defined genus. In the instant case, the applicant’s disclosure supports only a single species of executing code embedded within a graphical promotional emblem to populate a graphical promotion data field with text-based promotion data. In paragraphs 43 and 86 of the applicant’s disclosure the applicant is disclosing a single species in which an SVG (Scalable Vector Graphics) promotional emblem has embedded within the SVG code, a JavaScript code function that includes a JSON (JavaScript Object Notation) object, which when executed populates the text-based promotion data into a graphical promotion data field of the SVG promotional emblem. These two paragraphs, when read together are the only support, in the applicant’s specification, for generating a promotion emblem image including one or more graphical promotion data fields and one or more embedded encoding elements and then executing the code embedded within a graphical promotional emblem to populate a graphical promotion data field with text-based promotion data. One of ordinary skill in the art would realize that the only type of graphical promotional emblems that contain embedded code that is executable to generate a graphical promotional emblem are vector graphics. The most common type of vector graphics are SVG files, EPS (Encapsulated PostScript) file, WMF (Windows Metafile) files, EMF (Enhanced Metafiles) files, EMF+ (Enhanced Metafiles +) files, PDF (Portable Document Format) files, CDR (CorelDRAW) files, and AI (Adobe Illustrator) files. Each of which have different restrictions and requirements regarding the code embedded therein. The only type of vector graphics with code embedded therein which is mentioned in the applicant’s disclosure is SVG which is mentioned in paragraphs 43, 68, 72, and 116. Thus, the applicant’s specification does not have enough species of graphical promotion emblems with instructions embedded there in to prove the applicant had possession of any type of graphical promotion emblems with instructions embedded therein. Additionally, the applicant’s specification has only one example of code embedded in a graphical promotion emblem that is capable of being executed to populate a graphical promotion data field with text-based promotion data which is found in paragraph 86 which states: “As one example, the discount remote retrieval encoding 400 is configured as a JavaScript function including the JSON object, and once processed (e.g., executed), the function causes the emblem processing module 204 to generate a processed discount data retrieval request 402”. As previously indicated each type of vector graphic has different restrictions and requirements with regard to the actual coding and type of executable code that can be within each type of vector graphic. For example, one or ordinary skill in the art would realize that an SVG promotional emblem, for which the applicant’s specification does have support, is not capable of directly importing text-based from a promotion dataset into a graphical promotion data field of the SVG promotional emblem. SVGs are made up of vector graphics rather than merely pixels like traditional graphics. SVG files are XML (Extensible Markup Language) files, which means they contain markup tags that define the image and can be executed to display the image in the manner in which the embedded code defines. While some of the tags in an SVG file can import images from external sources such as the <image> tag, the <text> tag and its dependent tags such as <textPath>, and/or <tspan> do not allow for text to be dynamically imported from said external sources. If the text is not hardcoded into the coding of the SVG itself, the <text> tag can usually only access such from data another source within the same namespace that the SVG resides in when it is displayed. In these cases, in order to implement dynamic text population, a web document such as HTML page within the same namespace can include for example JavaScript code that can import the text and assign the text to an object which can then be accessed the encoding within the SVG file. For example, one could create a JSON structure that defines the shapes and texts to be drawn; then load the JSON data using JavaScipt on a webpage by setting const jsonData = JSON.parse(jsonString); then generate the SVG elements by iterating through the JSON data to dynamically create the corresponding SVG by using JavaScript and DOM manipulation or perhaps using JavaScript on a web page to assign text strings to variable by accessing a templating defining text. In these cases, the code in the SVG file would include the variable name which is then used to access the variable from the JavaScript code that is in on the webpage in which the SVG resides (i.e., same namespace) then including the variable name in the code of the SVG. It would also be possible to use the <foreignObject> to import text from other XML namespaces. However, any dynamic text would need to be imported and then converted into an object in the namespace using JavaScript before it could be populated using the <foreignObject> tag. Note, in all of the above cases, the additional JavaScript and JSON code is outside the code embedded in the SVG. As such, most other ways for dynamically inserting text-based promotion data into a graphical promotion data field requires code external to the SVG but residing in the same namespace to access the promotion data and convert it into a variable, wherein the SVG code embedded in the graphical promotional emblem is executed to obtain the current value of the variable. The only exception to this, for which the examiner whom has a master’s degree is computer science and engineering, is aware is to use an SVG <script> tag. The <script> tag allows one to embed code such as JavaScript code within and SVG file itself. While SVG does not allow one to embed a <script> tag directly inside <text> tag, it is possible to dynamically modify the text or other attributes originally assigned to the <text> tag, using JavaScript code within a separate <script> tag of the SVG file. This technique results in a portable SVG file that allows text-based promotion elements to be inserted into a graphical promotion data field because the JavaScript will always be within the same namespace as the SVG file because it is within the SVG file itself. Additionally, the applicant’s specification provides no indication of another manner in which code embedded in the SVG promotional emblem could be executed to dynamically populate text-based promotion data into a graphical promotion data field of the promotional emblem. Paragraph 43 of the applicant’s specification discloses that “Textual elements within the emblem string are updated to include the promotion parameters from the item promotion data”. This could mean opening the SVG in an editor and manually modifying the text. However, changing the SVG in this manner would not occur from executing the code in the SVG. Paragraph 43 further discloses “Update of the textual elements includes, in some instances, processing encoding of the emblem (e.g., encoding within the emblem string) to retrieve the promotion parameters and to embed the promotion data within the emblem, e.g., replace the processed encoding with the promotion parameters.” This might mean using the code within the SVG to directly access the text data in the promotional dataset or it could mean that code external to the SVG is executed to obtain the promotional data from the dataset and assigning the obtained data to variables that when accessed by executing the code in the SVG results in a promotional emblem that displays the promotional data within the emblem. Thus, it might be said to support the claimed embodiment, but does not describe how the invention can do such a thing, given that such text-based promotional data cannot be directly imported via code within the SVG using traditional SVG code limitations. Paragraph 43 further states “In some implementations, update of the textual elements utilizes JavaScript Object Notation (JSON), and in some implementations, the emblem is configurable as a scalable vector graphic (SVG) image, where the string is defined according to an SVG image encoding structure.”. However, JSON itself is a data interchange format, not a programming or drawing language, so it cannot "draw" an emblem directly. It can, however, be used to store the data or instructions that a separate program (written in a language like JavaScript, Python, or C++) then interprets to render the emblem using a graphics library (like HTML Canvas, SVG, or OpenGL). Thus, JSON can access the promotion data in the promotion dataset, so that text is capable of being updated in the SVG. However, the JSON format must be executed by a program in the namespace of the SVG to interpret the text data in the JSON data structure and assign the data to variables that match the variables used in the code within the SVG. Thus, the JavaScript, in the same namespace as the SVG, could assign each piece of text in the JSON to a variable, and if the SVG image encoding structure had a reference to said variable, the SVG emblem could dynamically disclose the text assigned to the variable by the JavaScript program that resides in the same namespace as the SVG emblem. However, in this case the code embedded in the SVG promotional emblem is not accessing the promotional data, it is accessing the current variable assigned by the program executing in the same namespace as the SVG file. The remainder of paragraph 43 describes promotional data of the emblem itself such as text path and color. Thus, they are irrelevant with regards to promotion data of the item. Paragraph 86 of the applicant’s specification discloses a discount remote retrieval encoding stored within the promotion emblem, wherein the discount retrieval encoding is formatted to include a JSON object targeting or directed toward promotion discount data included within the item promotion data, wherein the discount data could be text. Once again, directly importing text-based data into an SVG is not supported by the current SVG standard. Additionally, JSON is not a programming language but a data interchange format. Thus, it is possible the applicant is claiming that there is a JSON data structure on a web page, the claimed computer directly modifies this data structure based on promotion data in the dataset. However, in this case the code embedded in the SVG would be accessing the data in the modified JSON file and not accessing the promotion data. Additionally, embedding JSON directly within an SVG is not a standard practice for data storage or manipulation, as SVG is an XML-based image format and JSON is a data interchange format. Thus, one of ordinary skill in the art would interpret this disclosure as the by the promotion emblem including variables that are targeted to current variables in a JSON object stored in the same namespace or targeted to current variable in a JavaScript program executing in the same namespace that obtained said current variable from a JSON object. Thus, it would not appear to be disclosing that the code embedded in the graphical promotion emblem includes a JSON object. While, it might be possible, to include a JSON object in an SVG file, a JSON object does not execute to update data in the JSON object and there is no command within SVG for executing an JSON object to update. The closest operation would be to use the <script> tag to encode a script of code that is executed to update the JSON object which is the only species in the applicant’s specification as indicated in the next disclosure of Paragraph 86 which states: “As one example, the discount remote retrieval encoding 400 is configured as a JavaScript function including the JSON object, and once processed (e.g., executed), the function causes the emblem processing module 204 to generate a processed discount data retrieval request 402”. Paragraph 89 discloses using this same process for obtaining a second piece of text-based promotion data for inclusion in the graphical promotion emblem. As such, it is clear, that the applicant’s specification supports only a single species of code embedded in an SVG promotional emblem that is executable to replace a graphical promotion data field with the promotional data. In order to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor had possession of the claimed invention the applicant’s disclosure would need to disclose additional species of code encoded in the graphical promotion emblem of other types of vector graphics dynamically changing/replacing a graphical promotion data field with text-based promotion data and/or other ways in which code embedded within an SVG promotion emblem can be used to dynamically changing/replacing a graphical promotion data field with text-based promotion data. This is especially true given that each vector graphic has different coding requirements and restrictions and that any other manner of doing so with regards to an SVG promotion emblem would appear to be contrary to current SVG coding requirements and restrictions.
Without specific examples in the specification of how this step is performed for other vector graphic based promotional emblems and/or other ways in which it is possible to do with a SVG promotional emblem, it is impossible to conclude that the applicant has invented a sufficient number of species support a claim that the applicant had possession of the functionally-defined genus. As per the “Supplementary Examination Guidelines for Determining Compliance with 35 U.S.C. and for Treatment of Related Issues in Patent Applications” issued on January 21, 2011 and MPEP 2161.01, the first paragraph of § 112 contains a written description requirement that is separate and distinct from the enablement requirement. To satisfy the written description requirement, the specification must describe the claimed invention in sufficient detail that one skilled in the art can reasonably conclude that the inventor had possession of the claimed invention. Specifically, the specification must describe the claimed invention in a manner understandable to a person of ordinary skill in the art and show that the inventor actually invented the claimed invention. The written description requirement of § 112, ¶ 1 applies to all claims including original claims that are part of the disclosure as filed. Claims may fail to satisfy the written description requirement when the invention is claimed and described in functional language but the specification does not sufficiently identify how the invention achieves the claimed function. The problem is especially acute with genus claims that use functional language to define the boundaries of a claimed genus. In such a case, the functional claim may simply claim a desired result, and may do so without describing species that achieve that result. But the specification must demonstrate that the applicant has made a generic invention that achieves the claimed result and do so by showing that the applicant has invented species sufficient to support a claim to the functionally-defined genus. The level of detail required to satisfy the written description requirement varies depending on the nature and scope of the claims and on the complexity and predictability of the relevant technology. Computer-implemented inventions are often disclosed and claimed in terms of their functionality. This is because writing computer programming code for software to perform specific functions is normally within the skill of the art once those functions have been adequately disclosed. Nevertheless, for computer-implemented inventions, the determination of the sufficiency of disclosure will require an inquiry into both the sufficiency of the disclosed hardware as well as the disclosed software due to the interrelationship and interdependence of computer hardware and software. When examining computer-implemented functional claims, examiners should determine whether the specification discloses the computer and the algorithm (e.g., the necessary steps and/or flowcharts) that perform the claimed function in sufficient detail such that one of ordinary skill in the art can reasonably conclude that the inventor invented the claimed subject matter. Specifically, if one skilled in the art would know how to program the disclosed computer to perform the necessary steps described in the specification to achieve the claimed function and the inventor was in possession of that knowledge, the written description requirement would be satisfied. If the specification does not provide a disclosure of the computer and algorithm in sufficient detail to demonstrate to one of ordinary skill in the art that the inventor possessed the invention including how to program the disclosed computer to perform the claimed function, a rejection under § 112, ¶ 1 for lack of written description must be made. In the instant case, the claimed invention fails to satisfy the written description requirement because the invention is a genus claim and described in functional language but the specification does not sufficiently identify how the invention achieves the claimed function because genus claims that use functional language to define the boundaries of a claimed genus. The claims simply claim a desired result, and does so without describing species that achieve that result. There is no indication in the specification that demonstrates that the applicant invented species sufficient to support a claim to the functionally-defined genus.
As detail above, the specification provides no showing that the applicant has invented species sufficient to support a claim to the functionally-defined genus. There are no specific examples of how the claimed genus described using functional language would be used to obtain the desired result given a single species. There are no algorithms or flow charts that describe the specific details necessary for implementation of the claimed invention using a single species of the claimed genus. Hence, it is clear that the specification fails to satisfy the written description because it does not sufficiently identify how the invention achieves the claimed functions. An adequate written description of a claimed genus requires more than the generic statement of the inventions boundaries as presented in the applicant’s disclosure.
Dependent claims 2, 6-7, 9-11, 13, 15-17 and 19-21 fail to correct the deficiencies of the claims from which they depend and, as such, are rejected by virtue of dependency.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-2, 4-7, 9-13, 15-21, and 24-25 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Independent claims 1, 12, and 18 recite: “generating…a promotion emblem image including one or more graphical promotion data fields and one or more embedded encoding elements configured to target data and populate the one or more graphical promotion data fields with information from the targeted data when processed”. Independent claims 1, 12, and 18 also recite “identifying…promotion data of the item from a promotion dataset” and “populating the one or more graphical promotion data fields with information from the promotion data of the item through processing the one or more embedded encoding elements”.
It is clear, from the first identified limitation in claim 1, 12, and 18, that the promotional emblem image has a graphical promotion data field and an embedded encoding element. This embedded encoding element is configured to “target data” and populate the graphical promotion data field with information from the “targeted data” when processed. However, based on the second identified limitation in claims 1, 12, and 18, the processing of the one or more graphical promotion element neither performs the step of “target data” not the step of “populate the one or more graphical promotion data fields with information from the targeted data”. Instead, it appears to merely populate the one or more graphical promotion data fields with information from the promotion data of the item.
First, neither the “promotion data of the item” nor the “information from the promotion data of the item” has antecedent basis to the previously claimed “target data” nor the previously claimed “information from the targeted data”. As such, one of ordinary skill in the art would not be able to determine how the applicant’s invention is intended to “one of ordinary skill in the art would not be able to determine how the applicant’s invention “populate the one or more graphical promotion data fields with information from the promotion data of the item” when the one or more embedded encoding elements is processed. How does the invention determine that an information from the promotion data of the item is information from the targeted data, so that such information can be populated?
Second, even if one were to assume that the promotion data of the item was intended to be interpreted as the previously claimed “target data”, and that the information from the promotion data of the item is intended to be interpreted as the previously claimed “information from the targeted data”, the claim would still be indefinite. According to the first identified limitation the embedded encoding element is configured to target data. However, according to the second identified limitations the embedded encoding element does not perform a task comprising target data. Instead, the computing device identifies promotion data of the item (i.e., target data) from a promotion dataset. The processing of the embedded encoding element in the second limitation only appears to perform the step of populating the one or more graphical promotion data fields with information from the promotion data of the item (i.e., information from the targeted data). As such, it would appear from the second identified limitations that the computer system is configured to “target data” prior to the processing of the embedded encoding element instead of the processing of the embedded encoding element being configured to “target data” as required by the first identified limitation. Given this incongruity, one of ordinary skill in the art would not be able to determine the intended metes and bounds of the applicant’s invention. Therefore, it is clear that independent claims 1, 12, and 18 are indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor, or a joint inventor, regards as the invention.
Dependent claims 2, 4-7, 9-11, 13, 15-17, 19-21, and 24-25 fail to correct the deficiencies of the claims from which they depend and, as such, are rejected by virtue of dependency.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-2, 4-7, 9-11, and 21 are directed to a method which would be classified under one of the listed statutory classifications (i.e., 2019 Revised Patent Subject Matter Eligibility Guidance (hereinafter “PEG”) “PEG” Step 1=Yes).
However, claims 1-2, 4-7, 9-11, and 21 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. Claim(s) 1, 4-5, and 11 recite(s) the following abstract idea:
generating a promotional emblem image including one or more graphical promotion data fields and one or more embedded encoding elements configured to target data and populate the one or more graphical promotion data fields with information form the targeted data when processed, wherein the promotion emblem image is a scalable vector graphic (SVG) image defined by an image encoding structure, and the one or more embedded encoding elements include one or more JavaScript Object Notation (JSON) object embedded within the image encoding structure, wherein the one or more JSON objects includes a promotion date object and a promotion discount object;
receiving a digital image of an item;
receiving a user selection of the promotional emblem image; and
responsive to receiving the user selection of the promotional emblem image:
identifying promotion data of the item from a promotion dataset;
populating the one or more graphical promotion data fields with information from the promotion data of the item through processing the one or more embedded encoding elements;
forming a combined image by combining the promotional emblem image including the one or more graphical promotion data fields populated with the information from the promotion data of the item with the digital image in an overlapping arrangement non-destructive to the digital image; and
outputting the combined image for display, wherein outputting the combined image for display includes replacing the digital image in a listing of the item displayed with the combined image.
The limitations as detailed above, as drafted, falls within the “Certain Method of Organizing Human Activity” grouping of abstract ideas namely commercial or legal interactions because they recite advertising, marketing and sales activities or behaviors. Accordingly, the claim recites an abstract idea (i.e. “PEG” Revised Step 2A Prong One=Yes).
This judicial exception is not integrated into a practical application because the claim only recites the additional elements of:
a computing device (e.g., general-purpose computer);
a graphical user interface for providing information to an accepting user input (e.g., a generic computer element as per the Intellectual Ventures I v. Capital One decision); and
generating a dynamic SVG with an embedded encoding element within a data field, wherein the embedded encoding element includes a JavaScript Object Notation (JSON) object (e.g., a generic computer component as it is a traditional way in which dynamic SVGs tags are intended to operate).
When analyzing these additional elements, both individually and as a whole, the main question that needs to be answered is whether the dynamic SVG being claimed is a technical element of the claim which results in an improvement to a traditional SVG capable of transforming the abstract idea into a practical application under Step 2a, Prong 2. The applicant’s disclosure in figures 4-5 and paragraphs 85-98 describe how the invention dynamically updates the SVG using a JavaScript function including the JSON object. However, these sections of the applicant’s disclosure do not describe any problems encountered when including a JavaScript function with a JSON object within an SVG, nor any technical solutions for overcoming such problems. Furthermore, the applicant’s disclosure provides no specific information regarding how one of ordinary skill in the art would need to implement such an SVG. The closest thing to a specific technical implementation is found in figure 5. In figure 5, short snippets of barely legible code for implementing such an SVG are disclosed. Item 500 includes standard SVG shape encoding. Item 502 is SVG text encoding including the standard tspan tag. Within the first standard tspan tag in figure 5 the applicant has included item 406 and within the second standard tspan tag the applicant has included item 400. Based on paragraphs 86 and 89, item 400 and 406 are respective JavaScript functions that include respective JSON objects. There is no disclosure in the applicant’s disclosure of the specific JavaScript function itself nor the creation or structure of the JSON object. There is no disclosure regarding whether the JavaScript function is within the SVG file using the standard <script>…</script> tags or located external to the SVG file. Instead, the applicant merely assumes that one of ordinary skill in the art would already know how incorporate remote retrieval encoding with the SVG using JavaScript functions that includes JSON object. This weighs heavily against the generating of the dynamic SVG being a new type of SVG that the applicant has invented. Next, the examiner considered the significance of a JavaScript function that includes a JSON object. As disclosed in W3schools, JavaScript JSON Reference, January 19, 2023, https://web. archive.org/ web/20230119215806/https://www.w3schools.com/jsref/jsref_obj_json.asp, pages 1-6, which discloses on page 1 that JSON is merely a format for storing and transporting data. JSON is text, and can be transported anywhere, and read by any programming language. JavaScript Objects can be converted to JSON, and JSON can be converted back to JavaScript Object. Thus, it would not appear that a JavaScript function with a JSON object would be a technical improvement of any kind. Next, the examiner considered whether it is unusual to including JavaScript within an SVG file. Based on W3C, An SVG Primer for Today’s Browser’s, September 2010, https:// www.w3.org/Graphics/SVG/IG/resources/svgprimer.html#SMIL_animations, pages 1-165, which discloses on at least pages 56-57 and 71-77 that including JavaScript in an SVG was standard by at least 2010 by using the standard <script> tag. Next, the examiner considered whether it was unusual for JavaScript in an SVG to access a JSON object. Based on Oreillymedia, Using SVG with CSS3 and HTML5 – Supplementary Material, July 6, 2022, https://web.archive.org/web/20220706014901/ https://oreillymedia.github.io/Using_SVG/guide/markup.html#integration, pages 1-56, which discloses on pages 22-24 that SVG is designed to work with CSS, JavaScript, HTML, and other XML languages. The following SVG elements are used to integrate code from those languages in your SVG markup: <script> element can be used to include JSON data in the markup without parsing it, so that another script can access it by reading this element’s text content using type="text/json". Thus, based on these three references, generating a dynamic SVG with an embedded encoding element within a data field, wherein the embedded encoding element includes a JavaScript Object Notation (JSON) object appears to be a normal way in which SVG markup language is intended to operate. SVG is an XML-based vector graphic format that utilizes standardized tags, much like tags in an HTML document, to generate a graphic. These tags appear to already include the functionality for generating a dynamic SVG with an embedded encoding element within a data field, wherein the embedded encoding element includes a JavaScript Object Notation (JSON) object. Thus, every factor considered from the applicant’s disclosure, as well as, the traditional functionalities of SVG tags weighs against this being a technical improvement and instead provides a clear indication that standard SVG functionality is merely being used as a tool to implement the abstract idea.
As such, the additional element of a computing device with a computer-readable storage media (e.g., a general-purpose computer with a generic computer component), a graphical user interface for providing information to an accepting user input (e.g., a generic computer element as per the Intellectual Ventures I v. Capital One decision), and generating a dynamic SVG with an embedded encoding element within a data field, wherein the embedded encoding element includes a JavaScript Object Notation (JSON) object, whether considered individually or as a whole, amount to using a general-purpose computer with generic computer components as tools to merely implement the abstract idea.
The following limitations, if removed from the abstract idea and considered additional elements, merely perform generic computer function of processing, storing, communicating (e.g., transmitting and receiving), and displaying data and, as such, are insignificant extra-solution activities (see MPEP 2016.05(d)(II) and MPEP 2106.05(g)):
receiving, by the computing device, a digital image of an item (receiving data);
receiving, by the computing device via a graphical user interface (GUI) implemented by the computing device, a user selection of the promotional emblem including a graphical promotion data field (receiving data); and
outputting, by the computing device, the combined image for display in the GUI, wherein outputting the combined image for display includes replacing the digital image in a listing of the item displayed with the combined image (transmitting data).
The additional technical elements above are recited at a high-level of generality (i.e., as a generic processor and generic computer components performing a generic computers function of processing, communicating and displaying) such that it amounts to no more than mere instructions to apply the exception using one or more general-purpose computers and generic computer components. The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional technical elements above do not integrate the abstract idea/judicial exception into a practical application because it does not impose any meaningful limits on practicing the abstract idea. More specifically, the additional elements fail to include (1) improvements to the functioning of a computer or to any other technology or technical field (see MPEP 2106.05(a)), (2) applying or using a judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition (see Vanda memo), (3) applying the judicial exception with, or by use of, a particular machine (see MPEP 2106.05(b)), (4) effecting a transformation or reduction of a particular article to a different state or thing (see MPEP 2106.05(c)), or (5) applying or using the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the exception (see MPEP 2106.05(e) and Vanda memo).
Rather, the limitations merely add the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on one or more computers, or merely uses computers as a tool to perform an abstract idea (see MPEP 2106.05(f)), or generally link the use of the judicial exception to a particular technological environment or field of use (see MPEP 2106.05(h)).
Thus, the claim is “directed to” an abstract idea (i.e. “PEG” Revised Step 2A Prong Two=Yes)
When considering Step 2B of the Alice/Mayo test, the claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the claims do not amount to significantly more than the abstract idea.
More specifically, as discussed above with respect to integration of the abstract idea into a practical application, the additional elements of using a computing device, a graphical user interface, and generating a dynamic SVG with an embedded encoding element within a data field, wherein the embedded encoding element includes a JavaScript Object Notation (JSON) object (e.g. a general-purpose computer with generic computer components) to perform the claimed functions amounts to no more than mere instructions to apply the exception using one or more general-purpose computers and one or more generic computer component as a tool.
“Generic computer implementation” is insufficient to transform a patent-ineligible abstract idea into a patent-eligible invention (See Affinity Labs, _F.3d_, 120 U.S.P.Q.2d 1201 (Fed. Cir. 2016), citing Alice, 134 S. Ct. at 2352, 2357) and more generally, “simply appending conventional steps specified at a high level of generality” to an abstract idea does not make that idea patentable (See Affinity Labs, _F.3d_, 120 U.S.P.Q.2d 1201 (Fed. Cir. 2016), citing Mayo, 132 S. Ct. at 1300). Moreover, “the use of generic computer elements like a microprocessor or user interface do not alone transform an otherwise abstract idea into patent-eligible subject matter (See FairWarning, 120 U.S.P.Q.2d. 1293, citing DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245, 1256 (Fed. Cir. 2014)). As such, the additional elements of the claim do not add a meaningful limitation to the abstract idea because they would be generic computer functions in any computer implementation. Thus, taken alone, the additional elements do not amount to significantly more than the above-identified judicial exception (the abstract idea). Looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of the computer or improves any other technology. Their collective functions merely provide generic computer implementation.
The Examiner notes simply implementing an abstract concept on one or more computers, without meaningful limitations to that concept, does not transform a patent-ineligible claim into a patent-eligible one (See Accenture, 728 F.3d 1336, 108 U.S.P.Q.2d 1173 (Fed. Cir. 2013), citing Bancorp, 687 F.3d at 1280), limiting the application of an abstract idea to one field of use does not necessarily guard against preempting all uses of the abstract idea (See Accenture, 728 F.3d 1336, 108 U.S.P.Q.2d 1173 (Fed. Cir. 2013), citing Bilski, 130 S. Ct. at 3231), and further the prohibition against patenting an abstract principle “cannot be circumvented by attempting to limit the use of the [principle] to a particular technological environment” (See Accenture, 728 F.3d 1336, 108 U.S.P.Q.2d 1173 (Fed. Cir. 2013), citing Flook, 437 U.S. at 584), and finally merely limiting the field of use of the abstract idea to a particular existing technological environment does not render the claims any less abstract (See Affinity Labs, _F.3d_, 120 U.S.P.Q.2d 1201 (Fed. Cir. 2016), citing Alice, 134 S. Ct. at 2358; Mayo, 132 S. Ct. at 1294; Bilski v. Kappos, 561 U.S. 593, 612 (2010); Content Extraction & Transmission LLC v. Wells Fargo Bank, Nat’l Ass’n, 776 F.3d 1343, 1348 (Fed. Cir. 2014); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355 (Fed. Cir. 2014).
Applicant herein only requires one or more general-purpose computer and generic computer components (as evidenced from figures 1 and 10, as well as, paragraphs 35 and 127-134 of the applicant’s specification which discloses that the computing device is a general-purpose computer with generic computer components; the Intellectual Ventures I v. Capital One decision which found that a generic interactive interface that provides information to and accepts user input is a generic computer element; the prior arts of Zorzi et al. (PGPUB: 2023/0146018 – paragraph 37 and claim 5) and Uzgin et al. (PGPUB: 2019/0043231 – paragraphs 43 and 87), which both disclose that, prior to the effective filing date of the instant invention standard vector formats for vector files include one or more of SVG and JSON formats; and W3schools, JavaScript JSON Reference, January 19, 2023, https://web. archive.org/ web/20230119215806/https://www.w3schools.com/jsref/jsref_obj_json.asp, pages 1-6; W3C, An SVG Primer for Today’s Browser’s, September 2010, https:// www.w3.org/Graphics/SVG/IG/resources/svgprimer.html#SMIL_animations, pages 1-165; and Oreillymedia, Using SVG with CSS3 and HTML5 – Supplementary Material, July 6, 2022, https://web.archive.org/web/20220706014901/ https://oreillymedia.github.io/Using_SVG/guide/markup.html#integration, pages 1-56, which are all used to disclose that SVG tags that include JavaScript for accessing JSON objects were well-known prior to the effective filing data of the applicant’s invention); therefore, there does not appear to be any alteration or modification to the generic activities indicated, and they are also therefore recognized as insignificant activity with respect to eligibility. Finally, the following limitations, if removed from the abstract idea and considered additional elements, would be considered insignificant extra solution activity as they are directed to merely receiving, displaying, storing, and/or transmitting data (see MPEP 2016.05(d)(II) and MPEP 2106.05(g)):
receiving, by the computing device, a digital image of an item (receiving data);
receiving, by the computing device via a graphical user interface (GUI) implemented by the computing device, a user selection of the promotional emblem including a graphical promotion data field (receiving data); and
outputting, by the computing device, the combined image for display in the GUI, wherein outputting the combined image for display includes replacing the digital image in a listing of the item displayed with the combined image (transmitting data).
Thus, taken individually and in combination, the additional elements do not amount to significantly more than the above-identified judicial exception (the abstract idea) (i.e., “PEG” Step 2B=No).
The dependent claims 2, 6-7, 9-10, and 21 appear to merely further limit the abstract idea by further limiting the processing of the one or more embedded encoding elements by replacing the one or more embedded encoding elements with the information from the promotion data which is considered part of the abstract idea (Claim 2); further limiting the generating of the combined image which is considered part of the abstract idea (Claims 6); adding an additional step of layering the promotion emblem in the overlapping arrangement which is considered part of the abstract idea (Claim 7); further limiting the information from the promotion data to include a promotion start date, a promotion end date, and a promotion discount which is considered part of the abstract idea (Claim 9); adding an additional step of flattening the combined image which is considered part of the abstract idea (Claim 10); and adding an additional step of updating the appearance of the promotion emblem image which is considered part of the abstract idea (Claim 21), and therefore only further limit the abstract idea (i.e. “PEG” Revised Step 2A Prong One=Yes), does/do not include any new additional elements that are sufficient to amount to significantly more than the judicial exception, and as such are “directed to” said abstract idea (i.e. “PEG” Step 2A Prong Two=Yes); and do not add significantly more than the idea (i.e. “PEG” Step 2B=No).
Thus, based on the detailed analysis above, claims 1-2, 4-7, 9-11, and 21 are not patent eligible.
Claims 18-20, and 25 are directed to methods and a system which would be classified under one of the listed statutory classifications (i.e., 2019 Revised Patent Subject Matter Eligibility Guidance (hereinafter “PEG”) “PEG” Step 1=Yes).
However, claims 18-20, and 25 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. Claim(s) 18, 20 and 25 recite(s) the following abstract idea:
generating a promotional emblem image including one or more graphical promotion data fields and one or more embedded encoding elements configured to target data and populate the one or more graphical promotion data fields with information form the targeted data when processed, wherein the promotion emblem image is encoded as a scalable vector graphic (SVG) image defined by an image encoding structure, and the one or more embedded encoding elements include one or more JavaScript Object Notation (JSON) object embedded within the image encoding structure;
receiving a digital image of an item;
receiving a user selection of the promotional emblem image; and
responsive to receiving the user selection of the promotional emblem image:
identifying promotion data of the item from a promotion dataset;
populating the one or more graphical promotion data fields with information from the promotion data of the item through processing the one or more embedded encoding elements, wherein processing the one or more embedded encoding elements replaces information in the one or more graphical promotion data fields with the information from the promotion data;
forming a combined image by combining the promotional emblem image including the one or more graphical promotion data fields populated with the information from the promotion data of the item with the digital image, wherein forming the combined image alters a pixel content of the digital image responsive to a condition being satisfied and does not alter the pixel content of the digital image responsive to the condition not being satisfied; and
outputting the combined image for display.
The limitations as detailed above, as drafted, falls within the “Certain Method of Organizing Human Activity” grouping of abstract ideas namely commercial or legal interactions because they recite advertising, marketing and sales activities or behaviors. Accordingly, the claim recites an abstract idea (i.e. “PEG” Revised Step 2A Prong One=Yes).
This judicial exception is not integrated into a practical application because the claim only recites the additional elements of:
a computing device with a computer-readable storage media (e.g., a general-purpose computer with a generic computer component);
a graphical user interface for providing information to an accepting user input (e.g., a generic computer element as per the Intellectual Ventures I v. Capital One decision); and
generating a dynamic SVG with an embedded encoding element within a data field, wherein the embedded encoding element includes a JavaScript Object Notation (JSON) object (e.g., a generic computer component as it is a traditional way in which dynamic SVGs tags are intended to operate).
When analyzing these additional elements, both individually and as a whole, the main question that needs to be answered is whether the dynamic SVG being claimed is a technical element of the claim which results in an improvement to a traditional SVG capable of transforming the abstract idea into a practical application under Step 2a, Prong 2. The applicant’s disclosure in figures 4-5 and paragraphs 85-98 describe how the invention dynamically updates the SVG using a JavaScript function including the JSON object. However, these sections of the applicant’s disclosure do not describe any problems encountered when including a JavaScript function with a JSON object within an SVG, nor any technical solutions for overcoming such problems. Furthermore, the applicant’s disclosure provides no specific information regarding how one of ordinary skill in the art would need to implement such an SVG. The closest thing to a specific technical implementation is found in figure 5. In figure 5, short snippets of barely legible code for implementing such an SVG are disclosed. Item 500 includes standard SVG shape encoding. Item 502 is SVG text encoding including the standard tspan tag. Within the first standard tspan tag in figure 5 the applicant has included item 406 and within the second standard tspan tag the applicant has included item 400. Based on paragraphs 86 and 89, item 400 and 406 are respective JavaScript functions that include respective JSON objects. There is no disclosure in the applicant’s disclosure of the specific JavaScript function itself nor the creation or structure of the JSON object. There is no disclosure regarding whether the JavaScript function is within the SVG file using the standard <script>…</script> tags or located external to the SVG file. Instead, the applicant merely assumes that one of ordinary skill in the art would already know how incorporate remote retrieval encoding with the SVG using JavaScript functions that includes JSON object. This weighs heavily against the generating of the dynamic SVG being a new type of SVG that the applicant has invented. Next, the examiner considered the significance of a JavaScript function that includes a JSON object. As disclosed in W3schools, JavaScript JSON Reference, January 19, 2023, https://web. archive.org/ web/20230119215806/https://www.w3schools.com/jsref/jsref_obj_json.asp, pages 1-6, which discloses on page 1 that JSON is merely a format for storing and transporting data. JSON is text, and can be transported anywhere, and read by any programming language. JavaScript Objects can be converted to JSON, and JSON can be converted back to JavaScript Object. Thus, it would not appear that a JavaScript function with a JSON object would be a technical improvement of any kind. Next, the examiner considered whether it is unusual to including JavaScript within an SVG file. Based on W3C, An SVG Primer for Today’s Browser’s, September 2010, https:// www.w3.org/Graphics/SVG/IG/resources/svgprimer.html#SMIL_animations, pages 1-165, which discloses on at least pages 56-57 and 71-77 that including JavaScript in an SVG was standard by at least 2010 by using the standard <script> tag. Next, the examiner considered whether it was unusual for JavaScript in an SVG to access a JSON object. Based on Oreillymedia, Using SVG with CSS3 and HTML5 – Supplementary Material, July 6, 2022, https://web.archive.org/web/20220706014901/ https://oreillymedia.github.io/Using_SVG/guide/markup.html#integration, pages 1-56, which discloses on pages 22-24 that SVG is designed to work with CSS, JavaScript, HTML, and other XML languages. The following SVG elements are used to integrate code from those languages in your SVG markup: <script> element can be used to include JSON data in the markup without parsing it, so that another script can access it by reading this element’s text content using type="text/json". Thus, based on these three references, generating a dynamic SVG with an embedded encoding element within a data field, wherein the embedded encoding element includes a JavaScript Object Notation (JSON) object appears to be a normal way in which SVG markup language is intended to operate. SVG is an XML-based vector graphic format that utilizes standardized tags, much like tags in an HTML document, to generate a graphic. These tags appear to already include the functionality for generating a dynamic SVG with an embedded encoding element within a data field, wherein the embedded encoding element includes a JavaScript Object Notation (JSON) object. Thus, every factor considered from the applicant’s disclosure, as well as, the traditional functionalities of SVG tags weighs against this being a technical improvement and instead provides a clear indication that standard SVG functionality is merely being used as a tool to implement the abstract idea.
As such, the additional element of a computing device with a computer-readable storage media (e.g., a general-purpose computer with a generic computer component), a graphical user interface for providing information to an accepting user input (e.g., a generic computer element as per the Intellectual Ventures I v. Capital One decision), and generating a dynamic SVG with an embedded encoding element within a data field, wherein the embedded encoding element includes a JavaScript Object Notation (JSON) object, whether considered individually or as a whole, amount to using a general-purpose computer with generic computer components as tools to merely implement the abstract idea.
The following limitations, if removed from the abstract idea and considered additional elements, merely perform generic computer function of processing, storing, communicating (e.g., transmitting and receiving), and displaying data and, as such, are insignificant extra-solution activities (see MPEP 2016.05(d)(II) and MPEP 2106.05(g)):
receiving a digital image of an item (receiving data);
receiving, via a graphical user interface (GUI), a user selection of the promotional emblem image (receiving data); and
outputting the combined image for display in the GUI (transmitting data).
The additional technical elements above are recited at a high-level of generality (i.e., as a generic processor and generic computer components performing a generic computers function of processing, communicating and displaying) such that it amounts to no more than mere instructions to apply the exception using one or more general-purpose computers and generic computer components. The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional technical elements above do not integrate the abstract idea/judicial exception into a practical application because it does not impose any meaningful limits on practicing the abstract idea. More specifically, the additional elements fail to include (1) improvements to the functioning of a computer or to any other technology or technical field (see MPEP 2106.05(a)), (2) applying or using a judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition (see Vanda memo), (3) applying the judicial exception with, or by use of, a particular machine (see MPEP 2106.05(b)), (4) effecting a transformation or reduction of a particular article to a different state or thing (see MPEP 2106.05(c)), or (5) applying or using the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the exception (see MPEP 2106.05(e) and Vanda memo).
Rather, the limitations merely add the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on one or more computers, or merely uses computers as a tool to perform an abstract idea (see MPEP 2106.05(f)), or generally link the use of the judicial exception to a particular technological environment or field of use (see MPEP 2106.05(h)).
Thus, the claim is “directed to” an abstract idea (i.e. “PEG” Revised Step 2A Prong Two=Yes)
When considering Step 2B of the Alice/Mayo test, the claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the claims do not amount to significantly more than the abstract idea.
More specifically, as discussed above with respect to integration of the abstract idea into a practical application, the additional elements of using a computing device with a memory, a graphical user interface, and generating a dynamic SVG with an embedded encoding element within a data field, wherein the embedded encoding element includes a JavaScript Object Notation (JSON) object (e.g. a general-purpose computer with generic computer components) to perform the claimed functions amounts to no more than mere instructions to apply the exception using one or more general-purpose computers and one or more generic computer component.
“Generic computer implementation” is insufficient to transform a patent-ineligible abstract idea into a patent-eligible invention (See Affinity Labs, _F.3d_, 120 U.S.P.Q.2d 1201 (Fed. Cir. 2016), citing Alice, 134 S. Ct. at 2352, 2357) and more generally, “simply appending conventional steps specified at a high level of generality” to an abstract idea does not make that idea patentable (See Affinity Labs, _F.3d_, 120 U.S.P.Q.2d 1201 (Fed. Cir. 2016), citing Mayo, 132 S. Ct. at 1300). Moreover, “the use of generic computer elements like a microprocessor or user interface do not alone transform an otherwise abstract idea into patent-eligible subject matter (See FairWarning, 120 U.S.P.Q.2d. 1293, citing DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245, 1256 (Fed. Cir. 2014)). As such, the additional elements of the claim do not add a meaningful limitation to the abstract idea because they would be generic computer functions in any computer implementation. Thus, taken alone, the additional elements do not amount to significantly more than the above-identified judicial exception (the abstract idea). Looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of the computer or improves any other technology. Their collective functions merely provide generic computer implementation.
The Examiner notes simply implementing an abstract concept on one or more computers, without meaningful limitations to that concept, does not transform a patent-ineligible claim into a patent-eligible one (See Accenture, 728 F.3d 1336, 108 U.S.P.Q.2d 1173 (Fed. Cir. 2013), citing Bancorp, 687 F.3d at 1280), limiting the application of an abstract idea to one field of use does not necessarily guard against preempting all uses of the abstract idea (See Accenture, 728 F.3d 1336, 108 U.S.P.Q.2d 1173 (Fed. Cir. 2013), citing Bilski, 130 S. Ct. at 3231), and further the prohibition against patenting an abstract principle “cannot be circumvented by attempting to limit the use of the [principle] to a particular technological environment” (See Accenture, 728 F.3d 1336, 108 U.S.P.Q.2d 1173 (Fed. Cir. 2013), citing Flook, 437 U.S. at 584), and finally merely limiting the field of use of the abstract idea to a particular existing technological environment does not render the claims any less abstract (See Affinity Labs, _F.3d_, 120 U.S.P.Q.2d 1201 (Fed. Cir. 2016), citing Alice, 134 S. Ct. at 2358; Mayo, 132 S. Ct. at 1294; Bilski v. Kappos, 561 U.S. 593, 612 (2010); Content Extraction & Transmission LLC v. Wells Fargo Bank, Nat’l Ass’n, 776 F.3d 1343, 1348 (Fed. Cir. 2014); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355 (Fed. Cir. 2014).
Applicant herein only requires one or more general-purpose computer and generic computer components (as evidenced from figures 1 and 10, as well as, paragraphs 35 and 127-134 of the applicant’s specification which discloses that the computing device is a general-purpose computer with generic computer components; the Intellectual Ventures I v. Capital One decision which found that a generic interactive interface that provides information to and accepts user input is a generic computer element; the prior arts of Zorzi et al. (PGPUB: 2023/0146018 – paragraph 37 and claim 5) and Uzgin et al. (PGPUB: 2019/0043231 – paragraphs 43 and 87), which both disclose that, prior to the effective filing date of the instant invention standard vector formats for vector files include one or more of SVG and JSON formats; and W3schools, JavaScript JSON Reference, January 19, 2023, https://web. archive.org/ web/20230119215806/https://www.w3schools.com/jsref/jsref_obj_json.asp, pages 1-6; W3C, An SVG Primer for Today’s Browser’s, September 2010, https:// www.w3.org/Graphics/SVG/IG/resources/svgprimer.html#SMIL_animations, pages 1-165; and Oreillymedia, Using SVG with CSS3 and HTML5 – Supplementary Material, July 6, 2022, https://web.archive.org/web/20220706014901/ https://oreillymedia.github.io/Using_SVG/guide/markup.html#integration, pages 1-56, which are all used to disclose that SVG tags that include JavaScript for accessing JSON objects were well-known prior to the effective filing data of the applicant’s invention); therefore, there does not appear to be any alteration or modification to the generic activities indicated, and they are also therefore recognized as insignificant activity with respect to eligibility. Finally, the following limitations, if removed from the abstract idea and considered additional elements, would be considered insignificant extra solution activity as they are directed to merely receiving, displaying, storing, and/or transmitting data (see MPEP 2016.05(d)(II) and MPEP 2106.05(g)):
receiving a digital image of an item (receiving data);
receiving, via a graphical user interface (GUI), a user selection of the promotional emblem image (receiving data); and
outputting the combined image for display in the GUI (transmitting data).
Thus, taken individually and in combination, the additional elements do not amount to significantly more than the above-identified judicial exception (the abstract idea) (i.e., “PEG” Step 2B=No).
The dependent claim 19 appear to merely further limit the abstract idea by adding an additional step of controlling deployment of the combined image which is considered part of the abstract idea (Claim 19), and therefore only further limit the abstract idea (i.e. “PEG” Revised Step 2A Prong One=Yes), does/do not include any new additional elements that are sufficient to amount to significantly more than the judicial exception, and as such are “directed to” said abstract idea (i.e. “PEG” Step 2A Prong Two=Yes); and do not add significantly more than the idea (i.e. “PEG” Step 2B=No)..
Thus, based on the detailed analysis above, claims 18-20, and 25 are not patent eligible.
Claims 12-13, 15-17 and 24 are directed to a method which would be classified under one of the listed statutory classifications (i.e., 2019 Revised Patent Subject Matter Eligibility Guidance (hereinafter “PEG”) “PEG” Step 1=Yes).
However, claims 12-13, 15-17 and 24 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. Claim(s) 12 and 24 recite(s) the following abstract idea:
generating a promotional emblem image including one or more graphical promotion data fields and one or more embedded encoding elements configured to target data and populate the one or more graphical promotion data fields with information form the targeted data when processed, wherein the promotion emblem image is a scalable vector graphic (SVG) image defined by an image encoding structure, and the one or more embedded encoding elements include one or more JavaScript portions embedded within the image encoding structure;
receiving a listing of an item on an electronic commerce platform, the listing including: promotion data describing promotion parameters of the item and a digital image of an item;
receiving a user selection of the promotion emblem image; and
responsive to receiving the user selection of the promotion emblem image:
processing the one or more embedded encoding elements to populate the one or more graphical promotion data fields with information from the promotion data;
generating a combined image formed from the digital image of the item and the promotion emblem image; and
controlling deployment of the combined image within the listing for display based on the promotion parameters, wherein controlling deployment of the combined image within the listing includes replacing the digital image in the within with the combined image.
The limitations as detailed above, as drafted, falls within the “Certain Method of Organizing Human Activity” grouping of abstract ideas namely commercial or legal interactions because they recite advertising, marketing and sales activities or behaviors. Accordingly, the claim recites an abstract idea (i.e. “PEG” Revised Step 2A Prong One=Yes).
This judicial exception is not integrated into a practical application because the claim only recites the additional elements of:
a computing device (e.g., a general-purpose computer);
a graphical user interface for providing information to an accepting user input (e.g., a generic computer element as per the Intellectual Ventures I v. Capital One decision); and
generating a dynamic SVG with an embedded encoding element within a data field, wherein the embedded encoding element includes a JavaScript Object Notation (JSON) object (e.g., a generic computer component as it is a traditional way in which dynamic SVGs tags are intended to operate).
When analyzing these additional elements, both individually and as a whole, the main question that needs to be answered is whether the dynamic SVG being claimed is a technical element of the claim which results in an improvement to a traditional SVG capable of transforming the abstract idea into a practical application under Step 2a, Prong 2. The applicant’s disclosure in figures 4-5 and paragraphs 85-98 describe how the invention dynamically updates the SVG using a JavaScript function including the JSON object. However, these sections of the applicant’s disclosure do not describe any problems encountered when including a JavaScript function with a JSON object within an SVG, nor any technical solutions for overcoming such problems. Furthermore, the applicant’s disclosure provides no specific information regarding how one of ordinary skill in the art would need to implement such an SVG. The closest thing to a specific technical implementation is found in figure 5. In figure 5, short snippets of barely legible code for implementing such an SVG are disclosed. Item 500 includes standard SVG shape encoding. Item 502 is SVG text encoding including the standard tspan tag. Within the first standard tspan tag in figure 5 the applicant has included item 406 and within the second standard tspan tag the applicant has included item 400. Based on paragraphs 86 and 89, item 400 and 406 are respective JavaScript functions that include respective JSON objects. There is no disclosure in the applicant’s disclosure of the specific JavaScript function itself nor the creation or structure of the JSON object. There is no disclosure regarding whether the JavaScript function is within the SVG file using the standard <script>…</script> tags or located external to the SVG file. Instead, the applicant merely assumes that one of ordinary skill in the art would already know how incorporate remote retrieval encoding with the SVG using JavaScript functions that includes JSON object. This weighs heavily against the generating of the dynamic SVG being a new type of SVG that the applicant has invented. Next, the examiner considered the significance of a JavaScript function that includes a JSON object. As disclosed in W3schools, JavaScript JSON Reference, January 19, 2023, https://web. archive.org/ web/20230119215806/https://www.w3schools.com/jsref/jsref_obj_json.asp, pages 1-6, which discloses on page 1 that JSON is merely a format for storing and transporting data. JSON is text, and can be transported anywhere, and read by any programming language. JavaScript Objects can be converted to JSON, and JSON can be converted back to JavaScript Object. Thus, it would not appear that a JavaScript function with a JSON object would be a technical improvement of any kind. Next, the examiner considered whether it is unusual to including JavaScript within an SVG file. Based on W3C, An SVG Primer for Today’s Browser’s, September 2010, https:// www.w3.org/Graphics/SVG/IG/resources/svgprimer.html#SMIL_animations, pages 1-165, which discloses on at least pages 56-57 and 71-77 that including JavaScript in an SVG was standard by at least 2010 by using the standard <script> tag. Next, the examiner considered whether it was unusual for JavaScript in an SVG to access a JSON object. Based on Oreillymedia, Using SVG with CSS3 and HTML5 – Supplementary Material, July 6, 2022, https://web.archive.org/web/20220706014901/ https://oreillymedia.github.io/Using_SVG/guide/markup.html#integration, pages 1-56, which discloses on pages 22-24 that SVG is designed to work with CSS, JavaScript, HTML, and other XML languages. The following SVG elements are used to integrate code from those languages in your SVG markup: <script> element can be used to include JSON data in the markup without parsing it, so that another script can access it by reading this element’s text content using type="text/json". Thus, based on these three references, generating a dynamic SVG with an embedded encoding element within a data field, wherein the embedded encoding element includes a JavaScript Object Notation (JSON) object appears to be a normal way in which SVG markup language is intended to operate. SVG is an XML-based vector graphic format that utilizes standardized tags, much like tags in an HTML document, to generate a graphic. These tags appear to already include the functionality for generating a dynamic SVG with an embedded encoding element within a data field, wherein the embedded encoding element includes a JavaScript Object Notation (JSON) object. Thus, every factor considered from the applicant’s disclosure, as well as, the traditional functionalities of SVG tags weighs against this being a technical improvement and instead provides a clear indication that standard SVG functionality is merely being used as a tool to implement the abstract idea.
As such, the additional element of a computing device with a computer-readable storage media (e.g., a general-purpose computer with a generic computer component), a graphical user interface for providing information to an accepting user input (e.g., a generic computer element as per the Intellectual Ventures I v. Capital One decision), and generating a dynamic SVG with an embedded encoding element within a data field, wherein the embedded encoding element includes a JavaScript Object Notation (JSON) object, whether considered individually or as a whole, amount to using a general-purpose computer with generic computer components as tools to merely implement the abstract idea.
The following limitations, if removed from the abstract idea and considered additional elements, merely perform generic computer function of processing, storing, communicating (e.g., transmitting and receiving), and displaying data and, as such, are insignificant extra-solution activities (see MPEP 2016.05(d)(II) and MPEP 2106.05(g)):
receiving, by the computing device, a listing of an item on an electronic commerce platform implemented by the computing device, the listing including: promotion data describing promotion parameters of the item and a digital image of an item (receiving data);
receiving, by the computing device via a graphical user interface (GUI) implemented by the computing device, a user selection of the promotion emblem image (receiving data); and
controlling, by the computing device, deployment of the combined image within the listing for display in the GUI based on the promotion parameters, wherein controlling deployment of the combined image within the listing includes replacing the digital image in the withing with the combined image (transmitting data).
The additional technical elements above are recited at a high-level of generality (i.e., as a generic processor and generic computer components performing a generic computers function of processing, communicating and displaying) such that it amounts to no more than mere instructions to apply the exception using one or more general-purpose computers and generic computer components. The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional technical elements above do not integrate the abstract idea/judicial exception into a practical application because it does not impose any meaningful limits on practicing the abstract idea. More specifically, the additional elements fail to include (1) improvements to the functioning of a computer or to any other technology or technical field (see MPEP 2106.05(a)), (2) applying or using a judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition (see Vanda memo), (3) applying the judicial exception with, or by use of, a particular machine (see MPEP 2106.05(b)), (4) effecting a transformation or reduction of a particular article to a different state or thing (see MPEP 2106.05(c)), or (5) applying or using the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the exception (see MPEP 2106.05(e) and Vanda memo).
Rather, the limitations merely add the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on one or more computers, or merely uses computers as a tool to perform an abstract idea (see MPEP 2106.05(f)), or generally link the use of the judicial exception to a particular technological environment or field of use (see MPEP 2106.05(h)).
Thus, the claim is “directed to” an abstract idea (i.e. “PEG” Revised Step 2A Prong Two=Yes)
When considering Step 2B of the Alice/Mayo test, the claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the claims do not amount to significantly more than the abstract idea.
More specifically, as discussed above with respect to integration of the abstract idea into a practical application, the additional elements of using a computing device, a graphical user interface, and generating a dynamic SVG with an embedded encoding element within a data field, wherein the embedded encoding element includes a JavaScript Object Notation (JSON) object (e.g. a general-purpose computer with generic computer components) to perform the claimed functions amounts to no more than mere instructions to apply the exception using one or more general-purpose computers and one or more generic computer component.
“Generic computer implementation” is insufficient to transform a patent-ineligible abstract idea into a patent-eligible invention (See Affinity Labs, _F.3d_, 120 U.S.P.Q.2d 1201 (Fed. Cir. 2016), citing Alice, 134 S. Ct. at 2352, 2357) and more generally, “simply appending conventional steps specified at a high level of generality” to an abstract idea does not make that idea patentable (See Affinity Labs, _F.3d_, 120 U.S.P.Q.2d 1201 (Fed. Cir. 2016), citing Mayo, 132 S. Ct. at 1300). Moreover, “the use of generic computer elements like a microprocessor or user interface do not alone transform an otherwise abstract idea into patent-eligible subject matter (See FairWarning, 120 U.S.P.Q.2d. 1293, citing DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245, 1256 (Fed. Cir. 2014)). As such, the additional elements of the claim do not add a meaningful limitation to the abstract idea because they would be generic computer functions in any computer implementation. Thus, taken alone, the additional elements do not amount to significantly more than the above-identified judicial exception (the abstract idea). Looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of the computer or improves any other technology. Their collective functions merely provide generic computer implementation.
The Examiner notes simply implementing an abstract concept on one or more computers, without meaningful limitations to that concept, does not transform a patent-ineligible claim into a patent-eligible one (See Accenture, 728 F.3d 1336, 108 U.S.P.Q.2d 1173 (Fed. Cir. 2013), citing Bancorp, 687 F.3d at 1280), limiting the application of an abstract idea to one field of use does not necessarily guard against preempting all uses of the abstract idea (See Accenture, 728 F.3d 1336, 108 U.S.P.Q.2d 1173 (Fed. Cir. 2013), citing Bilski, 130 S. Ct. at 3231), and further the prohibition against patenting an abstract principle “cannot be circumvented by attempting to limit the use of the [principle] to a particular technological environment” (See Accenture, 728 F.3d 1336, 108 U.S.P.Q.2d 1173 (Fed. Cir. 2013), citing Flook, 437 U.S. at 584), and finally merely limiting the field of use of the abstract idea to a particular existing technological environment does not render the claims any less abstract (See Affinity Labs, _F.3d_, 120 U.S.P.Q.2d 1201 (Fed. Cir. 2016), citing Alice, 134 S. Ct. at 2358; Mayo, 132 S. Ct. at 1294; Bilski v. Kappos, 561 U.S. 593, 612 (2010); Content Extraction & Transmission LLC v. Wells Fargo Bank, Nat’l Ass’n, 776 F.3d 1343, 1348 (Fed. Cir. 2014); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355 (Fed. Cir. 2014).
Applicant herein only requires one or more general-purpose computer and generic computer components (as evidenced from figures 1 and 10, as well as, paragraphs 35 and 127-134 of the applicant’s specification which discloses that the computing device is a general-purpose computer with generic computer components; the Intellectual Ventures I v. Capital One decision which found that a generic interactive interface that provides information to and accepts user input is a generic computer element; the prior arts of Zorzi et al. (PGPUB: 2023/0146018 – paragraph 37 and claim 5) and Uzgin et al. (PGPUB: 2019/0043231 – paragraphs 43 and 87), which both disclose that, prior to the effective filing date of the instant invention standard vector formats for vector files include one or more of SVG and JSON formats; and W3schools, JavaScript JSON Reference, January 19, 2023, https://web. archive.org/ web/20230119215806/https://www.w3schools.com/jsref/jsref_obj_json.asp, pages 1-6; W3C, An SVG Primer for Today’s Browser’s, September 2010, https:// www.w3.org/Graphics/SVG/IG/resources/svgprimer.html#SMIL_animations, pages 1-165; and Oreillymedia, Using SVG with CSS3 and HTML5 – Supplementary Material, July 6, 2022, https://web.archive.org/web/20220706014901/ https://oreillymedia.github.io/Using_SVG/guide/markup.html#integration, pages 1-56, which are all used to disclose that SVG tags that include JavaScript for accessing JSON objects were well-known prior to the effective filing data of the applicant’s invention); therefore, there does not appear to be any alteration or modification to the generic activities indicated, and they are also therefore recognized as insignificant activity with respect to eligibility. Finally, the following limitations, if removed from the abstract idea and considered additional elements, would be considered insignificant extra solution activity as they are directed to merely receiving, displaying, storing, and/or transmitting data (see MPEP 2016.05(d)(II) and MPEP 2106.05(g)):
receiving, by the computing device, a listing of an item on an electronic commerce platform implemented by the computing device, the listing including: promotion data describing promotion parameters of the item and a digital image of an item (receiving data);
receiving, by the computing device via a graphical user interface (GUI) implemented by the computing device, a user selection of the promotion emblem image (receiving data); and
controlling, by the computing device, deployment of the combined image within the listing for display in the GUI based on the promotion parameters, wherein controlling deployment of the combined image within the listing includes replacing the digital image in the withing with the combined image (transmitting data).
Thus, taken individually and in combination, the additional elements do not amount to significantly more than the above-identified judicial exception (the abstract idea) (i.e., “PEG” Step 2B=No).
The dependent claims 13 and 15-17 appear to merely further limit the abstract idea by further limiting the promotional emblem image and further limiting the processing of the one or more embedder encoding element which are both considered part of the abstract idea (Claim 13); further limiting the controlling the deployment which is considered part of the abstract idea (Claims 15-16); further limiting the generating the combined image which is considered part of the abstract idea (Claim 17), and therefore only further limit the abstract idea (i.e. “PEG” Revised Step 2A Prong One=Yes), does/do not include any new additional elements that are sufficient to amount to significantly more than the judicial exception, and as such are “directed to” said abstract idea (i.e. “PEG” Step 2A Prong Two=Yes); and do not add significantly more than the idea (i.e. “PEG” Step 2B=No)..
Thus, based on the detailed analysis above, claims 12-13, 15-17 and 24 are not patent eligible.
Possible Allowable Subject Matter
Claims 1-2, 4-7, 9-13, 15-21, and 24-25 are contain subject matter that would be allowable over the prior art if the applicant were to be able to overcome the 35 USC 112(a) rejections, 35 USC 112(b) rejections, and the 35 USC 101 rejections above.
The following is a statement of reasons for the indication of allowable subject matter: The examiner has found prior art (see Gao et al. - CN104050568A; Uzgin et al. - 2019/0043231; and Shorthand.com (What’s the difference between SVG, PNG, and JPEG?, February 3, 2023, https://web.archive.org/web/20230203032116/ https://shorthand.com/the-craft/what-is-an-svg-file/index.html, pages 1-10) that discloses methods and a system comprising:
one or more computing devices; and one or more computer-readable storage media storing instructions which, when executed by the one or more computing devices, cause the one or more computing devices to perform operations comprising:
receiving a listing of an item on an electronic commerce platform, the listing including a graphical promotion dataset of the item;
receiving, via a graphical user interface (GUI), a user selection of an promotion emblem including a graphical promotion data field; and
responsive to receiving the user selection of the promotion emblem:
identifying graphical promotion data of the item from the graphical promotion dataset;
identifying a graphical promotion data field of the promotion emblem;
processing a promotion data retrieval encoding within an image encoding structure of the promotion emblem by executing computer-readable instructions stored within the promotional data retrieval encoding that define graphical objects targeting the promotion data to retrieve the graphical promotion data of the item from the promotion dataset and populate the graphical promotion data field with the graphical promotion data of the item, thereby replacing the graphical promotion data field with the graphical promotion data;
forming/generating a combined image by combining the promotion emblem including the graphical promotion data field populated with the promotion data of the item with the digital image in an overlapping arrangement non-destructive to the digital image; and
controlling deployment of the combined image by outputting the combined image within the listing based on the promotion parameters for display in the GUI.
While Gao, Uzgin, and Shorthand.com disclose a computer performing these steps with regards to graphical based items of the graphical promotion dataset, any text-based items in the promotion dataset would need to be input in the same namespace as the SVG file or updated manually.
Based on the applicant’s specification, in at least paragraph 92-95 and 42, as well as, the applicant’s arguments filed on September 5, 2025, the promotional dataset includes text and the instructions within the encoding of the promotional emblem include textual elements that are dynamically updated with the text of the promotional dataset.
As such, the prior art of Gao, Uzgin, and Shorthand.com cannot be said to teach, as recited in claim 1: identifying textual promotion data of the item from a promotion dataset and populating, by the computing device, the graphical promotion data field with the textual promotion data of the item via execution of instructions stored within an encoding of the promotional emblem; as recited in claim 12: receiving…promotion data describing promotion parameters of the item and processing, by the computing device, a promotion data retrieval encoding within an image encoding structure of the emblem to replace the graphical promotion data field with the promotion data; and as recited in claim 18, identifying promotion data of the item from a promotion dataset and populating the graphical promotion data field with the promotion data of the item by executing instructions defined by promotion data retrieval encoding stored within an image encoding structure of the promotional emblem.
The examiner has also found prior art (see stackoverflow.com, Scripting <path> data in SVG (reading and modifying), November 21, 2021, https://web.archive.org/web/ 20211129035935/https://stackoverflow.com/questions/8053487/scripting-path-data-in-svg-reading-and-modifying, pages 1-6) that discloses including JavaScript in a <script> encoding of the SVG file, that when executed allows for the dynamic updating of text from a remote location.
However, it would not have been obvious to one of ordinary skill in the art to combine these four different references without the use of impermissible hindsight by using the applicant’s claims as a roadmap.
Thus, claims contain subject matter that would be allowable over the prior art of Gao, Uzgin, and Shorthand.com if the applicant were to be able to overcome the 35 USC 112(a) rejections, 35 USC 112(b) rejections, and the 35 USC 101 rejections above.
Response to Arguments
Applicant's arguments filed September 9, 2025 have been fully considered but they are not persuasive.
In regards to the 35 USC 101 rejection, the applicant argues that the claims as amended integrate the alleged abstract idea into a practical application under Step 2a, Prong 2 because they recite a specific technical improvement in the field of item listing promotion management that provides technical advantages over conventional system. The examiner disagrees. In order to overcome a 35 USC 101 rejection under Step 2a, Prong 2, any purported technical improvement that is capable of transforming an abstract idea into a practical application must be rooted in the “additional elements” of the claim. “Additional elements” are defined as those elements that are not part of the identified abstract idea itself. As explained in the 35 USC 101 rejection above, the only additional elements that are claimed are a computing device (e.g., general-purpose computer); a graphical user interface for providing information to an accepting user input (e.g., a generic computer element as per the Intellectual Ventures I v. Capital One decision); and generating a dynamic SVG with an embedded encoding element within a data field, wherein the embedded encoding element includes a JavaScript Object Notation (JSON) object (e.g., a generic computer component as it is a traditional way in which dynamic SVGs tags are intended to operate). The additional elements of the computing device (e.g., general-purpose computer) and the graphical user interface for providing information to an accepting user input (e.g., a generic computer element as per the Intellectual Ventures I v. Capital One decision), whether considered individually or a whole, are clearly nothing more than merely applying the abstract idea using a general purpose computer with generic computer components and, as such, are incapable of overcoming the 35 USC 101 rejection under Step 2a, Prong 2. Thus, the key factor in determining whether the claims overcome the 35 USC 101 rejection is whether generating a dynamic SVG with an embedded encoding element within a data field, wherein the embedded encoding element includes a JavaScript Object Notation (JSON) object is a technical improvement which, when considered individually or a whole with the other additional elements, is capable of transforming the abstract or whether it is a standard SVG capability which is merely used as a tool to implement the abstract idea. The applicant’s disclosure in figures 4-5 and paragraphs 85-98 describe how the invention dynamically updates the SVG using a JavaScript function including the JSON object. However, these sections of the applicant’s disclosure do not describe any problems encountered when including a JavaScript function with a JSON object within an SVG, nor any technical solutions for overcoming such problems. Furthermore, the applicant’s disclosure provides no specific information regarding how one of ordinary skill in the art would need to implement such an SVG. The closest thing to a specific technical implementation is found in figure 5. In figure 5, short snippets of barely legible code for implementing such an SVG are disclosed. Item 500 includes standard SVG shape encoding. Item 502 is SVG text encoding including the standard tspan tag. Within the first standard tspan tag in figure 5 the applicant has included item 406 and within the second standard tspan tag the applicant has included item 400. Based on paragraphs 86 and 89, item 400 and 406 are respective JavaScript functions that include respective JSON objects. There is no disclosure in the applicant’s disclosure of the specific JavaScript function itself nor the creation or structure of the JSON object. There is no disclosure regarding whether the JavaScript function is within the SVG file using the standard <script>…</script> tags or located external to the SVG file. Instead, the applicant merely assumes that one of ordinary skill in the art would already know how incorporate remote retrieval encoding with the SVG using JavaScript functions that includes JSON object. As per MPEP 2161.01, “the algorithm or steps/procedure taken to perform the function must be described with sufficient detail so that one of ordinary skill in the art would understand how the inventor intended the function to be performed. See MPEP §§ 2163.02 and 2181, subsection IV”. Thus, the disclosure in figures 4-5 and paragraphs 85-98 must be considered a sufficient disclosure of how one or ordinary skill in the art would understand how the inventor intended the generated dynamic SVG claimed is to be performed. Thus, one must conclude, given the applicant’s disclosure, that merely placing a JavaScript function including a JSON object within the code of the SVG is sufficient for one or ordinary skill in the art to understand how to implement the claimed dynamic SVG. This weighs heavily against the generating of the dynamic SVG claimed being a new type of SVG that the applicant has invented or new technological manner in which such an SVG is created. Next, the examiner considered the significance of a JavaScript function that includes a JSON object. As disclosed in W3schools, JavaScript JSON Reference, January 19, 2023, https://web. archive.org/web/20230119215806/https://www.w3schools.com/jsref/jsref_obj_json.asp, pages 1-6, which discloses on page 1 that JSON is merely a format for storing and transporting data. JSON is text, and can be transported anywhere, and read by any programming language. JavaScript Objects can be converted to JSON, and JSON can be converted back to JavaScript Object. Thus, it would not appear that a JavaScript function with a JSON object would be a technical improvement of any kind. Next, the examiner considered whether it is unusual to including JavaScript within an SVG file. Based on W3C, An SVG Primer for Today’s Browser’s, September 2010, https://www.w3.org/Graphics/SVG/IG/ resources/svgprimer.html#SMIL_animations, pages 1-165, which discloses on at least pages 56-57 and 71-77 that including JavaScript in an SVG was standard by at least 2010 by using the standard <script> tag. Next, the examiner considered whether it was unusual for JavaScript in an SVG to access a JSON object. Based on Oreillymedia, Using SVG with CSS3 and HTML5 – Supplementary Material, July 6, 2022, https://web.archive.org/web/ 20220706014901/https://oreillymedia.github.io/Using_SVG/guide/markup.html#integration, pages 1-56, which discloses on pages 22-24 that SVG is designed to work with CSS, JavaScript, HTML, and other XML languages. The following SVG elements are used to integrate code from those languages in your SVG markup: <script> element can be used to include JSON data in the markup without parsing it by using type="text/json", so that another script can access it by reading this element’s text content. Thus, based on these three references, generating a dynamic SVG with an embedded encoding element within a data field, wherein the embedded encoding element includes a JavaScript Object Notation (JSON) object appears to be a normal way in which SVG markup language is intended to operate. SVG is an XML-based vector graphic format that utilizes standardized tags, much like tags in an HTML document, to generate a graphic. These tags appear to already include the functionality for generating a dynamic SVG with an embedded encoding element within a data field, wherein the embedded encoding element includes a JavaScript Object Notation (JSON) object. Thus, every factor considered from the applicant’s disclosure, as well as, the traditional functionalities of SVG tags weighs against this being a technical improvement and instead provides a clear indication that standard SVG functionality is merely being used as a tool to implement the abstract idea. Therefore, considered individually, the claimed generating an SVG with an embedded encoding element within a data field, wherein the embedded encoding element includes a JavaScript Object Notation (JSON) object appears to be a generic computer component as it is a traditional way in which dynamic SVGs tags are intended to operate and, as such, is merely applying the abstract idea using the claimed SVG as a tool, which is insufficient to transform an abstract idea into a practical application under Step 2a, Prong 2. Considered as a whole, the claims appear to merely apply the abstract idea using a general-purpose computer and generic computer components as a tool. As such, the purported improvement of modifying item listings without the need to manually modify item listings rests not in the “additional elements” of the claim, but instead in the abstract idea itself which is merely applied using the general-purpose computer with generic computer components as a tool. Improvements of this nature are improvement to an abstract idea which are improvements in ineligible subject matter (see MPEP 2106.05(a): “It is important to note, the judicial exception alone cannot provide the improvement”; MPEP 2106.05(a)(II): “However, it is important to keep in mind that an improvement in the abstract idea itself (e.g. a recited fundamental economic concept) is not an improvement in technology”; and the SAP v. Investpic decision: Page 2, line 22 through Page 3, line 13 - Even assuming that the algorithms claimed are groundbreaking, innovative or even brilliant, the claims are ineligible because their innovation is an innovation in ineligible subject matter because they are nothing but a series of mathematical algorithms based on selected information and the presentation of the results of those algorithms. Thus, the advance lies entirely in the realm of abstract ideas, with no plausible alleged innovation in the non-abstract application realm. An advance of this nature is ineligible for patenting; and Page 10, lines 18-24 - Even if a process of collecting and analyzing information is limited to particular content, or a particular source, that limitations does not make the collection and analysis other than abstract). Furthermore, while it is true that using the traditional dynamic functionalities of SVG, as claimed, would result in the ability to change various elements of an item listing without manually changing the item listing itself, it would still require manually changing the data in the JSON object to include any updated information because the applicant’s specification does not disclose any other automatic means for the data in the JSON object to change. As such, it would not appear that manually changing data in the JSON object would be an improvement over manually changing the item listing, since they both require a manual modification to make any changes. Thus, the applicant’s arguments are not convincing and the rejections have been maintained.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Li (PGPUB: 2022/0070514) which discloses obtaining an image of a product and promotion information for the product; determining a discount price for the product; and generating an overlay indicating the discount which is displayed on the product image.
Pasala et al. (PGPUB: 2019/0346981) which discloses generating advertisements by obtaining an input file including image components, scalable vector graphic (SVG) components, text components, tween components, animation components, physics components, and augmented reality (AR) components; converting the components into JSON elements; and using a template generating a layered advertisement for consumption on a computing device.
Stansell et al. (PGPUB: 2019/0244436) which discloses receiving an image and a promotional offer; analyzing the promotional offer; determining whether to display the promotional offer to a user; and overlaying the promotion on an image.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JOHN W VAN BRAMER whose telephone number is (571)272-8198. The examiner can normally be reached Monday-Thursday 5:30 am - 4 pm EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Spar Ilana can be reached at 571-270-7537. 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.
/John Van Bramer/Primary Examiner, Art Unit 3622
Prosecution Insights