DETAILED ACTION
1. 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 .
2.Status of Application and Claims
Claims 1 and 3-20 are pending.
Claim 2 is missing from the submitted list of claims.
Claims 1, 11 and 16 were amended and/or newly added in the Applicant's filing(s) on 1/16/2026.
This office action is being issued in response to the Applicant's filing(s) on 1/16/2026.
3. Minor Objections
Claim 1 is objected to because of the following informalities: lack of antecedent basis.
Claim 1 recites:
communicating, via one or more application programming interface (APIs) using an API protocol, with a standardization process of the private company securities platform that enables converting the information in the first format to the standardized format;
There is no earlier recitation of a standardized format. The claim term of “standardized format” was amended to “second format” in the amendments filed on 1/16/2026.
Claim 11 has similar issues.
4. Claim Interpretation
The subject matter of a properly construed claim is defined by the terms that limit its scope when given their broadest reasonable interpretation. see MPEP §2013(I)(C). Specifically, the “broadest reasonable construction ‘in light of the specification as it would be interpreted by one of ordinary skill in the art.’” See MPEP §2111, citing Phillips v. AWH Corp., 75 USPQ2d 1321, 1329 (Fed. Cir. 2005). However, “[t]hough understanding the claim language may be aided by explanations contained in the written description, it is important not to import into claim limitations that are not part of the claim.” See MPEP §2111.01, citing Superguide Corp. v. DirecTV Enterprises, Inc., 69 USPQ2d 1865, 1868 (Fed. Cir. 2004). Construing claims broadly during prosecution is not unfair to the applicant, because the applicant has the opportunity to amend the claims to obtain more precise claim coverage. See MPEP §2111, citing In re Yamamoto, 222 USPQ 934, 936 (Fed. Cir. 1984).
As a general matter, grammar and the plain meaning of terms as understood by one having ordinary skill in the art used in a claim will dictate whether, and to what extent, the language limits the claim scope. See MPEP §2013(I)(C). Language that suggests or makes a feature or step optional but does not require that feature or step does not limit the scope of a claim under the broadest reasonable claim interpretation. See MPEP §2013(I)(C).
As such, claim limitations that contain statement(s) such as “if,” “may,” “might,” “can,” and “could” are treated as containing optional language. See MPEP §2013(I)(C). As matter of linguistic precision, optional claim elements do not narrow claim limitations, since they can always be omitted. See MPEP §2013(I)(C).
Similarly, a method step exercised or triggered upon the satisfaction of a condition, where there remains the possibility that the condition was not satisfied under the broadest reasonable interpretation, is an optional claim limitation. See MPEP §2111.04(II). As the Applicant does not address what happens should the optional claim limitations fail, Examiner assumes that nothing happens (i.e., the method stops). An alternate interpretation is that merely the claim limitations based upon the condition are not triggered or performed.
In addition, when a claim requires selection of an element from a list of alternatives, the prior art teaches the element if one of the alternatives is taught by the prior art. See MPEP §2143.03, citing Fresenius USA, Inc. v. Baxter Int’l, Inc., 582 F.3d 1288, 1298 (Fed. Cir. 2009);
Language in a method or system claim that states only the intended use or intended result, but does not result in a manipulative difference in the steps of the method claim nor a structural difference between the system claim and the prior art, fails to distinguish the claims from the prior art.
The following types of claim language may raise a question as to its limiting effect (this list is not exhaustive):
Statements of intended use or field of use, including statements of purpose or intended use in the preamble. See MPEP §2111.02;
Clauses such as “adapted to”, “adapted for”, “wherein”, and “whereby.” See MPEP §2111.04;
Contingent limitations. See MPEP §2111.04(II);
Printed matter. See MPEP §2111.05; and
Functional language associated with a claim term. See MPEP §2181.
As such, while all claim limitations have been considered and all words in the claims have been considered in judging the patentability of the claimed invention, the following italicized, underlined and/or boldened language is interpreted as not further limiting the scope of the claimed invention.
Additionally, the following italicized, underlined and emboldened language is not necessarily an exhaustive list of claim language that is interpreted as not further limiting the scope of the claimed invention. Applicant should review all claims for additional claim interpretation issues.
Claim 1 recites a method comprising:
receiving an input comprising information for a transfer notice provided by a user in a first format incompatible with a plurality of user interfaces of an application associated with processing the transfer notice by the private company securities platform, wherein one or more of the plurality of user interfaces display and enable processing of the transfer notice based on a second format for an order page that is accessible via the one or more of the plurality of user interfaces.
Method claims are defined by the method steps being actively performed (i.e., receiving an input), not method steps that may or may not be performed. Reciting that a system element (i.e., user interface) in a method claim is configured to perform a method step (i.e., to display and enable processing) does not mean that the method step is actually performed (i.e., displaying and enabling processing).
Method claims are defined by the method steps being actively performed (i.e., accessing information), not method steps that may or may not be performed. Reciting that a system element (i.e., order page) in a method claim is configured to perform a method step (i.e., is accessible, is capable of being accessed) does not mean that the method step is actually performed (i.e., accessing the order page).
Claim 1 recites a method comprising:
determining a plurality of form fields of the order page presentable via the one or more of the plurality of user interfaces that present and enable processing of standardized order data for the order when the information in the first format is converted to the second format;
Under the broadest reasonable interpretation, every form field of the order page is presentable (i.e., capable of being presented) via the one or more plurality of user interfaces. Examiner notes that the method step of presenting the order page is never actively performed. As such, presentable pertains to the capability to potentially present the plurality of form fields of the order page.
Claim 11 has similar issues.
Claim 1 recites a method comprising:
generating, using the standardization process, the security order comprising the standardized order data inputted to the plurality of form fields for the order page presented by the user interface;
Method claims are defined by the method steps being actively performed not method steps performed in the past (i.e., data inputted to the plurality of form fields or an order page presented by the user interface).
Examiner notes that the claimed method never recites (i) presenting an order page on a user interface, (ii) presenting any information on a user interface or (iii) inputting data into a plurality of form fields.
Claiming method steps in the past tense can be interpreted as the method steps performed in the past are outside the scope of the claimed method. Alternatively stated, the scope of the claimed method are the active method steps which are building off a pre-existing state. The method steps performed for creation of the pre-existing state are outside the scope of the claimed invention.
Claim 1 recites a method comprising
automatically populating, without a further input by the user, the user interface with the standardized order data in the order page and a plurality of menu items for configuring the standardized order data;
Method claims are defined by the method steps being actively performed (i.e., receiving an input), not method steps that may or may not be performed. Reciting that a system element (i.e., user interface) in a method claim is configured to perform a method step (i.e., to display and enable processing) does not mean that the method step is actually performed (i.e., displaying and enabling processing).
Additionally, claim elements (i.e., the displayed menu items) pertain to nonfunctional descriptive material and are not functionally involved in the steps recited. Thus, this descriptive material will not distinguish the claimed invention from the prior art in terms of patentability. See MPEP §2111.05 (III).
Claim 11 has similar issues.
Claim 1 recites a method comprising:
automatically generating and transmitting a plurality of second notifications to all parties to the security order, the plurality of second notifications requesting a plurality of signatures for a transfer agreement settling the transfer notice and including the standardized order data;
Claim elements (i.e., the contents of the notifications) pertain to nonfunctional descriptive material and are not functionally involved in the steps recited. Thus, this descriptive material will not distinguish the claimed invention from the prior art in terms of patentability. See MPEP §2111.05 (III).
Claim 11 has similar issues.
Claim 6 recites a method wherein the input comprises a transfer notice.
Claim elements pertain to nonfunctional descriptive material and are not functionally involved in the steps recited. Thus, this descriptive material will not distinguish the claimed invention from the prior art in terms of patentability. See MPEP §2111.05 (III).
Claim 15 has similar issues.
Claim 7 recites a method wherein the transaction approval comprises a right of first refusal.
The broadest reasonable interpretation of a method (or process) claim having contingent limitations requires only those steps that must be performed and does not include steps that are not required to be performed because the condition(s) precedent is not met. See MPEP §2111.04(II).
Claim 1 recites a method “triggering a countdown for a transaction approval” which suggests that there remains the possibility that the contingent limitations are not performed as the condition(s) precedent is not met (i.e., no transaction approval is received). Therefore, the claim limitations based upon the condition are optional claim limitations. As a matter of linguistic precision, optional claim limitations do not narrow the scope of the invention, since they can always be omitted. See MPEP §2111.04(II).
As the Applicant does not address what happens should the optional claim limitation(s) fail, Examiner assumes that nothing happens (i.e., the method stops). An alternate interpretation is that merely the claim limitations based upon the condition are not triggered or performed.
Additionally, claim elements pertain to nonfunctional descriptive material (i.e., legal provisions contained within transaction approval) and are not functionally involved in the steps recited. Thus, this descriptive material will not distinguish the claimed invention from the prior art in terms of patentability. See MPEP §2111.05 (III).
Claims 8, 17 and 19 have similar issues.
Claim 9 recites a method wherein the first notification comprises the standardized order data and a request for an approval for a right of first refusal for the issuer.
Claim elements pertain to nonfunctional descriptive material and are not functionally involved in the steps recited. Thus, this descriptive material will not distinguish the claimed invention from the prior art in terms of patentability. See MPEP §2111.05 (III).
Claim 19 has similar issues.
Claim 12 recites a system wherein the code causes the system to:
automatically generate a transaction confirmation upon receipt of the plurality of signatures.
The broadest reasonable interpretation of a method (or process) claim having contingent limitations requires only those steps that must be performed and does not include steps that are not required to be performed because the condition(s) precedent is not met. See MPEP §2111.04(II).
Usage of the term and/or phrase “upon receipt of the plurality of signatures” in Claim 2 suggests that there remains the possibility that the contingent limitations are not performed as the condition(s) precedent is not met (i.e., no plurality of signatures are received). Therefore, the claim limitations based upon the condition are optional claim limitations. As a matter of linguistic precision, optional claim limitations do not narrow the scope of the invention, since they can always be omitted. See MPEP §2111.04(II).
As the Applicant does not address what happens should the optional claim limitation(s) fail, Examiner assumes that nothing happens (i.e., the method stops). An alternate interpretation is that merely the claim limitations based upon the condition are not triggered or performed.
5. 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 and 3-20 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to an abstract idea without significantly more.
STEP 1
The claimed invention falls within one of the four statutory categories of invention (i.e., process, machine, manufacture and composition of matter). See MPEP §2106.03.
STEP 2A – PRONG ONE
The claim(s) recite(s) a method and/or a system to perform a method comprising:
receiving an input comprising information for a transfer notice provided by a user in a first format incompatible with … processing the transfer notice by the private company securities [entity] … enable processing of the transfer notice based on a second format for an order page that is accessible …;
determining a plurality of form fields of the order … enable processing of standardized order data for the order when the information in the first format is converted to the second format;
determining portions of the input corresponding to the plurality of form fields;
communicating … with a standardized process of the private company securities [entity] that enables converting the information in the first format to the standardized format;
converting, using the standardization process …, the information to the second format for the order … wherein the converting comprises:
updating the information in the first format to the second format using the standardization process;
generating the standardized order data for a security order based at least on one of identifiers or security order information from the updated information in the second format;
generating, using the standardization process, the security order comprising the standardized order data inputted to the plurality of form fields for the order …;
… populating, without a further input by the user, … with the standardized order data in the order …;
… generating and transmitting a first notification including the standardized order data to an issuer, the transmitting of the first notification triggering a countdown for a transaction approval for the issuer;
… generating and transmitting a plurality of second notifications to all parties to the security order, the plurality of second notifications requesting a plurality of signatures for a transfer agreement settling the transfer notice and including the standardized order data; and
… initiating … a settlement corresponding to the transfer notice based on the security order based on at least one of the countdown or one or more of the plurality of signatures received.
These limitations, as drafted, under its broadest reasonable interpretation, covers a series of steps instructing how to process transfer notices pertaining to financial instruments which is a fundamental economic practice, a sub-category of certain method(s) of organizing human activity, an enumerated grouping of abstract ideas. See MPEP §2106.04(a)(2)(II)(A).
Additionally, these limitations, as drafted, under its broadest reasonable interpretation, covers a series of steps instructing how to process transfer notices pertaining to financial instruments which qualifies as a commercial or legal interaction, a subcategory of certain methods of organizing human activity, an enumerated grouping of abstract ideas. See MPEP §2106.04(a)(2)(II)(B).
Additionally, these limitations, as drafted, under its broadest interpretation, covers a series of steps that can be practically performed in the human mind (e.g., observations, evaluations, judgments and opinions) which are mental process, a second enumerated grouping of abstract ideas. See MPEP §2106.04(a)(2)(III).
Accordingly, the claimed invention recites an abstract idea.
STEP 2A – PRONG TWO
The claimed invention recites additional elements (i.e., computer elements) of a processor (Claim(s) 1 and 11), performing method steps automatically (Claim(s) 1 and 11), a user interface(s) (Claims(s) 1 and 11), an application programming interface (Claim(s) 1 and 11), a memory (Claim(s) 11), and a processor executable code (Claim(s) 11).
The claimed invention does not include additional elements that integrate the judicial exception into a practical application of the exception because the claims do not provide improvements to another technology or technical field; improvements to the functioning of the computer itself; are not applying or using a judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition; are not applying the judicial exception with or by use of a particular machine; are not effecting a transformation or reduction of a particular article to a different state or thing; and are not applying the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment. See MPEP §2106.04(d).
The additional elements are recited at a high-level of generality such that it amounts no more than mere instructions to apply the exception using a generic computer component. See MPEP §2106.05(f). Alternately, the additional elements amount to no more than generally linking the exception to a particular technological environment or field of use. See MPEP §2106.05(h). Accordingly, these additional element(s), when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea.
Accordingly, the claimed invention is directed to an abstract idea without a practical application.
STEP 2B
Upon reconsideration of the indicia noted under Step 2A in concert with the Step 2B considerations, the additional claim element(s) amounts to no more than mere instructions to apply the exception using generic computer components. See MPEP §2106.07(a)(II). The same analysis applies in Step 2B, i.e., mere instructions to apply an exception using a generic computer component cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B. The claim does not provide an inventive concept significantly more than the abstract idea.
Accordingly, these additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
DEPENDENT CLAIMS
Dependent Claim(s) 3-10 and 12-20 recite claim limitations that further define the abstract idea recited in respective independent Claim(s) 1 and 11. As such, the dependent claims are also grouped an abstract idea utilizing the same rationale as previously asserted against the independent claims.
No additional computer components other than those found in the respective independent claims is recited, thus it is presumed that the claim is further utilizing the same generically recited computer.
As such, the dependent claims do not include any additional elements that integrate the abstract idea into a practical application of the judicial exception or are sufficient to amount to significantly more than the judicial exception when considered both individually and as an ordered combination.
6. Claim Rejections - 35 USC § 112(b)
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 and 3-20 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.
Claim 1 recites a method comprising:
receiving an input comprising information for a transfer notice provided by a user in a first format incompatible with a plurality of user interfaces of an application associated with processing the transfer notice by the private company securities platform, wherein one or more of the plurality of user interfaces display and enable processing of the transfer notice based on a second format for an order page that is accessible via the one or more of the plurality of user interfaces.
Claim 1 is rejected based upon a reference to a claim element that is variable. “A claim may be rendered indefinite when a limitation of the claim is defined by reference to an object and the relationship between the limitation and the object is not sufficiently defined.” See MPEP §2173.05(b)(II).
Claim 1 defines a first format as a format “incompatible with a plurality of user interfaces of an application associated with processing the transfer notice by the private company securities platform.” The format is being defined by the capabilities or lack thereof of the user interface.
However, the capabilities of “user interfaces of an application associated with processing the transfer notice by the private company securities platform” are not sufficiently defined in the specification. As such, the claim language fails to establishes any limitations on the claim term “first format."
Claim 11 has similar issues.
Claim 1 recites a method comprising:
automatically generating and transmitting a first notification including the standardized order data to an issuer, the transmitting of the first notification triggering a countdown for a transaction approval for the issuer;
automatically generating and transmitting a plurality of second notifications to all parties to the security order, the plurality of second notifications requesting a plurality of signatures for a transfer agreement settling the transfer notice and including the standardized order data; and
automatically initiating, via the one or more APIs using the API protocol, a settlement corresponding to the transfer notice based on the security order based on at least one of the countdown or one or more of the plurality of signatures received.
What does this mean?
Claim 1 recites a method comprising triggering a countdown for transaction approval for the issuer and initiating settlement based on the countdown.
Does this mean that settlement occurs if the issuer provides a transaction approval, wherein the timeline for transaction approval is established by the countdown, or does this mean that settlement occurs at the end of the countdown, regardless of whether transaction approval was provided?
Examiner notes, if settlement is contingent on (i) receiving transaction approval or (ii) receiving one or more signatures then there remains the possibility that the contingent limitations (i.e., settlement) are not performed as the condition(s) precedent is not met. The claims, as written, do not establish that the system (i) receives transaction approval or (ii) receives one or more signatures. Therefore, the claim limitations based upon the condition are optional claim limitations. As a matter of linguistic precision, optional claim limitations do not narrow the scope of the invention, since they can always be omitted. See MPEP §2111.04(II).
As the Applicant does not address what happens should the optional claim limitation(s) fail, Examiner assumes that nothing happens (i.e., the method stops). An alternate interpretation is that merely the claim limitations based upon the condition are not triggered or performed.
Conversely, if the settlement is contingent on the countdown, not transaction approval, then transaction approval is irrelevant. Settlement occurs regardless of whether the approval is received. The countdown is analogous toa settlement timer.
Claim 11 has similar issues.
Appropriate correction is requested.
7. Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1, 3-6, 10, 11, 13-16 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable Spinka (US PG Pub. 2020/0302526) in view of Smith (US PG Pub. 2020/0097548).
Regarding Claim 1, Spinka discloses a method comprising:
receiving an input comprising information (order data) for a transfer order provided by a user in a first format (client-specific format) incompatible with a plurality of interfaces (order routers/market venues) of an application associated with processing the transfer notice (order) by the private company securities platform, wherein one or more of the plurality of interfaces (order routers/market venues) enable processing of the transfer notice (order) based on a second format (common format or venue-specific format) for an order page of non-standardized information (order data in customer-specific format) provided by the user the one or more of the plurality of interfaces format incompatible with a standardized (common or venue-specific) order format that is accessible via the one or more of the plurality of interfaces. (see para. 20-21);
determining a plurality of parameters (e.g., price and quantity) of the order (limit order) that enable processing of the standardized order when the information in the first format (customer-specific format) is converted to the second format (common format). (see para. 20-21 and 46-47);
determining portions of the input (e.g., price and quantity) corresponding to the plurality of parameters. (see para. 20-21 and 46-47);
communicating, via one or more application using a protocol, with a standardization process of the private company securities platform that enables converting the information in the first format (customer-specific format) to the standardized format (common format). (see para. 20-21)
converting, using the standardization process via the application, the information to the second format for the order, wherein the converting comprises:
updating the information in the first format (customer-specific format) to the second format (common or venue-specific format) using the standardization process. (see para. 20-21); and
generating the standardized (common or venue-specific formatted) order data for a security order based on one of identifiers or security order information (appropriate market venue for fulfillment) from the updated information in the second format (common or venue-specific format). (see para. 19-21);
automatically inputting the standardized (common or venue-specific formatted) order data into the order. (see para. 20-21);
generating, utilizing the standardization process, the security order comprising the standardized (common or venue-specific formatted) order data inputted into the order. (see para. 20-21); and
automatically generating and transmitting a first notification including the standardized (common or venue-specific formatted) order data to an issuer (market venue), the transmitting of the first notification triggering a countdown for posting (i.e., until a specified time). (see para. 20-21 and 36);
automatically generating and transmitting a plurality of second notifications (fill data) to all parties to the security order, the plurality of second notifications including the standardized order data. (see para. 27-29); and
automatically initiating a settlement (fulfillment) corresponding to the transfer notice based on the security order based at least one of the countdown (specified time) or one or more of the plurality of signatures received. (see para. 21 and 36).
Spinka does not explicitly teach a method wherein the format pertains to a user interface, wherein the user interface displays the transfer note, although Spinka discloses a method wherein the user communicates with the private company securities platform via a user interface (web interface) (see para. 20) and the private computer securities platform displays information (see para. 57-58).
Spinka does not explicitly teach a method wherein the application is an application programming interface (i.e., a set of rules or protocols that enables software applications to communicate with each other), although Spinka does disclose interfaces between computing devices wherein the computing devices are capable of communicating with each other. (see para. 26-29).
Spinka does not teach a method comprising determining a plurality of form fields of the order page presentable via the one or more of the plurality of user interfaces that present; or wherein portions of the input correspond to the plurality of form fields.
Spinka does not explicitly teach a method wherein the format is presentable (i.e., capable of being presented) via a user interface; wherein the countdown is for a transaction approval for the issuer; or wherein the second notifications request a plurality of signatures for a transfer agreement settling the transfer notice. Examiner notes that such claim elements have no patentable weight based upon Claim Interpretation. See Claim Interpretation.
Smith discloses a method comprising:
receiving an input (client inputs) comprising information for a notice provided by a user in a first format (abbreviated form), wherein one or more of the plurality of user interfaces display and enable processing of the notice based on a second format (original form) for a page that is accessible via the one or more of the plurality of user interfaces. (see para. 11-13);
determining a plurality of form fields of the page presentable via the one or more of the plurality of user interfaces that present and enable processing of standardized order data (original form information) when the information in the first format (abbreviated form) is converted to the second format (original form). (see para. 11-13 and 27);
determining portions of the input corresponding to the plurality of form fields. (see para. 11-13 and 27);
communicating, via one or more application programming interfaces using an API protocol, with a standardization process of the platform that enables converting the information in the first format (abbreviated form) to the standardized format (original form). (see para. 11-13, 27, 38 and 70-71);
converting, using the standardization process via the API, the information (abbreviated form information) to the second format (original form) based for the page presentable via a user interface, wherein the comprises:
updating the information in the first format (abbreviated form) to the second format (original form) using the standardized process. (see para. 11-13 and 27);
generating the standardized order data (original form information) for an order the updated information in the second format (original form). (see para. 11-13 and 27);
automatically inputting, the standardized order data (original form information) in the plurality of form fields of the order page. (see para. 11-13 and 36);
generating, using the standardization process, the order comprising the standardized order data (original form information) inputted to the plurality of form fields for the order page presented by the user interface. (see para. 11-13 and 36);
automatically populating, without a further input by the user (based upon previous input via abbreviated form), the user interface with the standardized order data (original form information) in the page and a plurality of menu items (drop-down menus) for configuring the standardized order data (original form information). (see para. 11-13 and 36);
automatically generating and transmitting a first notification including the standardized order data (original form information) to an issuer (client). (see abstract);
automatically, generating and transmitting a second notification to all parties (client) to the order, the second notification requesting a signature for the agreement settling (completing or finalizing) the notice. (see para. 58 and 80); and
automatically initiating, via the one or more APIs using the API protocol, settlement (completion or finalization) based on one or more of the plurality of signatures. (see para. 58 and 80).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Spinka by incorporating the conversion of data and auto-population of forms with said data, as disclosed by Smith, thereby enabling fast and efficient completion of needed order documentation.
Regarding Claim 3, Spinka discloses a method comprising storing the security order with a storage of the private company securities platform (data storage module). (see fig. 2; para. 23 and 28).
Regarding Claim 4, Spinka discloses a method wherein the standardized (common or venue-specific) order data comprising one or more of a buyer name, a seller name, one or more shares being transferred (e.g., 250,000 shares), price per share (e.g., $50/share), and issuer name (e.g., ABC) in the standardized (common or venue-specific) order format. (see para. 45-47).
Regarding Claim 5, Spinka does not teach a method wherein the input comprises a plurality of documents for the transfer notice.
Smith discloses a method wherein the input comprises a plurality of documentation.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Spinka and Smith by incorporating the ability to submit input via documents, as disclosed by Smith, as document submission is a standard and conventional means for obtaining input data.
Regarding Claim 6, Spinka discloses a method wherein the non-standardized information comprises at least one of order details (target metrics), intent to sell information, or terms for a sale or a transfer a security in a company. (see para. 29).
Regarding Claim 10, Spinka discloses a method wherein the transfer agreement (outbound order to a market venue) is automatically generated by the private company securities platform based on the standardized (common or venue-specific format) order data. (see para. 20-21).
Regarding Claims 11, 13-16 and 20, such claims recite substantially similar limitations as claimed in previously rejected claims and, therefore, would have been obvious based upon previously rejected claims.
Claim(s)7-9, 12 and 17-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Spinka and Smith, as applied to Claims 1 and 11 above, and further in view of Pallotta (US PG Pub. 2023/0222582).
Regarding Claims 7-9, Spinka discloses a method wherein the first notification comprises the standardized (common or venue-specific) order data. (see para. 20-21 and 36).
Spinka does not teach a method wherein the transaction approval comprises a right of first refusal; the right of first refusal is associated with a status comprising one of a pending status, an accepted status, a rejected status, a blocked status, a waived status, or a hold status; or the first notification comprises a request for an approval for a right of first refusal for the issuer.
Pallotta discloses a method wherein:
the transaction approval comprises a right of first refusal. (see para. 77 and 132);
the right of first refusal is associated with a status comprising one of a pending status (pending issuer review), an accepted status, a rejected status, a blocked status, a waived status, or a hold status. (see para. 84); and
the first notification comprises the standardized order data and a request for an approval for a right of first refusal for the issuer (option to offer issuers right of first refusal). (see para. 77-79).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Spinka and Smith by incorporating a right of first refusal, as disclosed by Pallotta, as a right of first refusal is a standard and conventional contractual agreement.
Regarding Claim 12, Spinka does not teach a system wherein the code causes the system to automatically generate a transaction confirmation upon receipt of the plurality of signatures.
Pallotta discloses a system wherein the code causes the system to automatically generate a transaction confirmation (status update) upon receipt of the plurality of signatures. (see para. 68).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Spinka, Smith and Pallotta by incorporating a transaction confirmation, as disclosed by Pallotta, thereby keeping parties apprised concerning the status of proposed transaction.
Regarding Claims 17-19, such claims recite substantially similar limitations as claimed in previously rejected claims and, therefore, would have been obvious based upon previously rejected claims.
8. Response to Arguments
Applicant's arguments filed 1/16/2026 have been fully considered but they are not persuasive.
§101 Rejection
Step 2A Prong Two
Applicant argues that the claimed invention recites a practical application, specifically “an improvement in the functioning of a computer, or an improvement to other technology or technical field,” and, as such, satisfies Step 2A Prong Two of the §101 Guidelines. See Arguments, pp. 9-11.
Specifically, the Applicant argues:
In particular, the limitations relate to a specific usage (data formatting and conversion using a standardization process for automated security order generation and processing) in a specific situation (when receiving input information for a transfer notice requiring conversion to a UI and security order-usable format) to provide a particular practical application that improves technology (e.g., to enable automated inputting, processing, and presenting of the information from the transfer notice into a standardized and compliant format for automated data processing). See Arguments, p. 9 – emphasis added.
The Examiner respectfully disagrees.
MPEP §2106.05(a) recites:
If it is asserted that the invention improves upon conventional functioning of a computer, or upon conventional technology or technological processes, a technical explanation as to how to implement the invention should be present in the specification. That is, the disclosure must provide sufficient details such that one of ordinary skill in the art would recognize the claimed invention as providing an improvement. The specification need not explicitly set forth the improvement, but it must describe the invention such that the improvement would be apparent to one of ordinary skill in the art. Conversely, if the specification explicitly sets forth an improvement but in a conclusory manner (i.e., a bare assertion of an improvement without the detail necessary to be apparent to a person of ordinary skill in the art), the examiner should not determine the claim improves technology.
The specification does not provide any evidence that there is a technical problem (i.e., a technology-based problem) to be solved. For example, the specification does not provide any evidence that existing and conventional technology was not capable of performing the claimed process (i.e., to enable automated inputting, processing, and presenting of the information from the transfer notice into a standardized and compliant format for automated data processing) but for the claimed technology-based solution.
Additionally, the specification does not provide any evidence that the claimed invention results in an improvement to the functioning of a computer, or an improvement to conventional technology or technological processes. For example, the specification does not provide any evidence that the functionality of a computer or conventional technology have been improved, or their technological capabilities have been expanded beyond their existing capabilities.
Applicant further argues:
The presently recited claims provide specific improvements in technology so as to be limited to a practical application that improves over prior systems. There is a technical problem in a technical field noted at ¶¶ [0004]-[0005] of the present application. Indeed, the application describes that conventional systems and processes do not standardize data in manner for UI data entry and security order form filling related to digital asset processing, such as transfer notices and security orders. See Arguments, p. 9.
The Examiner respectfully disagrees.
Even if “conventional systems and processes “do not standardize data in [a] manner for UI data entry and security order form filling” that does not necessarily equate to a technical problem (i.e., a technology-based problem) wherein existing computer technology is incapable of standardizing data in a manner for UI data entry and security order form filling.
The court in Electric Power Group LLC v. Alstom SA (Fed. Cir. 2016) stated:
The claims here are unlike the claims in Enfish. There, we relied on the distinction made in Alice between, on one hand, computer-functionality improvements and, on the other, uses of existing computers as tools in aid of processes focused on “abstract ideas” (in Alice, as in so many other § 101 cases, the abstract ideas being the creation and manipulation of legal obligations such as contracts involved in fundamental economic practices). Enfish, 822 F.3d at 1335-36; see Alice, 134 S. Ct. at 2358-59. That distinction, the Supreme Court recognized, has common-sense force even if it may present line-drawing challenges because of the programmable nature of ordinary existing computers. In Enfish, we applied the distinction to reject the § 101 challenge at stage one because the claims at issue focused not on asserted advances in uses to which existing computer capabilities could be put, but on a specific improvement—a particular database technique—in how computers could carry out one of their basic functions of storage and retrieval of data. Enfish, 822 F.3d at 1335-36; see Bascom, 2016 U.S. App. LEXIS 11687, 2016 WL 3514158, at *5; cf. Alice, 134 S. Ct. at 2360 (noting basic storage function of generic computer). The present case is different: the focus of the claims is not on such an improvement in computers as tools, but on certain independently abstract ideas that use computers as tools. see Electric Power Group LLC v. Alstom SA, 119 USPQ2d 1739, 1742 (Fed. Cir. 2016) – emphasis added.
The claimed invention is not an improvement to computer technology or computer functionality. Rather, the claimed invention is applying a computer’s existing capabilities to implement a particular abstract idea. As in Electric Power Group, the focus of the claimed invention is not on an improvement in computers as tools but on improving an abstract idea (i.e., processing transfer notices) that uses computers as tools.
Applicant further argues:
To address the problem, the application notes the improvements to the technical problem at least at ¶¶ [0034], [0043], [0069], [0077], [00115]-[11116], and [00118] of the present application, which, in part, state:
Thus, one or more advantages, technical effects, and/or benefits of the private company securities platform (e.g., and the T&S application or tool thereof) includes increasing computer/communication efficiencies, reducing settlement times, implementing effective and reliable settlements, and unlocking liquidity faster for companies and broker-dealers that is otherwise not currently available or currently performed by conventional services. In this regard, the private company securities platform improves the settlement process in private company trades by completing transaction with increased efficiency (e.g., along a shorter timeline) while instilling confidence in the private markets. See ¶ [0034] of the present application.
... According to one or more embodiments, the private company securities platform utilizes the one or more security orders to support a paying agent process and/or tax reporting process as described herein. For example, by automatically populating legal documents, the private company securities platform reduces errors. Id. at ¶ [0043].
... By automatically storing the standardized order data, the private company securities platform can generate and track documents to reduce misplacing information or requiring rework to sign multiple documents of a same format and substance. Id. at ¶ [00115]. See Arguments, pp. 8-9 – emphasis added.
The Examiner respectfully disagrees.
In DDR Holdings, LLC v. Hotels.com, the U.S. Court of Appeals stated:
As an initial matter, it is true that the claims here are similar to the claims in the cases discussed above in the sense that the claims involve both a computer and the Internet. But these claims stand apart because they do not merely recite the performance of some business practice known from the pre-Internet world along with the requirement to perform it on the Internet. Instead, the claimed solution is necessarily rooted in computer technology in order to overcome a problem specifically arising in the realm of computer networks. See DDR Holdings, LLC v. Hotels.com, 113 USPQ2d 1097, 1106 (Fed. Cir. 2014) – emphasis added.
In the instant case, the problems that the claimed invention is designed to overcome (i.e., reducing settlement times, implementing effective and reliable settlements, unlocking liquidity faster, reducing errors, reducing misplacing of information or reworking) are not problems specifically arising from the realm of computers. These problems are standard business problems that exists outside the realm of computers and existed before the age of computers.
MPEP §2106.04(d) recites:
The courts have also identified limitations that did not integrate a judicial exception into a practical application:
Merely reciting the words “apply it” (or an equivalent) with the judicial exception, or merely including instructions to implement an abstract idea on a computer, or merely using a computer as a tool to perform an abstract idea, as discussed in MPEP § 2106.05(f); [and]
Generally linking the use of a judicial exception to a particular technological environment or field of use, as discussed in MPEP § 2106.05(h).
Examiner asserts that the additional elements amount to merely (1) including instructions to implement an abstract idea on a computer, or merely using a computer as a tool to perform an abstract idea, or alternatively, (2) merely links the use of a judicial exception to a particular technological environment or field of use (i.e., processing forms, wherein the forms are transfer notices and security orders).
§103 Rejection
The §102 and/or §103 Rejection has been rewritten and the prior art remapped to account for the newly amended claim language.
9. Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JASON M BORLINGHAUS whose telephone number is (571)272-6924. The examiner can normally be reached M-F 9-5.
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, Calvin L Hewitt II can be reached on 571-272-6709. 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.
/Jason M. Borlinghaus/Primary Examiner, Art Unit 3692 July 20, 2026
Prosecution Insights