DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
The following is a Non-Final Office Action in response to communications received March 02, 2026. Claim(s) 4, 6-7, 10, 14 and 20. have been canceled. Claims 1-3, 5, 8-9, 11-13 and 15-19 have been amended. No new claims have been added. Therefore, claims 1-3, 5, 8-9, 11-13 and 15-19 are pending and addressed below.
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 has been entered.
Priority
Application No. 16595189 filed 10/07/2019 and having 5 RCE-type filing therein Claims Priority from Provisional Application 62746965 , filed 10/17/2018
Applicant Name/Assignee Information: Comenity LLC
Inventor Name(s): Chilaka, Uchenna; Pontious, Timothy
Response to Arguments/Amendments
Claim Rejections - 35 USC § 101
Applicant's arguments filed 03/02/2026 have been fully considered but they are not persuasive.
In the remarks applicant argues that the amended claims are patent eligible. Applicant points to the Desjardins decision which requires evaluation technical improvements to software/computers which is may not be defined by physical features but rather logical structures and processes. Applicant argues the previous Office actions mis-characterizes with the analysis that the claim limitations merely apply PKI pairs in transaction data and storage systems failing to analyze the specific technical arrangement and therefore, does not apply the directed of Desjardins. Applicant’s argument is not persuasive. The examiner notes that applicant does not identify what technology is improved and how by the arrangement of operations recited in the limitations or specification. The specification makes clear that the focus of the invention is not the improvement to technology but rather improvement to invoice-centric transaction processing using technology to reduces instances of fraud in transactions where separate encrypted containers are used to manage subsets of transaction data with PKI enforced access restrictions (¶ 0021, ¶0024-0025, ¶0037, ¶0040-0044). The specification does not disclose any discussion of particular technical process. The specification only discloses how technology is applied to perform the abstract idea. The rejection is maintained.
In the remarks applicant argues that the amended claims under step 2A prong 1 are not directed toward any enumerated abstract idea as identified by the courts and statute. Applicant argues in light of the Desjardins decision the claim limitations as a whole is directed toward the technical problem of securing private account information in transaction processing applying specific technical architecture. The specific combination of technical elements including receiving separate data streams, first and second bilateral decrypting using private key mechanism, separate container parsing with different formats and access rights, serialized, tagged data stream. Applicant argues the specification discloses the payer-centric model in transactions is susceptible to fraud because anyone who obtains payor account information can use funds of the payer’s account to perform unauthorized transactions, therefore, the combination of the specific architecture improves technology with the use of private/public key of the payor to decrypt data and parse data into appropriate containers hierarchy of a given transaction. The additional process of the payee encrypting transaction data with private/public key sending encrypted transaction data, that is decrypted, parsed into appropriate containers hierarchy for the transaction is not a process directed toward abstract concepts. Accordingly the process as a whole is not directed toward abstract concepts. Applicant’s argument is not persuasive. Improving a transaction process using generic technology with high level functions with an expected outcome or lacking any particular special programming to prevent fraud in a transaction does not improve technology, instead focuses on improvement of the transaction process to mitigate risk. The process claimed is not directed toward improvement to any of the underlying technology. The claimed process is not directed toward improvement or changing the ordinary operations of PKI technology or its application, the claimed containers merely limit the environment in which the data is stored and is not directed toward container technology. The focus of the claim limitations is to received encrypted data, decrypt the data and store transaction data based on PKI that is then transmitted for use in a transaction process that verifies amount due and sent for an invoice and notification sent confirming transaction complete. The examiner maintains that as a whole the claim limitations under step 2A prong 1 is directed toward commercial interactions and mitigation of risk sub-categories of the abstract category of methods of organizing human activity. The rejection is maintained.
In the remarks applicant argues that amended claim 13 clearinghouse architecture is specific with specific implementation. Applicant list “separate storage of encrypted data” where encrypted data is stored into a one or more first and second containers, “party-specific decryption” where the encrypted data is decrypted using generic PKI mechanisms, “invoice storage with integrity verification” where submitted invoice is storage and identified from the decrypted data in the container which a checksum value or digital signature which is specific technical arrangements. Applicant’s argument is not persuasive. The “separate storage” is merely the technical environment applied to store data without any processes directed toward the technical process for storing data in a storage mechanisms. With respect to the “decryption” argument, the claim limitations and specification merely describes the use of PKI to encrypt/decrypt data for use in transaction processes which is prevalent in the field of data encryption for risk mitigation. With respect to the integrity verification argument, applicant is arguing limitations not claimed. The limitations are silent with respect to any technical process with respect to the checksum or signature as claimed. Applicants’ argument is not persuasive. The claim limitations as whole are not directed toward encryption/decryption technology, container technology but rather a transaction process. The examiner maintains that as a whole the claim limitations under step 2A prong 1 is directed toward commercial interactions and mitigation of risk sub-categories of the abstract category of methods of organizing human activity. The rejection is maintained
In the remarks applicant argues that amended claim 19 system architecture is specific with specific implementation. Applicant list “party specific encrypted streams” where the data encrypted format for first portion of transaction data and second encrypted format for second portion of transaction data can be decrypted using PKI technology and “server decryption capability” the server decrypting the first encrypted data and second encrypted data stream into decrypted data with specific technical arrangement. Applicant’s argument is not persuasive. The “party specific encrypted streams” is merely received, the claim limitations do not recite an encryption process. . With respect to the “decryption” argument, the claim limitations and specification merely describes the use of PKI to encrypt/decrypt data for use in transaction processes which is prevalent in the field of data encryption for risk mitigation. The claim limitations as whole are not directed toward encryption/decryption technology but rather a transaction process. The examiner maintains that as a whole the claim limitations under step 2A prong 1 is directed toward commercial interactions and mitigation of risk sub-categories of the abstract category of methods of organizing human activity. The rejection is maintained
In the remarks applicant argues that under step 2A prong 2, the claimed limitation improve computer security technology integrating applying concrete technological implementation providing technological improvement by bilateral architecture resulting in security improvement which converts any alleged abstract idea into a practical application going beyond utilization of PKI encryption/decryption tools. Applicant points to the specification discloses “payer's private account information is never shared with payees in an invoice- centric transaction processed according to the invoice-centric transaction model disclosed herein, the payer's private account information is much more secure than in a conventional, payer-centric transaction. As such, the invoice-centric transaction processing service and model disclosed herein represents a technical improvement with respect to transaction security over conventional, payer- centric transactions” with the solution found in “using separate containers within a hierarchy of containers to manage the subsets of transaction data, transaction processing service 113 may enforce custom-access restrictions”. Applicant argues that in light of Desjardins the previous Office Action the analysis is inconsistent with the guidance. Applicant argues that the previous Office Action analysis use of PKI determination is a decomposed analysis, lacking details of the decryption of data, parsing of data other than recited high level results oriented functions on data manipulation and storage and not evaluated as a whole. Applicant argues the amended limitations recite specific decryption keys used that is not possessed by either party with server private key, separate parsing of each decryption stream into separate containers with different formats and different access rights. Applicant argues the limitations are not high level results oriented functions with specific technical steps in specific technical architecture. Applicant’s argument is not persuasive. The claim limitations do not provide in the specification or in the limitations the technical process for decrypting data using specific party keys using PKI technology lacking any technical details as to the decryption process beyond high level “decrypt” using private key. The parsing is equally high level lacking technical details (see spec ¶ 0043-0044, ¶ 0057, ¶ 0077). With respect with the “container” limitations, the containers are merely applied for use in storing data without any technical processes related to the container technology itself. The rejection is maintained.
Claim Rejections - 35 USC § 103
Applicant's arguments are moot in light of the new ground of rejection that was necessitated by Applicant's amendments. Based on an updated search of the art, a new reference was used in the rejection below
Claim Interpretation
With respect to the limitation “wherein parsing further includes decrypting separately supplied and received portion of the transaction data from each party and maintaining decryption keys held by the transaction processing and not by the parties”, the examiner is interpreting the “maintaining decryption keys held by the transaction processing and not the parties to be that the processing service utilizes the keys to decrypt data stream so that the data stream can be parsed into the appropriate containers.
See specification which discloses in para 0043-0044 “ the payer may utilize its private key and a public key of the transaction processing service 113 to encrypt a subset of transaction data, which may then be sent as an encrypted data stream to the transaction processing service 113 via the transaction interface 123 of the payer. The transaction processing service 113 may then utilize its private key and a public key of the payer to decrypt the encrypted data stream and parse the decrypted data stream into the appropriate containers within a container hierarchy for a given transaction.”…” The transaction processing service 113 may then use its private key and the public key of the payee to decrypt the encrypted data stream and parse the decrypted data stream into the appropriate containers within the container hierarchy for the corresponding transaction.
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-3, 5, 8-9, 11-13 and 15-19 are rejected under 35 U.S.C. § 101 because the instant application is directed to non-patentable subject matter. Specifically, the claims are directed toward at least one judicial exception without reciting additional elements that amount to significantly more than the judicial exception. The rationale for this determination is in accordance with the guidelines of USPTO, applies to all statutory categories, and is explained in detail below.
In reference to Claims 1-3, 5, 8-10 and 11-12:
STEP 1. Per Step 1 of the two-step analysis, the claims are determined to include a method, as in independent Claim 1 and the dependent claims. Such methods fall under the statutory category of "process." Therefore, the claims are directed to a statutory eligibility category.
STEP 2A Prong 1. The claimed invention is directed to an abstract idea without significantly more. Method claim 1 recites a method to 1) receiving data 2) decrypting first data (3) decrypting second data (4) parsing first data into first containers (5) parsing first data into containers second separate container (6) transmitting first and second portion data (7) processing transactions (8) verifying amount due (9) sending notification. The claimed limitations which under its broadest reasonable interpretation, covers performance of the limitation in the mind without any recitation of computer technology.
The specification titled “cloud based transaction processing”, discloses in the background that there is a plethora of technology to mitigate fraud where payers share account details with the payee for transferring funds (¶ 0002-0003). The specification discloses a solution to fraud mitigation with an invoice centric transaction processing service where subsets of data are sent separately by each party of the transaction to the transaction processing service. The payer is asked to confirm an invoice before the transaction is processed where each container of data is encrypted such that each party can only access information that is authorized to access. (¶ 0004). The claim limitations mirror this idea by receiving data, parsing transaction data into containers the containers comprising different formats or encryptions of the data with different access rights. The parsing includes decrypting the received portions of transaction data, processing the transaction on behalf of the parties and verifying the total amount due for an invoice sent by first party matches second party payment amount and then sending a notification to at least one of the parties when transaction is confirmed. The claim limitations merely incorporate an encryption process in order in light the specification to mitigate fraud.
When considered as a whole the claimed subject matter is directed toward a transaction processing. Other than using a generic transaction processing server to function as one of ordinary skill in the art would expect such servers to function, that is perform, inter alia, receiving, parsing, decrypting, maintaining, transaction processing functions. Other than using a generic server, the claimed method describes a process for storing data within containers where the data is decrypted by the server for use in a transaction process. This confirms the specifications explanation of applying technology to mitigate fraud in performing transactions. Based on the claim analysis the limitation describe a scheme for performing a sales activity and fraud mitigation. Such concepts can be found in the abstract category of sales activity and fundamental economic practices. These concepts are enumerated in Section I of the 2019 revised patent subject matter eligibility guidance published in the federal register (84 FR 50) on January 7, 2019) is directed toward abstract category of methods of organizing human activity.
STEP 2A Prong 2: The identified judicial exception is not integrated into a practical application because the claims fail to provide indications of patent eligible subject matter that integrate the alleged abstract idea into a practical application. The additional elements recited in the claim beyond the abstract idea include a “transaction processing server”, first and second “private key”, first and second “public key” and first and second “one or more containers”
The additional element beyond the abstract idea “transaction processing server” to perform the steps “receiving…data”; “parsing …first …data ….into a first one or more containers”, “parsing …second…data in a second one or more containers…” “transmitting…first portion of …transaction data and …second portion …transaction data”; “sending …notification …” which according to the courts have recognized the following computer functions are claimed in a merely generic manner (e.g., at a high level of generality) where technology is merely applied to perform the abstract idea or as insignificant extra-solution activity.
Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network); but see DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245, 1258, 113 USPQ2d 1097, 1106 (Fed. Cir. 2014)
Electronic recordkeeping, Alice Corp. Pty. Ltd. v. CLS Bank Int'l, 573 U.S. 208, 225, 110 USPQ2d 1984 (2014) (creating and maintaining "shadow accounts"); Ultramercial, 772 F.3d at 716, 112 USPQ2d at 1755 (updating an activity log);
Storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93
The claim limitations (receive data…; parsing …first …data ….into a first one or more containers”, “parsing …second…data in a second one or more containers…; transmitting…first portion of …transaction data and …second portion …transaction data and “sending …notification …) are recited at a high level of generality without details of technical implementation and thus are insignificant extra solution activity.
The additional element beyond the abstract idea “transaction processing server” using first “private key” and second “public key” and second “private key and second public key” to perform the operation “decrypting” encrypted first and second data without any technical details is directed toward mere data manipulation. For data, mere “manipulation” of basic mathematical constructs [i.e.,] the paradigmatic ‘abstract idea,’" has not been deemed a transformation. CyberSource v. Retail Decisions, 654 F.3d 1366, 1372 n.2, 99 USPQ2d 1690, 1695 n.2 (Fed. Cir. 2011) (quoting /n re Warmerdam, 33 F.3d 1354, 1355, 1360 (Fed. Cir. 1994). Whether the transformation is extra-solution activity or a field-of-use (/.e., the extent to which (or how) the transformation imposes meaningful limits on the execution of the claimed method steps). A transformation that contributes only nominally or insignificantly to the execution of the claimed method (e.g., in a data gathering step or in a field-of-use limitation) would not provide significantly more (or integrate a judicial exception into a practical application). Mayo, 566 U.S. at 76, 101 USPQ2d at 1967. The Supreme Court disagreed, finding that this step was only a field-of-use limitation and did not provide significantly more than the judicial exception. /d. See MPEP § 2106.05(g) & (h).The method steps “processing the transaction” which comprises verifying a total amount due for an invoice…” is not tied to any technology focusing on the transaction process.
The wherein clause “wherein at least one of the first one or more containers comprises at least one of a different data format, an encoding, or an encryption than at least of the second one or more containers, and wherein the first one or more containers comprise different access rights that the second one or more containers” limits the containers receiving the data passed to different container formats with different access rights. The parsing step does not recite any details related to the different container formats in the parsing step. The access rights is an abstract idea and does not further limit the parsing step.
The functions are is recited as being performed by a generic transaction server at a high-level of generality such that it amounts to no more than applying the exception. Although the claim limitations recite “by a transaction processing server”, to perform the “parsing” function, the claim limitations are silent with respect to technological processes. Taking the claim elements separately, the operation performed by the method at each step of the process is purely in terms of results desired and devoid of implementation of details. This is true with respect to the limitations “parsing …data”, “decrypting …data”, “utilizing” PKI pairs and “processing the transaction” as the claimed limitations do not provide any details on technical implementation of the claimed functions. Technology is not integral to the process as the claimed subject matter is so high level that any generic programming could be applied and the functions could be performed by any known means. Furthermore, the claimed functions do not provide any technology or technical process that could be considered as sufficient to provide a technological implementation or application of/or improvement to this concept (i.e. integrated into a practical application).
When the claims are taken as a whole, as an ordered combination, the combination of limitations 1-5 are directed toward receiving data that is manipulated and stored for a transaction process– a common business practice of data organization and manipulation. The combination of limitations 1-5 and 6-10 are directed toward transmitting the data that has been decrypted and stored for use in a transaction process where the transaction includes verifying total amount due for transaction, and sending notification confirming the completion of the transaction. The combinations of parts is not directed toward any technical process or technological technique or technological solution to a problem rooted in technology. With respect to the parsing limitation, the parsing of the transaction data into containers where the containers have different access rights is merely applying known technology in its ordinary capacity in order to mitigate risk of transaction fraud. Applying container technology to control data access is a known application of such technology and therefore, is generically applied in the transaction process to control data access. The claim limitations do not attempt to change the ordinary operations or capability of container storage processes or capability. The decrypting data portions using a generic computer separately is recited at a high level of functionality without any details as to the technical implementation of the decryption process. The recited operations of the transaction processor is results oriented and is merely being applied in order to perform the abstract idea.
In addition, when the claims are taken as a whole, as an ordered combination, the combination of steps not integrate the judicial exception into a practical application as the claim process fails to impose meaningful limits upon the abstract idea. This is because the claimed subject matter fails to provide additional elements or combination or elements to apply or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception. The functions recited in the claims recite the concept of a transaction process which is a process directed toward a business practice.
The integration of elements do not recite any technology or recite a process that is an attempt to improve upon technology or improve upon computer functionality or capability in how computers carry out one of their basic functions. The integration of elements do not provide a process that allows computers to perform functions that previously could not be performed. The integration of elements do not provide a process which applies a relationship to apply a new way of using an application. The instant application, therefore, still appears only to implement the abstract idea to the particular technological environments apply what generic computer functionality in the related arts. The steps are still a combination made to perform a transaction process and does not provide any of the determined indications of patent eligibility set forth in the 2019 USPTO 101 guidance. The additional steps only add to those abstract ideas using generic functions, and the claims do not show improved ways of, for example, an particular technical function for performing the abstract idea that imposes meaningful limits upon the abstract idea. Moreover, Examiner was not able to identify any specific technological processes that goes beyond merely confining the abstract idea in a particular technological environment, which, when considered in the ordered combination with the other steps, could have transformed the nature of the abstract idea previously identified. Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
STEP 2B; The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because as discussed above with respect to concepts of the abstract idea into a practical application. The additional elements recited in the claim beyond the abstract idea include a “transaction processing server”, first and second “private key”, first and second “public key” and first and second “one or more containers”, the transaction processor server to perform the functions “receiving” data, “decrypting …data”, “parsing” data into “containers”, “transmitting the first and second data portion” for use in processing the transaction process of verifying amount due for transaction completion and transmitting notification of transaction completion is purely conventional and generic as the processing server is employed in a customary manner such that they are insufficient the abstract idea into patent eligible subject matter. Taking the claim elements separately, the function performed by the server at the receiving, parsing and decrypting steps of the process is purely conventional. Using a server for receiving data, parsing data and decrypting data which includes decrypting separately received data and maintaining keys----are some of the most basic functions of a processing server. The use of PKI for data decryption without technical details being applied in its ordinary capacity for its intended use prevalent in the industry. The specification is silent with respect to the technical process for data decryption.
When the claims are taken as a whole, as an ordered combination, the combination of steps does not add “significantly more” by virtue of considering the steps as a whole, as an ordered combination. All of these computer functions are generic, routine, conventional computer activities that are performed only for their conventional uses. See Elec. Power Grp. v. Alstom S.A., 830 F.3d 1350, 1353 (Fed. Cir. 2016). Also see In re Katz Interactive Call Processing Patent Litigation, 639 F.3d 1303, 1316 (Fed. Cir. 2011). Absent a possible narrower construction of the terms “receiving”, “parsing” …”decrypting” and “processing the transaction” ... are functions can be achieved by any general purpose computer without special programming. None of these activities are used in some unconventional manner nor do any produce some unexpected result. Applicants do not contend they invented a decryption process. In short, each step does no more than require a generic server to perform generic computer functions.
As to the data operated upon, "even if a process of collecting and analyzing information is 'limited to particular content' or a particular 'source,' that limitation does not make the collection and analysis other than abstract." SAP America, Inc. v. Invest Pic LLC, 898 F.3d 1161, 1168 (Fed. Cir. 2018). Considered as an ordered combination, the computer components of Applicant’s claimed functions add nothing that is not already present when the steps are considered separately. The sequence of data reception-analysis modification-transmission is equally generic and conventional. See Ultramercial, Inc. v. Hulu, LLC, 772 F.3d 709, 715 (Fed. Cir. 2014) (sequence of receiving, selecting, offering for exchange, display, allowing access, and receiving payment recited as an abstraction), Inventor Holdings, LLC v. Bed Bath & Beyond, Inc., 876 F.3d 1372, 1378 (Fed. Cir. 2017) (sequence of data retrieval, analysis, modification, generation, display, and transmission), Two-Way Media Ltd. v. Comcast Cable Communications, LLC, 874 F.3d 1329, 1339 (Fed. Cir. 2017) (sequence of processing, routing, controlling, and monitoring). The ordered combination of parts does not provide significant more than merely confining a transaction process to a particular technological environment for storing data. The ordering of the steps is therefore ordinary and conventional. The analysis concludes that the claims do not provide an inventive concept because the additional elements recited in the claims do not provide significantly more than the recited judicial exception.
According to 2106.05 well-understood and routine processes to perform the abstract idea is not sufficient to transform the claim into patent eligibility. As evidence the examiner provides:
With respect to the “parsing” limitation, the specification discloses the parsing at a high level with an expected result being applied to manipulate data for storage without any indications of technical structure or specific technical process in order provide indications of patent eligibility.
[0005]… The transaction data is parsed into a hierarchy of containers and the transaction is processed on behalf of the parties using the transaction data corresponding to select containers within
the hierarchy.
[0043]… For example, the payer may utilize its private key and a public key of the transaction
processing service 113 to encrypt a subset of transaction data, which may then be sent as an encrypted data stream to the transaction processing service 113 via the transaction interface 123 of the payer. The transaction processing service 113 may then utilize its private key and a public key of the payer to decrypt the encrypted data stream and parse the decrypted data stream into the appropriate containers within a container hierarchy for a given transaction.
[0044] Similarly, the payee may encrypt its subset of transaction data with its private key and a public key of the transaction processing service 113 and may send the encrypted data stream to the transaction processing service 113 via the payee's transaction interface 123. The transaction processing service 113 may then use its private key and the public key of the payee to decrypt the encrypted data stream and parse the decrypted data stream into the appropriate containers within the container hierarchy for
the corresponding transaction.
[0057] Transaction processing service 113 may confirm that the two separately sent subsets of transaction data match, in particular, that the two separately received transaction identifiers match, and may proceed to parse the subsets of transaction data into various containers within the transaction
container hierarchy….
[0077]… For example, all of the transaction data may be received from just one of the parties or respective subsets of the transaction data can be received from each of the parties. Then, at 220, the transaction service parses the transaction data into containers of a hierarchy. That is, groupings and types associated with the transaction data are identified and assigned to transaction data containers that are separately managed within a hierarchy of the containers. In an example implementation, parsing the transaction data into containers may include encrypting at least a portion of the transaction data within at least one corresponding container…
With respect to PKI pairs utilized the specification discloses:
[0042] Additionally, the transaction processing service 113 may natively store content associated with some containers in an encrypted format without disclosing the decryption key to any party associated with a given transaction. This allows the transaction processing service 113 to store key information associated with a given transaction, such as a dollar amount due or paid, in a secure fashion to prevent fraud.
[0043] The subsets of transaction data may also be provided to the transaction processing service 113 in an encrypted data stream that is specific to each of the parties, such that only the transaction processing service 113 is capable of decrypting the data stream to process the corresponding subset of transaction data into the containers. For example, the payer may utilize its private key and a public key of the transaction processing service 113 to encrypt a subset of transaction data, which may then be sent as an encrypted data stream to the transaction processing service 113 via the transaction interface 123 of the payer. The transaction processing service 113 may then utilize its private key and a public key of the payer to decrypt the encrypted data stream and parse the decrypted
data stream into the appropriate containers within a container hierarchy for a given transaction.
[0044] Similarly, the payee may encrypt its subset of transaction data with its private key and a public key of the transaction processing service 113 and may send the encrypted data stream to the transaction processing service 113 via the payee's transaction interface 123. The transaction processing service 113 may then use its private key and the public key of the payee to decrypt the encrypted data stream and parse the decrypted data stream into the appropriate containers within the container hierarchy for the corresponding transaction.
[0080] At 215, the transaction service decrypts the first subset of transaction data using a private key associated with the transaction service and a public key associated with the first party. At 216, the transaction service decrypts the second subset of transaction data using the private key of the transaction service and a public key associated with the second party. It should be appreciated that the operations at 215 and/or 216 may be prior or subsequent to combining the first and second subsets of transaction data.
See Also US Pub No. 2015/0287030 A1 by Sagady et al- para 0005, para 0019, para 0023, para 0025; US Patent No. 11,075,747 B1 by Holsman – Col 1 lines 1-48; US Pub No. 2021/0157935 A1 by Sood et al- para 0009.
NPL article “What is hierarchical namespace in Microsoft Azure data Lake storage by stack overflow” which explains container technology known in the art- Hierarchical storage simply stores a collection of data and files organizing them into a tree/nested folders for efficient data access. It is known in the art in data storage that hierarchical data storage allows for single entry/file access. This type of file system is well understood by one of ordinary skill in the art.
The instant application, therefore, still appears to only implement the abstract ideas to the particular technological environments using what is generic components and functions in the related arts. The claim is not patent eligible.
The remaining dependent claims—which impose additional limitations—also fail to claim patent-eligible subject matter because the limitations cannot be considered statutory. In reference to claims 2-3, 5, 8-9 and 11-12 these dependent claim have also been reviewed with the same analysis as independent claim 1. Dependent claim 2 is directed toward maintaining data in a container (i.e. storage or ledger) for period of time- common practice in business to apply a storage utility for data. Dependent claim 3 is directed toward enforcing restrictions on data access- mitigation of risk. Dependent claim 5 is directed toward receiving data, determining identifier of first and second received data match and combining first and second transaction data- risk mitigation and sales activity. Dependent claim 8 is directed toward encrypting data within container- risk mitigation. Dependent claim 9 is directed toward providing an invoice for approval- a common business practice. Dependent claim 11 is directed toward requesting third party process transaction and requesting notification to each party transaction completed- a common business practice. Dependent claim 12 is directed toward notifying third party- insignificant extra solution activity. The dependent claim(s) have been examined individually and in combination with the preceding claims, however they do not cure the deficiencies of claim 1. Where all claims are directed to the same abstract idea, “addressing each claim of the asserted patents [is] unnecessary.” Content Extraction & Transmission LLC v. Wells Fargo Bank, Nat 7 Ass ’n, 776 F.3d 1343, 1348 (Fed. Cir. 2014). If applicant believes the dependent claims 2-3, 5, 8-9, 11-12 are directed towards patent eligible subject matter, they are invited to point out the specific limitations in the claim that are directed towards patent eligible subject matter.
In reference to Claims 13 and 15-18:
STEP 1. Per Step 1 of the two-step analysis, the claims are determined to include a method, as in independent Claim 13 and the dependent claims. Such methods fall under the statutory category of "process." Therefore, the claims are directed to a statutory eligibility category.
STEP 2A Prong 1. The claimed invention is directed to an abstract idea without significantly more. Method claim 13 recites a method to 1) organizing data into containers 2) storing data in first one or more containers, 3) storing data is second one or more containers 4) first party encrypts first encrypted transaction data 5) first party sends first encrypted data 6) second party encrypts second encrypted transaction data 7) second party sends second encrypted transaction data 8) decrypting first encrypted data 9) decrypting first encrypted data 10 ) storing invoice submitted 11) identifying an authorization from second party 12) obtaining …first and second portion of decrypted transaction data 13) causing transaction to be processed 9) confirming transaction to be processed 14) causing confirmation transaction completed 15) enforcing access restrictions 16) providing transaction data to first and/or second party after transaction. The claimed limitations which under its broadest reasonable interpretation except for the encrypting step and the recitation of the steps being performed by a generic transaction processing server, covers performance of sales activity.
The specification titled “cloud based transaction processing”, discloses in the background that there is a plethora of technology to mitigate fraud where payers share account details with the payee for transferring funds (¶ 0002-0003). The specification discloses a solution to fraud mitigation with an invoice centric transaction processing service where subsets of data are sent separately by each party of the transaction to the transaction processing service. The payer is asked to confirm an invoice before the transaction is processed where each container of data is encrypted such that each party can only access information that is authorized to access. (¶ 0004). The claim limitations mirror this idea by receiving data, parsing transaction data into containers the containers comprising different formats or encryptions of the data with different access rights. The parsing includes storing the received data into containers used to control transaction data access for use in a transaction. The identifying authorization and obtaining transaction data for use in processing the transaction on behalf of the parties is explicitly directed toward a transaction process. The corresponding confirmation of transaction complete and enforcing data access restrictions as well as the providing of transaction data to first and/or second party of the transaction are all part of the transaction process and sales activity. The claim limitations merely incorporate an encryption process in order in light the specification to mitigate fraud. The claim limitations do not positively recite a decryption process and makes clear that the decryption if implemented is part of the transaction process in risk mitigation when considered in light of the specification.
When considered as a whole the claimed subject matter is directed toward a transaction processing. Other than using a generic transaction processing server to function as one of ordinary skill in the art would expect such servers to function, that is perform, inter alia, data organization and storage, encrypting of data, identifying authorization, obtaining transaction data for use in the transaction, performing the transaction process and confirmation functions. This confirms the specifications explanation of applying technology to mitigate fraud in performing transactions. Based on the claim analysis the limitation describe a scheme for performing a sales activity and fraud mitigation.
These concepts are enumerated in Section I of the 2019 revised patent subject matter eligibility guidance published in the federal register (84 FR 50) on January 7, 2019) is directed toward abstract category of methods of organizing human activity.
STEP 2A Prong 2: The identified judicial exception is not integrated into a practical application because the claims fail to provide indications of patent eligible subject matter that integrate the alleged abstract idea into a practical application. The additional elements recited in the claim beyond the abstract idea include a “transaction clearinghouse server”, “transaction processing service”, first and second “private key”, first and second processing service “public key” and first and second “one or more containers”
The additional element beyond the abstract idea “transaction clearinghouse server” to perform the steps “storing …first …data into a first one or more containers”, “storing …second… data into a second one or more containers”, “obtaining …first portion of first and second data” and “providing…data “
The additional element beyond the abstract idea “transaction processing service” applied to perform the step “storing …invoice submitted” which according to the courts have recognized the following computer functions are claimed in a merely generic manner (e.g., at a high level of generality) where technology is merely applied to perform the abstract idea or as insignificant extra-solution activity.
Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network); but see DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245, 1258, 113 USPQ2d 1097, 1106 (Fed. Cir. 2014)
Electronic recordkeeping, Alice Corp. Pty. Ltd. v. CLS Bank Int'l, 573 U.S. 208, 225, 110 USPQ2d 1984 (2014) (creating and maintaining "shadow accounts"); Ultramercial, 772 F.3d at 716, 112 USPQ2d at 1755 (updating an activity log);
Storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93
The claim limitations (receive data…; parsing …first …data ….into a first one or more containers”, “parsing …second…data in a second one or more containers…; transmitting…first portion of …transaction data and …second portion …transaction data and “sending …notification …) are recited at a high level of generality without details of technical implementation and thus are insignificant extra solution activity.
The additional element beyond the abstract idea “transaction clearinghouse server” applied to perform the step “organizing …transaction data…received” without details of technical implementation for use in a transaction process.
The additional element beyond the abstract idea “transaction clearinghouse server” applied to perform the step “decrypting …first …transaction data” and “decrypting …second transaction data” which is mere data manipulation.
. For data, mere “manipulation” of basic mathematical constructs [i.e.,] the paradigmatic ‘abstract idea,’" has not been deemed a transformation. CyberSource v. Retail Decisions, 654 F.3d 1366, 1372 n.2, 99 USPQ2d 1690, 1695 n.2 (Fed. Cir. 2011) (quoting /n re Warmerdam, 33 F.3d 1354, 1355, 1360 (Fed. Cir. 1994). Whether the transformation is extra-solution activity or a field-of-use (/.e., the extent to which (or how) the transformation imposes meaningful limits on the execution of the claimed method steps). A transformation that contributes only nominally or insignificantly to the execution of the claimed method (e.g., in a data gathering step or in a field-of-use limitation) would not provide significantly more (or integrate a judicial exception into a practical application). Mayo, 566 U.S. at 76, 101 USPQ2d at 1967. The Supreme Court disagreed, finding that this step was only a field-of-use limitation and did not provide significantly more than the judicial exception. /d. See MPEP § 2106.05(g) & (h).The method steps “processing the transaction” which comprises verifying a total amount due for an invoice…” is not tied to any technology focusing on the transaction process.
The additional element “transaction clearinghouse server” applied to perform the method steps “causing a confirmation indicating …transaction was completed” comprising “enforcing …access restriction on request for access”, which is merely applying technology to enforce transaction access restrictions for transaction process.
The steps the “first party encrypts …first encrypted transaction data utilizes first party payer private key and transaction processing service public key”, the first party sends the first encrypted transaction message”, “second party encrypts …second encrypted transaction data utilizes second party payer private key and transaction processing service public key”, the second party sends the second encrypted transaction message”, “identifying an authorization from the second party”, “causing the transaction to be processed …using …first…and second transaction data is not tied to any technology.
The wherein clause “wherein each container comprises a respective party-specific portion of the transaction data associated with a corresponding container-defined data format or corresponding container- defined access rights” does not further limit the storing of the data, instead the wherein claimed limits the format as corresponding to the container which is broad without technical details or as data stored according to corresponding contained defined access rights which is a business concept and not technology.
The functions are is recited at a high-level of generality such that it amounts to no more than applying the exception. The claim limitations are silent with respect to details on technical implementation. Taking the claim elements separately, the operation performed by the method at each step of the process is purely in terms of results desired and devoid of implementation of details. This is true with respect to the limitations “organizing data into containers”, “encrypted formats”, “identifying” authorization, “obtaining” data, “utilizing” PKI pairs, “causing transaction to be processed”, “causing confirmation”, “enforcing” access and “providing” data as the claimed limitations do not provide any details on how technology to perform the recited functions. Technology is not integral to the process as the claimed subject matter is so high level that any generic programming and server could be applied and the functions could be performed by any known means. Furthermore, the claimed functions do not provide any technology or technical process that could be considered as sufficient to provide a technological implementation or application of/or improvement to this concept (i.e. integrated into a practical application).
When the claims are taken as a whole, as an ordered combination, the combination of limitations 1-7 is directed toward organizing transaction data received where the data is stored and encrypted data storage containers where the received data is encrypted and setn to the transaction service– a common business practice data encrypting received transaction data to mitigate risk and storing the transaction data that is sent to a processing services. The combination of limitations 8-10 are directed toward decrypting using PKI technology and storing encrypted transaction data sent in the combination of limitations 1-7. The combination of limitations 11-14 is directed toward a transaction process including identifying authorization, obtaining decrypted transaction data of limitations 1-10, processing transaction and confirming transaction completed. The combination of limitations 15-16 as a combination is directed toward applying the transaction clearing server to perform the abstract idea of enforcing access restrictions on data stored in containers lacking any technical details and providing the first and second portions of transaction data after transaction completed of limitations 1-14 based on access rights of limitations 15-16. The combinations of parts is not directed toward any technical process or technological technique or technological solution to a problem rooted in technology.
In addition, when the claims are taken as a whole, as an ordered combination, the combination of steps not integrate the judicial exception into a practical application as the claim process fails to impose meaningful limits upon the abstract idea. This is because the claimed subject matter fails to provide additional elements or combination or elements to apply or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception. The functions recited in the claims recite the concept of a transaction process which is a process directed toward a business practice. The operations of the recited server are high level without details of technical implementation and merely calls for the server to receive and store transaction data that is used for a transaction process where access to data for use in the transaction is restricted based on rights. Accordingly the focus of claim 13 is not on solving a problem rooted in technology or to provide improvements to the functions or capability unique to “transaction processing server” or the use of “containers” to store data. The claim limitations and specifications do not point to any processes which would cause the functions as claimed to affect the normal operation of servers or the storing of data using containers in a hierarchical structure. The analysis above makes clear that the server and storing of data within containers lacks technical details on how the functions are performed, notwithstanding the generic server employed. Claim 13 consist solely of result oriented functional language omitting any specific requirements as to how the steps of organizing, encrypting are performed.
The integration of elements do not recite any technology or recite a process that is an attempt to improve upon technology or improve upon computer functionality or capability in how computers carry out one of their basic functions. The integration of elements do not provide a process that allows computers to perform functions that previously could not be performed. The integration of elements do not provide a process which applies a relationship to apply a new way of using an application. The instant application, therefore, still appears only to implement the abstract idea to the particular technological environments apply what generic computer functionality in the related arts. The steps are still a combination made to perform a transaction process and does not provide any of the determined indications of patent eligibility set forth in the 2019 USPTO 101 guidance. The additional steps only add to those abstract ideas using generic functions, and the claims do not show improved ways of, for example, an particular technical function for performing the abstract idea that imposes meaningful limits upon the abstract idea. Moreover, Examiner was not able to identify any specific technological processes that goes beyond merely confining the abstract idea in a particular technological environment, which, when considered in the ordered combination with the other steps, could have transformed the nature of the abstract idea previously identified. Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
STEP 2B; The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because as discussed above with respect to concepts of the abstract idea into a practical application. The additional elements recited in the claim beyond the abstract idea include a “transaction clearinghouse server”, “transaction processing service”, first and second “private key”, first and second processing service “public key” and first and second “one or more containers” The clearinghouse server applied to perform the steps “organizing …data”, “storing …data”, “decrypting …data”, “obtaining …data’, “enforcing …access rights”, “providing …data” and the additional element “processing service” to perform the step “storing …data” -some of the most basic functions of a processing server. The additional limitations include using PKI pair technology to encrypt and de-encrypt data is purely conventional and generic as the processing server is employed in a customary manner such that they are insufficient the abstract idea into patent eligible subject matter. Taking the claim elements separately, the function performed by the server at the receiving and parsing step of the process is purely conventional. With respect to the decrypting of data by the server both the claim limitations and specification is silent with respect to the technical process for data decryption.
When the claims are taken as a whole, as an ordered combination, the combination of steps does not add “significantly more” by virtue of considering the steps as a whole, as an ordered combination. All of these computer functions are generic, routine, conventional computer activities that are performed only for their conventional uses. See Elec. Power Grp. v. Alstom S.A., 830 F.3d 1350, 1353 (Fed. Cir. 2016). Also see In re Katz Interactive Call Processing Patent Litigation, 639 F.3d 1303, 1316 (Fed. Cir. 2011). Absent a possible narrower construction of the terms “organizing”, “identifying”, “obtaining”, causing transaction to be processed” and “causing confirmation indicating transaction complete”.. are functions can be achieved by any general purpose computer without special programming. None of these activities are used in some unconventional manner nor do any produce some unexpected result. Applicants do not contend they invented a decryption keys or process. In short, each step does no more than require a generic server to perform generic computer functions.
As to the data operated upon, "even if a process of collecting and analyzing information is 'limited to particular content' or a particular 'source,' that limitation does not make the collection and analysis other than abstract." SAP America, Inc. v. Invest Pic LLC, 898 F.3d 1161, 1168 (Fed. Cir. 2018). Considered as an ordered combination, the computer components of Applicant’s claimed functions add nothing that is not already present when the steps are considered separately. The sequence of data reception-analysis modification-transmission is equally generic and conventional. See Ultramercial, Inc. v. Hulu, LLC, 772 F.3d 709, 715 (Fed. Cir. 2014) (sequence of receiving, selecting, offering for exchange, display, allowing access, and receiving payment recited as an abstraction), Inventor Holdings, LLC v. Bed Bath & Beyond, Inc., 876 F.3d 1372, 1378 (Fed. Cir. 2017) (sequence of data retrieval, analysis, modification, generation, display, and transmission), Two-Way Media Ltd. v. Comcast Cable Communications, LLC, 874 F.3d 1329, 1339 (Fed. Cir. 2017) (sequence of processing, routing, controlling, and monitoring). The ordered combination of parts does not provide significant more than merely confining a transaction process to a particular technological environment for storing data. The ordering of the steps is therefore ordinary and conventional. The analysis concludes that the claims do not provide an inventive concept because the additional elements recited in the claims do not provide significantly more than the recited judicial exception.
According to 2106.05 well-understood and routine processes to perform the abstract idea is not sufficient to transform the claim into patent eligibility. As evidence the examiner provides:
With respect to the “decryption” as claimed the specification discloses common public-private key for parties.
[0042] Additionally, the transaction processing service 113 may natively store content associated with some containers in an encrypted format without disclosing the decryption key to any party associated with a given transaction. This allows the transaction processing service 113 to store key information associated with a given transaction, such as a dollar amount due or paid, in a secure fashion to prevent fraud.
[0043] The subsets of transaction data may also be provided to the transaction processing service 113 in an encrypted data stream that is specific to each of the parties, such that only the transaction processing
service 113 is capable of decrypting the data stream to process the corresponding subset of transaction data into the containers. For example, the payer may utilize its private key and a public key of the transaction processing service 113 to encrypt a subset of transaction data, which may then be sent as an encrypted data stream to the transaction processing service 113 via the transaction interface 123 of the payer. The transaction processing service 113 may then utilize its private key and a public key of
the payer to decrypt the encrypted data stream and parse the decrypted data stream into the appropriate containers within a container hierarchy for a given transaction.
[0044] Similarly, the payee may encrypt its subset of transaction data with its private key and a public key of the transaction processing service 113 and may send the encrypted data stream to the transaction processing service 113 via the payee's transaction interface 123. The transaction processing service 113 may then use its private key and the public key of the payee to decrypt the encrypted data stream and parse the decrypted data stream into the appropriate containers within the container hierarchy for
the corresponding transaction.
[0045]… For example, a payer may encrypt a private account identifier that the payee cannot decrypt, but which payee can forward to the transaction processing service 113, which in turn, can decrypt the account identifier to facilitate payment for the transaction.
[00101] In an embodiment, at 360 (shown in FIG. 3A), the transaction clearinghouse service maintains a first encryption/decryption key for the transaction data of the first party and maintains a second encryption/decryption key for the transaction data of the second party…
With respect to PKI pairs utilized the specification discloses:
[0042] Additionally, the transaction processing service 113 may natively store content associated with some containers in an encrypted format without disclosing the decryption key to any party associated with a given transaction. This allows the transaction processing service 113 to store key information associated with a given transaction, such as a dollar amount due or paid, in a secure fashion to prevent fraud.
[0043] The subsets of transaction data may also be provided to the transaction processing service 113 in an encrypted data stream that is specific to each of the parties, such that only the transaction processing service 113 is capable of decrypting the data stream to process the corresponding subset of transaction data into the containers. For example, the payer may utilize its private key and a public key of the transaction processing service 113 to encrypt a subset of transaction data, which may then be sent as an encrypted data stream to the transaction processing service 113 via the transaction interface 123 of the payer. The transaction processing service 113 may then utilize its private key and a public key of the payer to decrypt the encrypted data stream and parse the decrypted
data stream into the appropriate containers within a container hierarchy for a given transaction.
[0044] Similarly, the payee may encrypt its subset of transaction data with its private key and a public key of the transaction processing service 113 and may send the encrypted data stream to the transaction processing service 113 via the payee's transaction interface 123. The transaction processing service 113 may then use its private key and the public key of the payee to decrypt the encrypted data stream and parse the decrypted data stream into the appropriate containers within the container hierarchy for the corresponding transaction.
[0080] At 215, the transaction service decrypts the first subset of transaction data using a private key associated with the transaction service and a public key associated with the first party. At 216, the transaction service decrypts the second subset of transaction data using the private key of the transaction service and a public key associated with the second party. It should be appreciated that the operations at 215 and/or 216 may be prior or subsequent to combining the first and second subsets of transaction data.
NPL article “What is hierarchical namespace in Microsoft Azure data Lake storage by stack overflow” which explains container technology known in the art- Hierarchical storage simply stores a collection of data and files organizing them into a tree/nested folders for efficient data access. It is known in the art in data storage that hierarchical data storage allows for single entry/file access. This type of file system is well understood by one of ordinary skill in the art.
The instant application, therefore, still appears to only implement the abstract ideas to the particular technological environments using what is generic components and functions in the related arts. The claim is not patent eligible.
The remaining dependent claims—which impose additional limitations—also fail to claim patent-eligible subject matter because the limitations cannot be considered statutory. In reference to claims 15-18 these dependent claim have also been reviewed with the same analysis as independent claim 13. Dependent claim 15 are directed toward organizing and receiving encrypted data – a common business practice and insignificant extra solution activity. Dependent claim 16 is directed toward receiving data and identifying an invoice, receiving transaction data iteratively, decrypting data, assembling final invoice and providing final invoice - a common business practice. Dependent claim 17 is directed toward identifying an invoice, providing an invoice in format viewed and receiving authorization- sales activity and a common use of technology in business practice. Dependent claim 18 is directed toward encrypting the first and second party public key using third key pair and inserting encrypted version in container – risk mitigation- a common business practice. The dependent claim(s) have been examined individually and in combination with the preceding claims, however they do not cure the deficiencies of claim 13. Where all claims are directed to the same abstract idea, “addressing each claim of the asserted patents [is] unnecessary.” Content Extraction & Transmission LLC v. Wells Fargo Bank, Nat 7 Ass ’n, 776 F.3d 1343, 1348 (Fed. Cir. 2014). If applicant believes the dependent claims 15-18 are directed towards patent eligible subject matter, they are invited to point out the specific limitations in the claim that are directed towards patent eligible subject matter.
In reference to Claims 19:
STEP 1. Per Step 1 of the two-step analysis, the claims are determined to include a system, as in independent Claim 19. Such systems fall under the statutory category of "machine." Therefore, the claims are directed to a statutory eligibility category.
STEP 2A Prong 1. The claimed invention is directed to an abstract idea without significantly more. System claim 19 recites a functional process to 1) identify transaction between parties 2) identify transaction data 3)maintaining first portion and second portion transaction data (4) receiving first and second portions encrypted data (5) segmenting transaction data into containers/storage (5) transmitting first and second portion of transaction data (6) receiving authorization (7) causing transaction to be completed (8) causing notification sent (8) providing decryption transaction data.
The claimed limitations which under its broadest reasonable interpretation except for the encrypting step and the recitation of the steps being performed by a generic server processor, covers performance of a sales transaction.
The specification titled “cloud based transaction processing”, discloses in the background that there is a plethora of technology to mitigate fraud where payers share account details with the payee for transferring funds (¶ 0002-0003). The specification discloses a solution to fraud mitigation with an invoice centric transaction processing service where subsets of data are sent separately by each party of the transaction to the transaction processing service. The payer is asked to confirm an invoice before the transaction is processed where each container of data is encrypted such that each party can only access information that is authorized to access. (¶ 0004). The claim limitations mirror this idea by receiving data, parsing transaction data into containers the containers comprising different formats or encryptions of the data with different access rights. The parsing includes storing the received data into containers used to control transaction data access for use in a transaction. The identifying authorization and obtaining transaction data for use in processing the transaction on behalf of the parties is explicitly directed toward a transaction process. The corresponding confirmation of transaction complete and enforcing data access restrictions as well as the providing of transaction data to first and/or second party of the transaction are all part of the transaction process and sales activity. The claim limitations merely incorporate an encryption process in order in light the specification to mitigate fraud. The claim limitations do not positively recite a decryption process and makes clear that the decryption if implemented is part of the transaction process in risk mitigation when considered in light of the specification.
The claimed limitations which under its broadest reasonable interpretation, covers performance a transaction. This is because the identifying a transaction between parties and transaction data associated with the transaction is explicitly directed toward a transaction/sales activity. The following functions where the processor segments and stores the received encrypted transaction data into containers with an access rights hierarchy is directed toward storing transaction data and controlling rights to access the data is a business practice in risk mitigation and transaction processes. The next limitations are directed toward authorization to process the transaction and completing the transaction which explicitly directed toward a transaction process. The final functions of the transaction performed by the transaction processor or to cause a notification to be sent when the transaction is completed and controlling the data requested according to access rights assigned and providing the data based on those rights which is a common business practice in protecting user PII and other sensitive account data in transaction processing. Therefore, when considered as a whole, pulling the claimed functions performed by the processor, one of ordinary skill in the art would recognize that the claim limitations are directed toward risk mitigation in a transaction process.
Such concepts can be found in the abstract category of commercial interactions and marketing. These concepts are enumerated in Section I of the 2019 revised patent subject matter eligibility guidance published in the federal register (84 FR 50) on January 7, 2019) is directed toward abstract category of methods of organizing human activity.
STEP 2A Prong 2: The identified judicial exception is not integrated into a practical application because the claims fail to provide indications of patent eligible subject matter that integrate the alleged abstract idea into a practical application. The additional elements recited in the claim beyond the abstract idea include a “system “ comprising “a server comprising at least one processor and a non-transitory computer readable storage medium”, “a non-transitory computer readable storage medium comprising server executable instructions” cause the “one processor of the server to perform operations“ and a “server”
The additional element beyond the abstract idea include a “server” applied to perform the function “receiving first and second portion transaction data”, “transmitting first and second portion decrypted transaction data”, “receiving authorization to process transaction”, “causing notification to be sent” and “providing transaction data” which according to the courts have recognized the following computer functions are claimed in a merely generic manner (e.g., at a high level of generality) where technology is merely applied to perform the abstract idea or as insignificant extra-solution activity.
Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network); but see DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245, 1258, 113 USPQ2d 1097, 1106 (Fed. Cir. 2014)
Electronic recordkeeping, Alice Corp. Pty. Ltd. v. CLS Bank Int'l, 573 U.S. 208, 225, 110 USPQ2d 1984 (2014) (creating and maintaining "shadow accounts"); Ultramercial, 772 F.3d at 716, 112 USPQ2d at 1755 (updating an activity log);
Storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93
The claim limitations (receive data…; parsing …first …data ….into a first one or more containers”, “parsing …second…data in a second one or more containers…; transmitting…first portion of …transaction data and …second portion …transaction data and “sending …notification …) are recited at a high level of generality without details of technical implementation and thus are insignificant extra solution activity.
The additional computer element beyond the abstract idea includes a “server” performing the operation “identifying …a transaction between” parties fails to provide any technical details, instead applying the server to analyze transaction data.
The additional computer element beyond the abstract idea includes a server applied to “enforce access restrictions on a request to access first and second transaction data” which is merely applying technology to mitigate risk. .
The operation “identifying transaction data”, “maintaining first and second portion of transaction data”, “causing the transaction to be completed”, “causing the notification to be sent” is not tied to any technology. The wherein clause does not further limit the cause confirming indications transaction completed but rather limits the enforcement of access restrictions of data of the container – which is a mitigation of risk; The functions are is recited at a high-level of generality such that it amounts to no more than applying the exception using generic computer components. Taking the claim elements separately, the operation performed by the system at each step of the process is purely in terms of results desired and devoid of implementation of details. This is true with respect to the limitations “segmenting …data into containers having a corresponding container hierarchy, where containers comprise different data formats, encodings/encryptions and different access rights as the claimed components of the limitation do not provide any details as to the technology or technical process needed to perform the recited functions. Technology is not integral to the process as the claimed subject matter is so high level that any generic programming could be applied and the functions could be performed by any known means. Furthermore, the claimed functions do not provide an operation that could be considered as sufficient to provide a technological implementation or application of/or improvement to this concept (i.e. integrated into a practical application).
When the claims are taken as a whole, as an ordered combination, the combination of limitations 1-6 is directed toward a transaction process. The combination of limitations 1-6 and 7-9 are directed toward directed toward a transaction process and sending a corresponding notification and providing data based on access rights- a common business practice. The combinations of parts is not directed toward any technical process or technological technique or technological solution to a problem rooted in technology.
In addition, when the claims are taken as a whole, as an ordered combination, the combination of steps not integrate the judicial exception into a practical application as the claim process fails to impose meaningful limits upon the abstract idea. . This is because the claimed subject matter fails to provide additional elements or combination or elements to apply or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception. The functions recited in the claims recite the concept of a transaction completion which is a process directed toward a business practice. The analysis of the claim concludes the claim limitations still “simply recite actions in a generic way” (e.g., identify transaction, identify transaction data, segmenting transaction data into containers/storage, receiving authorization, causing transaction to be completed, causing notification sent) and “do not purport to improve any underlying technology.” The wherein clause “wherein the separate portions are received in party-specific encrypted formats …that the server can decrypt using private keys” is directed toward the data acted upon and not on the preceding identifying step. The wherein clause “wherein subsets of transaction data are provided to a transaction processing service in an encrypted data stream that is specific to each of the first party and the second party, such that only the transaction processing service is capable of decrypting the encrypted data stream to process a corresponding subset of transaction data into containers” limits the data acted upon and does not further limit the preceding identifying step.
The integration of elements do not improve upon technology or improve upon computer functionality or capability in how computers carry out one of their basic functions. The integration of elements do not provide a process that allows computers to perform functions that previously could not be performed. The integration of elements do not provide a process which applies a relationship to apply a new way of using an application. The instant application, therefore, still appears only to implement the abstract idea to the particular technological environments apply what generic computer functionality in the related arts. The steps are still a combination made to complete a transaction and does not provide any of the determined indications of patent eligibility set forth in the 2019 USPTO 101 guidance. The additional steps only add to those abstract ideas using generic functions, and the claims do not show improved ways of, for example, an particular technical function for performing the abstract idea that imposes meaningful limits upon the abstract idea. Moreover, Examiner was not able to identify any specific technological processes that goes beyond merely confining the abstract idea in a particular technological environment, which, when considered in the ordered combination with the other steps, could have transformed the nature of the abstract idea previously identified. Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
STEP 2B; The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because as discussed above with respect to concepts of the abstract idea into a practical application. The additional elements recited in the claim beyond the abstract idea include a “system “ comprising “a server comprising at least one processor and a non-transitory computer readable storage medium”, “a non-transitory computer readable storage medium comprising server executable instructions” cause the “one processor of the server to perform operations“ and a “server”. The server applied to executes instruction to cause the processor to perform the operations -. –is purely functional and generic. Nearly every system will include a “a server, at least one processor, a non-transitory computer readable medium comprising instructions where the server executes instructions to perform the operations required by the system claims . . . As a result, none of the hardware recited by the system claims offers a meaningful limitation beyond generally linking the use of the method to a particular technological environment, that is, implementation via computers.
Taking the claim elements separately, the function performed by the computer at each step of the process is purely conventional. Using a processor to perform the operations “identify transaction”, “identify transaction data”, “segmenting transaction data into containers/storage”, “receiving authorization”, “causing transaction to be complete” and “causing notification sent” ----are some of the most basic functions of a computer. When the claims are taken as a whole, as an ordered combination, the combination of steps does not add “significantly more” by virtue of considering the steps as a whole, as an ordered combination. All of these computer functions are generic, routine, conventional computer activities that are performed only for their conventional uses. See Elec. Power Grp. v. Alstom S.A., 830 F.3d 1350, 1353 (Fed. Cir. 2016). Also see In re Katz Interactive Call Processing Patent Litigation, 639 F.3d 1303, 1316 (Fed. Cir. 2011) Absent a possible narrower construction of the terms “identifying”, “maintaining”, “segmenting”, “receiving”, “causing notification” ... are functions can be achieved by any general purpose computer without special programming"). None of these activities are used in some unconventional manner nor do any produce some unexpected result. Applicants do not contend they invented any of these activities. In short, each step does no more than require a generic computer to perform generic computer functions.
As to the data operated upon, "even if a process of collecting and analyzing information is 'limited to particular content' or a particular 'source,' that limitation does not make the collection and analysis other than abstract." SAP America, Inc. v. Invest Pic LLC, 898 F.3d 1161, 1168 (Fed. Cir. 2018). Considered as an ordered combination, the computer components of Applicant’s claimed functions add nothing that is not already present when the steps are considered separately. The sequence of data reception-analysis modification-transmission is equally generic and conventional. See Ultramercial, Inc. v. Hulu, LLC, 772 F.3d 709, 715 (Fed. Cir. 2014) (sequence of receiving, selecting, offering for exchange, display, allowing access, and receiving payment recited as an abstraction), Inventor Holdings, LLC v. Bed Bath & Beyond, Inc., 876 F.3d 1372, 1378 (Fed. Cir. 2017) (sequence of data retrieval, analysis, modification, generation, display, and transmission), Two-Way Media Ltd. v. Comcast Cable Communications, LLC, 874 F.3d 1329, 1339 (Fed. Cir. 2017) (sequence of processing, routing, controlling, and monitoring). The ordering of the steps is therefore ordinary and conventional. The analysis concludes that the claims do not provide an inventive concept because the additional elements recited in the claims do not provide significantly more than the recited judicial exception.
According to 2106.05 well-understood and routine processes to perform the abstract idea is not sufficient to transform the claim into patent eligibility. As evidence the examiner provides:
The specification discloses computer components in para 0032-0034, configured to process transaction para 0035.
EP 3317775 B1 by Zinder; US Pub No. 2022/0318752 A1 by Bailey et al; US Pub No. 2017/0364552 A1 by Pattanaik et al- are cited for teaching transaction processes in a blockchain environment were data elements are segmented according to hierarchy.
With respect to the “decryption” as claimed the specification discloses common public-private key for parties.
[0042] Additionally, the transaction processing service 113 may natively store content associated with some containers in an encrypted format without disclosing the decryption key to any party associated with a given transaction. This allows the transaction processing service 113 to store key information associated with a given transaction, such as a dollar amount due or paid, in a secure fashion to prevent fraud.
[0043] The subsets of transaction data may also be provided to the transaction processing service 113 in an encrypted data stream that is specific to each of the parties, such that only the transaction processing
service 113 is capable of decrypting the data stream to process the corresponding subset of transaction data into the containers. For example, the payer may utilize its private key and a public key of the transaction processing service 113 to encrypt a subset of transaction data, which may then be sent as an encrypted data stream to the transaction processing service 113 via the transaction interface 123 of the payer. The transaction processing service 113 may then utilize its private key and a public key of
the payer to decrypt the encrypted data stream and parse the decrypted data stream into the appropriate containers within a container hierarchy for a given transaction.
[0044] Similarly, the payee may encrypt its subset of transaction data with its private key and a public key of the transaction processing service 113 and may send the encrypted data stream to the transaction processing service 113 via the payee's transaction interface 123. The transaction processing service 113 may then use its private key and the public key of the payee to decrypt the encrypted data stream and parse the decrypted data stream into the appropriate containers within the container hierarchy for
the corresponding transaction.
[0045]… For example, a payer may encrypt a private account identifier that the payee cannot decrypt, but which payee can forward to the transaction processing service 113, which in turn, can decrypt the account identifier to facilitate payment for the transaction.
[00101] In an embodiment, at 360 (shown in FIG. 3A), the transaction clearinghouse service maintains a first encryption/decryption key for the transaction data of the first party and maintains a second encryption/decryption key for the transaction data of the second party…
With respect to PKI pairs utilized the specification discloses:
[0042] Additionally, the transaction processing service 113 may natively store content associated with some containers in an encrypted format without disclosing the decryption key to any party associated with a given transaction. This allows the transaction processing service 113 to store key information associated with a given transaction, such as a dollar amount due or paid, in a secure fashion to prevent fraud.
[0043] The subsets of transaction data may also be provided to the transaction processing service 113 in an encrypted data stream that is specific to each of the parties, such that only the transaction processing service 113 is capable of decrypting the data stream to process the corresponding subset of transaction data into the containers. For example, the payer may utilize its private key and a public key of the transaction processing service 113 to encrypt a subset of transaction data, which may then be sent as an encrypted data stream to the transaction processing service 113 via the transaction interface 123 of the payer. The transaction processing service 113 may then utilize its private key and a public key of the payer to decrypt the encrypted data stream and parse the decrypted
data stream into the appropriate containers within a container hierarchy for a given transaction.
[0044] Similarly, the payee may encrypt its subset of transaction data with its private key and a public key of the transaction processing service 113 and may send the encrypted data stream to the transaction processing service 113 via the payee's transaction interface 123. The transaction processing service 113 may then use its private key and the public key of the payee to decrypt the encrypted data stream and parse the decrypted data stream into the appropriate containers within the container hierarchy for the corresponding transaction.
[0080] At 215, the transaction service decrypts the first subset of transaction data using a private key associated with the transaction service and a public key associated with the first party. At 216, the transaction service decrypts the second subset of transaction data using the private key of the transaction service and a public key associated with the second party. It should be appreciated that the operations at 215 and/or 216 may be prior or subsequent to combining the first and second subsets of transaction data.
NPL article “What is hierarchical namespace in Microsoft Azure data Lake storage by stack overflow” which explains container technology known in the art- Hierarchical storage simply stores a collection of data and files organizing them into a tree/nested folders for efficient data access. It is known in the art in data storage that hierarchical data storage allows for single entry/file access. This type of file system is well understood by one of ordinary skill in the art.
The instant application, therefore, still appears to only implement the abstract ideas to the particular technological environments using what is generic components and functions in the related arts. The claim is not patent eligible.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1-3 and 8 is/are rejected under 35 U.S.C. 103 as being unpatentable over US Patent No. 11,514,448 B1 by Liberman (Liberman) in view of US Pub No. 2019/0340251 A1 by Peddada et al. (Peddada) and further in view of US Pub No. 2006/0015363 A1 by Allu et al (Allu)
In reference to Claim 1:
Liberman teaches:
(Currently Amended) A method ((Liberman) in at least Fig. 8; Col 42 lines 56-Col 43 lines 1-50), comprising:
receiving by a transaction processing server, first encrypted transaction data associated with a first party and second encrypted transaction data associated with a second party to a transaction ((Liberman) in at least Fig. 8; Col 39 lines 28-35, Col 40 lines 30-45, Col 42 lines 57-Col 43 lines 1-7); …
parsing, by the transaction processing server, the first decrypted transaction data into a first one or more containers of a container hierarchy ((Liberman) in at least Col 2 lines 34-37 wherein the prior art teaches database structure to contain data to enable access management; lines 47-52 wherein the prior art teaches information organized using particular format, protocol for storing data, Col 7 lines 20-25 wherein the prior art teaches rules via the consensus protocol which specify participation access and validation protocols; Col 9 lines 60-Col 10 lines 1-9, Col 10 lines 21-30 wherein the prior art teaches applying different consensus protocols for each data segment; lines 51 lines 51-Col 12 lines 1-3 wherein the prior art teaches defined data formats with each substrate include validation rules and data store consist of independent containers arranged in hierarchical arrangement and each substrate may be permissioned or feature restriction participation, lines 61-1-9, Col 13 lines 35-44, Col 14 lines 1-13 wherein the prior art teaches shared substrate encryption, Col 15 lines 4-18, lines 27-39, Col 16 lines 49-Col 17 lines 1-26, Col 19 lines 5-63 wherein the prior art teaches validation feature includes use of encryption for true per missioning for data delivery, Col 20 lines 14-44, Col 21 lines 49-Col 22 lines 1-37 wherein the prior art teaches sending data in a specified format in the substrate definition, Col 23 lines 57-67, Col 25 lines 65-Col 26 lines 1-4, Col 35 lines 7-31, Col 36 lines 56-Col 37 lines 1-26, Col 39 lines 28-35);
wherein at least one of the first one or more containers comprises at least one of a different data format, an encoding, or an encryption than at least of the second one or more containers, and wherein the first one or more containers comprise different access rights that the second one or more containers ((Liberman) in at least Col 2 lines 34-37 wherein the prior art teaches database structure to contain data to enable access management; lines 47-52 wherein the prior art teaches information organized using particular format, protocol for storing data, Col 7 lines 20-25 wherein the prior art teaches rules via the consensus protocol which specify participation access and validation protocols; Col 9 lines 60-Col 10 lines 1-9, Col 10 lines 21-30 wherein the prior art teaches applying different consensus protocols for each data segment, Col 21 lines 49-Col 22 lines 1-37 wherein the prior art teaches sending data in a specified format in the substrate definition); …
processing the transaction on behalf of the first party and the second party parties using the stream of transaction data ((Liberman) in at least Col 11 lines 47-Col 12 lines 1-2, Col 43 lines 15-Col 44 lines 1-3, Col 42 lines 40-48, Col 47 lines 49-Col 48 lines 1-5);…
Liberman suggest but does not explicitly teach:
decrypting, by the transaction processing server, the second encrypted transaction data using the private key and a second public key associated with the second party to obtain second decrypted transaction data ;((Liberman) in at least Col 2 lines 7-16, Col 19 lines 15-15-21, Col 36 lines 56-Col 37 lines 1-27, Col 49 lines 57-Col 50 lines 1-45 wherein the prior art teaches each ledger for purposes of sending/addressing transaction message data may include private/public keys (for decrypting) associated with all of the each other devices, Col 56 lines 55-60, Col 57 lines 42-43, Col 71 lines 55-59)
Although Liberman does not explicitly teach “second encrypted transaction data using the private key and a second public key associated with the second party...”, the prior art does teach that for each stored transaction data a private/public key process is applied, furthermore, according to MPEP 2144.04, VI, section B, In re Harza, 274 F.2d 669, 124 USPQ 378 (CCPA 1960), the court held that mere duplication of parts has no patentable significance unless a new and unexpected result is produced. Therefore, the duplication of decrypting second encrypted data using second private and public key associated with second party is obvious
Liberman does not explicitly teach:
decrypting, by the transaction processing server, the first encrypted transaction data using a private key that is maintained on the transaction processing server that neither the first party nor the second party possesses, and a first public key associated with the first party to obtain first decrypted transaction data
transmitting, by the transaction processing server, a first portion of the first decrypted transaction data and a second portion of the second decrypted transaction data as a stream of transaction data that is serialized, tagged, or field-defined; and
wherein processing the transaction comprises:
verifying a total amount due for an invoice sent by the first party matches or is less than an authorized payment amount sent by the second party before completing the transaction on behalf of the first party and the second party; and
sending, by the transaction processing server, a notification to at least one of the first party or the second party when the transaction is confirmed as completed, wherein the notification includes a confirmation that the transaction was processed according to the first encrypted transaction data and the second encrypted transaction data.
Allu teaches:
wherein processing the transaction comprises: verifying a total amount due for an invoice sent by the first party matches or is less than an authorized payment amount sent by the second party before completing the transaction on behalf of the first party and the second party.((Allu) in at least para 0043)
sending, by the transaction processing server, a notification to at least one of the first party or the second party when the transaction is confirmed as completed, wherein the notification includes a confirmation that the transaction was processed according to the first encrypted transaction data and the second encrypted transaction data [stored] ((Allu) in at least FIG. 5 ref # 52, 56, para 0034, para 0040, para 0048-0049).
Both Liberman and Allu managing account data files for payment processing. Allu teaches the motivation at part of a transaction process processing an invoice for amount due wherein when the amount due is below a threshold the payment may be deferred until the next billing cycle when a transaction payment is directed toward recurring transactions. It would have been obvious to one having ordinary skill at the time of effective filing the invention to modify the processing of transaction transactions to include analyzing invoices as taught by Allu since Allu teaches the motivation at part of a transaction process processing an invoice for amount due wherein when the amount due is below a threshold the payment may be deferred until the next billing cycle when a transaction payment is directed toward recurring transactions.
Both Liberman and Allu managing account data files for payment processing. Allu teaches the motivation of presenting/notifying a generated invoice for informational purposes only in order to display an indicator of account balance at $0 in response to procedural conditions when invoices meet a certain criteria. It would have been obvious to one having ordinary skill at the time of effective filing the invention to modify the processing of transaction transactions of Liberman to include presenting invoice balance at $0 as taught by Allu since Allu teaches the motivation of presenting/notifying a generated invoice for informational purposes only in order to display an indicator of account balance at $0 in response to procedural conditions when invoices meet a certain criteria
Peddada teaches:
decrypting, by the transaction processing server, the first encrypted transaction data using a private key that is maintained on the transaction processing server that neither the first party nor the second party possesses, and a first public key associated with the first party to obtain first decrypted transaction data ((Peddada) in at least abstract; para 0017, para 0019, para 0028-0029, para 0031, para 0041, para 0043, para 0052)
transmitting, by the transaction processing server, a first portion of the first decrypted transaction data and a second portion of the second decrypted transaction data as a stream of transaction data that is serialized, tagged, or field-defined ((Peddada) in at least para 0033-0034, para 0036-0037, para 0039-0040, para 0052-0053, para 0057-0058, para 0155); and
Both Liberman and Peddada are directed toward transaction processes which encrypt data where keys are applied for the decryption process where data is stored in cloud database environment. Peddada teaches the motivation increasing database security migrating encrypted data between databases where the database utilize encryption keys across databased allowing target databases to decrypt data it receives from a source database. It would have been obvious to one having ordinary skill at the time of effective filing the invention to modify the encryption key application and generation of Liberman to include generating encryption database specific key pairs as taught by Peddada since Peddada teaches the motivation increasing database security migrating encrypted data between databases where the database utilize encryption keys across databased allowing target databases to decrypt data it receives from a source database.
Both Liberman and Peddada are directed toward transaction processes which encrypted data is sent and stored as portions within the database. Peddada teaches the motivation of the user sending data to the database where the data includes one or more data fields where the data object includes a set of data fields designated for encryption. It would have been obvious to one having ordinary skill at the time of effective filing the invention to modify the ingestion of data into the database as taught by Liberman to include encryption of data into databased as taught by Peddada since . Peddada teaches the motivation of the user sending data to the database where the data includes one or more data fields where the data object includes a set of data fields designated for encryption with specific named data into as specific data field objects
In reference to Claim 2:
The combination of Liberman, Peddada and Allu discloses the limitations of independent claim 1. Liberman further discloses the limitations of dependent claim 2
(Currently Amended) The method of claim 1 (see rejection of claim 1 above) further comprising:
respectively maintaining the first decrypted transaction data and the second decrypted transaction data in the first one or more containers and the second one or more containers of the container hierarchy for a configurable period of time after the processing of the transaction is complete.((Liberman) in at least Col 4 lines 1-34, Col 15 lines 27-39, Col 22 lines 51-Col 23 lines 1-2, Col 26 lines 65-Col 27 lines 1-6, Col 38 lines 51-Col 39 lines 1-13, Col 59 lines 32-62)
Peddada teaches and provides supporting evidence.
respectively maintaining the first decrypted transaction data and the second decrypted transaction data in the first one or more containers and the second one or more containers of the container hierarchy for a configurable period of time after the processing of the transaction is complete.((Peddada) in at least Abstract; para 0023, para 0029, para 0042, para 0046-0047, para 0051, para 0057-0058, para 0061-0070)
Both Liberman and Peddada are directed toward transaction processes which encrypt data where keys are applied for the decryption process where data is stored in cloud database environment. Peddada teaches the motivation increasing database security migrating encrypted data between databases where the database utilize encryption keys across database allowing target databases to decrypt data for each recipient it receives from a source database. It would have been obvious to one having ordinary skill at the time of effective filing the invention to modify the encryption key application and generation of Liberman to include generating encryption database specific key pairs as taught by Peddada since Peddada teaches the motivation increasing database security migrating encrypted data between databases where the database utilize encryption keys across databased allowing target databases to decrypt data for each recipient it receives from a source database.
In reference to Claim 3:
The combination of Liberman, Peddada and Allu discloses the limitations of dependent claim 2. Liberman further discloses the limitations of dependent claim 3.
(Original) The method of claim 2 (see rejection of claim 2 above) further comprising:
enforcing access restrictions on requests for access to the first decrypted transaction data or the second decrypted transaction data based on access rights assigned to the one or more containers. ((Liberman) in at least Col 19 lines 15-28, Col 36 lines 56-Col 37 lines 1-27)
In reference to Claim 8:
The combination of Liberman, Peddada and Allu discloses the limitations of independent claim 1. Liberman further discloses the limitations of dependent claim 8
(Currently Amended) The method of claim 1 (see rejection of claim 1 above), further comprising
further includes encrypting at least a portion of the first decrypted transaction data within at least one container of the first one or more containers. ((Liberman) in at least Col 10 lines 21-30, lines 50-60, Col 13 lines 35-44, Col 14 lines 1-13, Col 19 lines 15-22, Col 20 lines 14-44, Col 23 lines 57-67, Col 36 lines 56-Col 37 lines 1-26, Col 42 lines 57-Col 43 lines 1-15, Col 56 lines 4-7)
Claim(s) 5 is/are rejected under 35 U.S.C. 103 as being unpatentable over US Patent No. 11,514,448 B1 by Liberman (Liberman) in view of US Pub No. 2019/0340251 A1 by Peddada et al. (Peddada) in view of US Pub No. 2006/0015363 A1 by Allu et al (Allu) as applied to claim 1 above, and further in view of US Patent No. 10,091,151 B2 by Hardee et al. (Hardee).
In reference to Claim 5:
The combination of Liberman, Peddada and Allu discloses the limitations of independent claim 1. Liberman further discloses the limitations of dependent claim 5
(Currently Amended) The method of claim 1 (see rejection of claim 1 above), wherein receiving further includes:
receiving … transaction [data] corresponding to the first encrypted transaction data ((Liberman) in at least FIG. 8; Col 36 lines 56-Col 37 lines 1-27, Col 42 lines 57-Col 43 lines 1-15, Col 56 lines 4-7, ) , …
receiving a second transaction [data] corresponding to the second encrypted transaction data((Liberman) in at least FIG. 8; Col 36 lines 56-Col 37 lines 1-27, Col 42 lines 57-Col 43 lines 1-15, Col 56 lines 4-7, ),…
Liberman does not explicitly teach:
receiving a first transaction identifier… ;
receiving a second transaction identifier;
determining that the first transaction identifier matches the second transaction identifier; and
based on determining that the first transaction identifier matches the second transaction identifier, combining the first decrypted transaction data with the second decrypted transaction data to form a complete version of transaction data for the transaction.
Hardee teaches:
receiving a first transaction identifier ((Hardee) in at least FIG. 3; Col 5 lines 50-Col 6 lines 1-18; Claim 1);
receiving a second transaction identifier ((Hardee) in at least FIG. 3; Col 5 lines 50-Col 6 lines 1-49, Claim 1);
determining that the first transaction identifier matches the second transaction identifier ((Hardee) in at least FIG. 4; Col 7 lines 1-17; Claim 1 wherein the prior art teaches the identifier generated based on both parties identifier); and
based on determining that the first transaction identifier matches the second transaction identifier, combining the first … transaction data with the second … transaction data to form a complete version of transaction data for the transaction ((Hardee) in at least FIG. 4; Col 7 lines 1-17; Claim 1).
Both Liberman and Hardee are directed toward transaction processes where a transaction identifier is generated. Hardee teaches the motivation of generating a transaction identifier based on both parties identifiers in order to bypass spam filters for notifications associated with transaction identifiers. It would have been obvious to one having ordinary skill at the time of effective filing the invention to modify the generation of a unique transaction identifier of Liberman to include generating the identifier based on participants identifiers as taught by Hardee since Hardee teaches the motivation of generating a transaction identifier based on both parties identifiers in order to bypass spam filters for notifications associated with transaction identifiers
Claim(s) 9 is/are rejected under 35 U.S.C. 103 as being unpatentable over US Patent No. 11,514,448 B1 by Liberman (Liberman) in view of US Pub No. 2019/0340251 A1 by Peddada et al. (Peddada) in view of US Pub No. 2006/0015363 A1 by Allu et al (Allu) as applied to claim 1 above, and further in view of US Pub No. 2009/0248467 A1 by Bulman et al. (Bulman)
In reference to Claim 9:
The combination of Liberman, Ahmed, Nicholls and Allu discloses the limitations of independent claim 1. Liberman further discloses the limitations of dependent claim 9.
(Currently Amended) The method of claim 1 (see rejection of claim 1 above), wherein processing further includes:
Liberman does not explicitly teach:
providing the invoice for approval to the second party of the transaction before the processing the transaction.
Bulman teaches:
providing the invoice for approval to the second party of the transaction before the processing the transaction ((Bulman) in at least para 0012).
Both Liberman and Bulman are directed toward a transaction process. Bulman teaches the motivation of invoicing processes in response to when orders for goods are placed an invoice of the goods are presented and determined whether the invoice of goods match the orders placed so that payment may be approved. It would have been obvious to one having ordinary skill at the time of effective filing the invention to modify the transaction process of Liberman to include invoice process as taught by Bulman since Bulman teaches the motivation of invoicing processes in response to when orders for goods are placed an invoice of the goods are presented and determined whether the invoice of goods and amount due match the orders placed so that payment may be approved.
Claim(s) 11 is/are rejected under 35 U.S.C. 103 as being unpatentable over US Patent No. 11,514,448 B1 by Liberman (Liberman) in view of US Pub No. 2019/0340251 A1 by Peddada et al. (Peddada) in view of US Pub No. 2006/0015363 A1 by Allu et al (Allu) as applied to claim 1 above, and further in view of US Pub No. 2018/0308090 A1 by Leavitt et al (Leavitt)
In reference to Claim 11:
The combination of Liberman, Peddada and Allu discloses the limitations of independent claim 1. Liberman further discloses the limitations of dependent claim 11.
(Currently Amended) The method of claim 1 (see rejection of claim 1 above), wherein processing further includes:
…using stream of the transaction data…((Liberman) in at least Col 5 lines 45-65)
Liberman does not explicitly teach:
requesting a third-party service to process the transaction using stream of the transaction data; and
requesting the third-party service notify each of the first party and the second party when the transaction is completed by the third-party service.
Leavitt teaches:
requesting a third-party service to process the transaction using … the transaction data from the one or more particular containers ((Leavitt) in at least para 0059-0061) and
requesting the third-party service notify each of the first party and the second party when the transaction is completed by the third-party service. ((Leavitt) in at least para 0059-0061)
Both Liberman and Leavitt teach notification processes related to transactions and third-party concepts within the transaction process. Leavitt teaches the motivation of a third party which processes the payment and a requesting entity requesting the third party as part of the payment transaction to send notification information to the merchant and buyer of the status of the payment. It would have been obvious to one having ordinary skill at the time of effective filing the invention to modify the transaction process of Liberman to include third party notification process of Leavitt since Leavitt teaches the motivation of a third party which processes the payment and a requesting entity requesting the third party as part of the payment transaction to send notification information to the merchant and buyer of the status of the payment.
Claim(s) 12 is/are rejected under 35 U.S.C. 103 as being unpatentable over US Patent No. 11,514,448 B1 by Liberman (Liberman) in view of US Pub No. 2019/0340251 A1 by Peddada et al. (Peddada) in view of US Pub No. 2006/0015363 A1 by Allu et al (Allu) as applied to claim 1 above, and further in view of US Pub No. 2008/0011820 A1 by Brown et al. (Brown)
In reference to Claim 12:
The combination of Liberman, Peddada and Allu discloses the limitations of independent claim 1. Liberman further discloses the limitations of dependent claim 12.
(Original) The method of claim 1 (see rejection of claim 1 above), wherein processing further includes:
Liberman does not explicitly teach:
notifying, by a transaction service, one or more third-party services as different portions of a workflow associated with processing the transaction are completed such that the one or more third-party services can confirm completion of the different portions of the workflow with the first party and the second party independently of the transaction service.
Brown teaches:
notifying, by a transaction service, one or more third-party services as different portions of a workflow associated with processing the transaction are completed such that the one or more third-party services can confirm completion of the different portions of the workflow with the first party and the second party independently of the transaction service.((Brown) in at least Abstract; para 0005, para 0033, para 0036-0040)
Both Liberman and Brown are directed toward transaction processes with include third party interactions. Brown teaches the motivation of a third party confirming different parts of a purchase in order to determine which qualified payment account can be used for item eligibility purchases . It would have been obvious to one having ordinary skill at the time of effective filing the invention to modify the transaction process of Liberman to include third party oversight as taught by Brown since Brown teaches the motivation of a third party confirming different parts of a purchase in order to determine which qualified payment account can be used for item eligibility purchases
Claim(s) 13 and 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over US Patent No. 11,514,448 B1 by Liberman (Liberman) in view of US Pub No. 2011/0082798 A1 by Michaud (Michaud) and in view of in view of US Patent No. 11,195,215 B1 by Silver et al. (Silver)
In reference to Claim 13:
Liberman teaches:
(Currently Amended) A method ((Liberman) in at least Fig. 8; Col 42 lines 56-Col 43 lines 1-50), comprising:
organizing, by a transaction clearinghouse server, first encrypted transaction data received from a first party to a transaction and second encrypted transaction data received form a second party to the transaction ((Liberman) in at least Col 5 lines 20-34, Col 7 lines 15-25, Col 9 lines 60-Col 10 lines 1-9, lines 51-Col 11 lines 1-9, lines 60-Col 12 lines 1-2, Col 15 lines 4-18, lines 27-39, Col 16 lines 49-Col 17 lines 1-26, Col 19 lines 34-40, lines 50-60, Col 23 lines 37-67, Col 25 lines 65-Col 26 lines 1-4, Col 26 lines 49-50, Col 29 lines 10-Col 30 lines 1-46, Col 36 lines 56-Col 37 lines 1-9);
storing, by the transaction clearinghouse server, the first encrypted transaction data into a first one or more containers of a container hierarchy ((Liberman) in at least FIG. 3;, FIG. 7A. Col 16 lines 1-27, Col 23 lines 37-67, ;
storing, by the transaction clearinghouse server, the second encrypted transaction data into a second one or more containers of the container hierarchy, , wherein each container comprises a respective party specific portion of transaction data associated with a corresponding container-defined data format or corresponding container-defined access rights ((Liberman) in at least Col 5 lines 21-63, Col 10 lines 51-67, Col 11 lines 42-Col 12 lines 1-2, lines 15-25, Col 19 lines 18-28, Col 20 lines 44-59, Col 22 lines 1-4, Col 31 lines 4-16 lines 36-47, lines 53-56, Col 32 lines 21-50, Col 33 lines 25-45, Col 36 lines 59-Col 37 lines 1-27, Col 49 lines 57-Col 50 lines 1-45 wherein the prior art teaches each ledger for purposes of sending/addressing transaction message data may include private/public keys (for decrypting) associated with all of the each other devices, col 57 lines 42-61); …
decrypting, by the transaction clearinghouse server, the first encrypted transaction data from the first one or more containers using a transaction processing service private key and a first party public key to obtain first decrypted transaction data ;((Liberman) in at least Col 2 lines 7-16, Col 19 lines 15-15-21, Col 36 lines 56-Col 37 lines 1-27, Col 49 lines 57-Col 50 lines 1-45 wherein the prior art teaches each ledger for purposes of sending/addressing transaction message data may include private/public keys (for decrypting) associated with all of the each other devices, Col 56 lines 55-60, Col 57 lines 42-43, Col 71 lines 55-59);
decrypting, by the transaction clearinghouse server, the second encrypted transaction data from the second one or more containers using the transaction processing service private key and a second party public key to obtain second decrypted transaction data;((Liberman) in at least Col 2 lines 7-16, Col 19 lines 15-15-21, Col 36 lines 56-Col 37 lines 1-27, Col 49 lines 57-Col 50 lines 1-45 wherein the prior art teaches each ledger for purposes of sending/addressing transaction message data may include private/public keys (for decrypting) associated with all of the each other devices, Col 56 lines 55-60, Col 57 lines 42-43, Col 71 lines 55-59)
Although Liberman does not explicitly teach “second encrypted transaction data using the private key and a second public key associated with the second party...”, the prior art does teach that for each stored transaction data a private/public key process is applied, furthermore, according to MPEP 2144.04, VI, section B, In re Harza, 274 F.2d 669, 124 USPQ 378 (CCPA 1960), the court held that mere duplication of parts has no patentable significance unless a new and unexpected result is produced. Therefore, the duplication of decrypting second encrypted data using second private and public key associated with second party is obvious. …
storing, by the transaction processing service, an … [data] submitted by the first party and identified from the first decrypted transaction data with a checksum value or with at least one digital signature associated with the first party or the second party ((Liberman) in at least Col 16 lines 43-59, Col 20 lines 7-13, Col 37 lines 10-Col 38 lines 1-10, Col 56 lines 19-21)
identifying an authorization from the first party to process the transaction ((Liberman) in at least Col 36 lines 56-Col 37 lines 1-27, Col 38 lines 51-Col 39 lines 1-27, Col 40 lines 46-Col 41 lines 1-17, Col 42 lines 57-Col 43 lines 1-15; Col 71 lines 55-67);
obtaining by the transaction clearinghouse server, a first portion of the first decrypted transaction data and the second portion of the second decrypted transaction data ((Liberman) in at least Col 29 lines 10-Col 30 lines 1-46, Col 42 lines 57-Col 43 lines 1-15, Col 48 lines 15-Col 49 lines 1-2, , Col 49 lines 57-Col 50 lines 1-45 wherein the prior art teaches each ledger for purposes of sending/addressing transaction message data may include private/public keys (for decrypting) associated with all of the each other devices); and
wherein the causing the confirmation to be sent comprises:
enforcing, by the transaction clearinghouse server, at least one access restriction on a request for access to the first encrypted transaction data in the first one or more containers or the second encrypted transaction data in the second one or more containers .((Liberman) in at least Col 9 lines 60-Col 10 lines 1-8 wherein the prior art teaches hash chaining of ledgers with includes proof of work for write permission makes it infeasible to modify the ledger; Col 11 lines 38-66 wherein the prior art teaches each substrate/container includes hierarchical arrangement and may be permissions or feature restricted participation such that only certain participants have access to certain substrates/containers; Col 19 lines 4-15) and
providing, by the transaction clearinghouse server, at least a portion of the first encrypted transaction data or at least a portion of the second encrypted transaction data to at least one of the first party or the second party after the transaction is completed for a configurable period of time based on at least one access right.((Liberman) in at least Col 1 lines 45-51, Col 4 lines 17-33, lines 60-Col 5 lines 1-3, Col 17 lines 1-13, Col 37 lines 10-Col 38 lines 1-10, Col 38 lines 51-Col 39 lines 1-13, Col 51 lines 14-29, Col 58 lines 9-35, Col 59 lines 32-48)
Liberman suggest but does not explicitly teach:
wherein the first party encrypts the first encrypted transaction data with a first party private key and a transaction processing service public key of a transaction processing service the first party sends the first encrypted transaction data to the transaction processing service, and the second party encrypts the second encrypted transaction data with a second party private key and the transaction processing service public key and the second party sends the second encrypted transaction data to the transaction processing service ((Liberman) in at least Col 5 lines 20-34, Col 7 lines 15-25, Col 9 lines 60-Col 10 lines 1-9, lines 51-Col 11 lines 1-9, lines 60-Col 12 lines 1-2, Col 15 lines 4-18, lines 27-39, Col 16 lines 49-Col 17 lines 1-26, Col 19 lines 34-40, lines 50-60, Col 23 lines 37-67, Col 25 lines 65-Col 26 lines 1-4, Col 26 lines 49-50, Col 29 lines 10-Col 30 lines 1-46, Col 36 lines 56-Col 37 lines 1-9;
Liberman does not explicitly teach:
storing, by the transaction processing service, an invoice …
wherein the first party encrypts the first encrypted transaction data with a first party private key and a transaction processing service public key of a transaction processing service the first party sends the first encrypted transaction data, to the transaction processing service, and the second party encrypts the second encrypted transaction data with the second party private key and the transaction processing service public key and the second party sends the second encrypted transaction data to the transaction processing service
causing a confirmation indicating that the transaction was completed to be sent to at least one or the first party or the second party
Michaud teaches:
wherein the first party encrypts the first encrypted transaction data with a first party private key and a transaction processing service public key of a transaction processing service the first party sends the first encrypted transaction data, to the transaction processing service, and the second party encrypts the second encrypted transaction data with the second party private key and the transaction processing service public key and the second party sends the second encrypted transaction data to the transaction processing service ((Michaud) in at least para 0005, para 0026-0027, para 0029-0031, para 0047, para 0050- 0060)
According to KSR, simple substitution for one known entity to decrypt encrypted data and maintaining keys for another with predictable results is common sense obvious rationale. The prior art Liberman differed from the claimed entity maintaining a decryption key used to decrypt data by the substitution with another entity in a transaction process where data stored in containers are encrypted and then when extracted decrypted. The prior art Michaud provides evidence that in a transaction system landscape that a plurality of options can be substituted for implemented when considering which entity maintains decryption keys and applies the decryption keys for decrypting encrypted data stored in containers. Accordingly, the prior art Michaud provides teaching that the substituted entities/computer systems and their functions were known in the art which can be considered for maintaining decryption keys and using decryption keys to decrypt encrypted transaction data. Accordingly, one of ordinary skill in the art could have substituted one known element for another, and the results of the substitution would have been predictable
Both Liberman and Michaud are directed toward transaction processes which encrypt data stored in containers where keys are applied for the decryption process. Michaud teaches the motivation of in a retail landscape system utilizing encryption and decryption mechanisms where different options for decrypting mechanism which include exemplary options of a target system, middleware, processor logic, Head Office server or any other system depending on preferred embodiment stores the key information necessary to decrypt encrypted POS transaction sensitive data stored in containers so that the system that needs to extract sensitive data needs only to perform the decryption operation once improving performance without compromising security. It would have been obvious to one having ordinary skill at the time of effective filing the invention to modify the entity options for decryption mechanism and possession of keys of Liberman to include the exemplary option of the head office server which maintains keys and decrypts transaction data of Michaud since Michaud teaches the motivation of in a retail landscape system utilizing encryption and decryption mechanisms where different options for decrypting mechanism which include exemplary options of a target system, middleware, processor logic, Head Office server or any other system depending on preferred embodiment stores the key information necessary to decrypt encrypted POS transaction sensitive data stored in containers so that the system that needs to extract sensitive data needs only to perform the decryption operation once improving performance without compromising security.
Silver teaches:
storing, by the transaction processing service, an invoice …((Silver) in at least FIG. 2; Col 3 lines 60-Col 4 lines 1-2, Col 9 lines 45-54):
causing a confirmation indicating that the transaction was completed to be sent to at least one or the first party or the second party ((Silver) in at least Col 5 lines 19-38, Col 9 lines 45-62, Col 11 lines 9-21)
Both Liberman and Silver are directed toward transaction processes. Silver teaches the motivation that some transactions may be on-going and therefore, an invoice representing the transaction needs to be continuously updated until a final invoice is determined at payment. It would have been obvious to one having ordinary skill at the time of effective filing the invention to modify the transaction process of Liberman to include providing invoices that have been updated for on-going transactions of Silver since Silver teaches the motivation that some transactions may be on-going and therefore, an invoice representing the transaction needs to be continuously updated until a final invoice is determined at payment.
Both Liberman and Silver are directed toward transaction processes. Silver teaches the motivation of storing confirmation of completion and payment for transaction in order to allow a review of the transactions and payments. It would have been obvious to one having ordinary skill at the time of effective filing the invention to modify the transaction process of Liberman to include storing transaction confirmations receipts as taught by Silver since Silver teaches the motivation of storing confirmation of completion and payment for transaction in order to allow a review of the transactions and payments
In reference to Claim 15:
The combination of Liberman, Silver and Michaud discloses the limitations of independent claim 13. Liberman further discloses the limitations of dependent claim 15.
(Currently Amended) The method of claim 13 (see rejection of claim 13 above), further includes:
receiving the first encrypted of the data in a first encrypted format from the first party ((Liberman) in at least Col 15 lines 61-65, Col 23 lines 60-67, Col 36 lines 56-Col 37 lines 1-27, Col 40 lines 46-67, Col 79 lines 1-15); and
receiving the second encrypted transaction data in a second encrypted format from the second party. ((Liberman) in at least Col 15 lines 61-65, Col 23 lines 60-67, Col 36 lines 56-Col 37 lines 1-27, Col 40 lines 46-67, Col 79 lines 1-15)
Claim(s) 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over US Patent No. 11,514,448 B1 by Liberman (Liberman) in view of US Pub No. 2011/0082798 A1 by Michaud et al (Michaud) in view of US Patent No. 11,195,215 B1 by Silver et al. (Silver) as applied to claim 15 above, and further in view of US Pub No. 2013/0104022 A1 by Coon (Coon) and in view of US Pub No. 2004/0030893 A1 by Karamchedu et al (Karamchedu)
In reference to Claim 16:
The combination of Liberman, Nicholls and Michaud discloses the limitations of dependent claim 14. Liberman further discloses the limitations of dependent claim 16.
(Currently Amended) The method of claim 14 (see rejection of claim 14 above),
wherein receiving the first encrypted transaction data and receiving the second encrypted transaction data from the second party ;((Liberman) in at least Col 2 lines 7-16, Col 19 lines 15-15-21, Col 36 lines 56-Col 37 lines 1-27, Col 49 lines 57-Col 50 lines 1-45 wherein the prior art teaches each ledger for purposes of sending/addressing transaction message data may include private/public keys (for decrypting) associated with all of the each other devices, Col 56 lines 55-60, Col 57 lines 42-43, Col 71 lines 55-59)
further includes:
decrypting the …[any] encrypted transaction data using the transaction processing service private key and the second party public key into …[any] decrypted transaction data ;((Liberman) in at least Col 2 lines 7-16, Col 19 lines 15-15-21, Col 36 lines 56-Col 37 lines 1-27, Col 49 lines 57-Col 50 lines 1-45 wherein the prior art teaches each ledger for purposes of sending/addressing transaction message data may include private/public keys (for decrypting) associated with all of the each other devices, Col 56 lines 55-60, Col 57 lines 42-43, Col 71 lines 55-59)
Although Liberman does not explicitly teach “second encrypted transaction data using the private key and a second public key associated with the second party...into third decrypted transaction data”, the prior art does teach that for each stored transaction data a private/public key process is applied, furthermore, according to MPEP 2144.04, VI, section B, In re Harza, 274 F.2d 669, 124 USPQ 378 (CCPA 1960), the court held that mere duplication of parts has no patentable significance unless a new and unexpected result is produced. Therefore, the duplication of decrypting second encrypted data using second private and public key associated with second party is obvious
Liberman does not explicitly teach:
identifying a non-final invoice associated with the first party in the first decrypted transaction data; :
identifying a limit defined by or associated with an account of the second party in the second decrypted transaction data;
iteratively receiving one or more portions of third encrypted transaction data from the second party;
assembling a final invoice based on the third decrypted transaction data
notifying the second party when the limit is exceeded or within a configurable amount of the limit; and
providing the final invoice to the second party for the authorization.
Silver teaches:
identifying a non-final invoice associated with the first party in the first decrypted transaction data ((Silver) in at least FIG. 2; Col 9 lines 45-54): …
iteratively receiving one or more portions of third encrypted transaction data from the second party; ((Silver) in at least FIG. 2; Col 3 lines 60-Col 4 lines 1-2; Col 9 lines 45-54);
assembling a final invoice based on the … decrypted transaction data ((Silver) in at least FIG. 2; Col 3 lines 60-Col 4 lines 1-2, Col 9 lines 45-54); …
providing the final invoice to the second party for the authorization. ((Silver) in at least Col 9 lines 54-62).
Although Silver does not teach “decrypted transaction data”, the combination of Liberman and Silver makes obvious that data stored can be decrypted. According to KSR, known work in one field of endeavor may prompt variations of it for use in either the same field or different one based on design incentives or other market forces if the variations are predictable to one of ordinary skill in the art. The scope and content of the prior art Silver, whether in the same filed as that of applicant’s invention or a different variation included a similar method of storing transaction related data. The prior art Liberman provides design incentives or market forces that would have prompted one of ordinary skill in the art to adapt the invoice data stored to be encrypted and decrypted for security of data. Accordingly the differences between the claimed invention (i.e. encrypted/decrypted transaction data that are invoices) and the prior art as taught Silver that transaction data can include invoice data and as taught by Liberman generally that transaction data stored is encrypted and decrypted where encompassed in known variations or in a principle known in the art. Therefore, based on common sense and the teaching of the prior art references, one of ordinary skill in the art, in view of the identified design incentives or other market forces, could have implemented the claimed variation of the prior art, and the claimed variation would have been predictable to one of ordinary skill in the art
Both Liberman and Silver are directed toward transaction processes. Silver teaches the motivation that some transactions may be on-going and therefore, an invoice representing the transaction needs to be continuously updated until a final invoice is determined at payment. It would have been obvious to one having ordinary skill at the time of effective filing the invention to modify the transaction process of Liberman to include providing invoices that have been updated for on-going transactions of Silver since Silver teaches the motivation that some transactions may be on-going and therefore, an invoice representing the transaction needs to be continuously updated until a final invoice is determined at payment.
Coon teaches:
identifying a limit defined by or associated with an account of the second party in the second decrypted transaction data ((Coon) in at least para 0068-0069, para 0108, para 0142, para 0152, para 0154);
notifying the second party when the limit is exceeded or within a configurable amount of the limit ((Coon) in at least para 0068-0070, para 0152); and
Both Liberman and Coon are directed toward transaction processes. Coon teaches the motivation of the purchaser setting pre-determined thresholds for amounts of payment on purchases so that in the event the buyer does not know specific amount of the anticipated purchase they can be notified for authorization approval of the requested amount. It would have been obvious to one having ordinary skill at the time of effective filing the invention to modify the transaction process of Liberman to include a process for purchases where the accumulated price of goods is not known of Coon since Coon teaches the motivation of the purchaser setting pre-determined thresholds for amounts of payment on purchases so that in the event the buyer does not know specific amount of the anticipated purchase they can be notified for authorization approval of the requested amount.
Karamchedu teaches:
decrypting the third encrypted transaction data using the transaction processing service private key and the second party public key into third decrypted transaction data((Karamchedu) in at least para 0057-0067).
Both Liberman and Karamchedu are directed toward encryption of communication messages ((Liberman) in at least Col 49 lines 57-Col 50 lines 1-30). Karamchedu teaches the motivation of selective encryption of messages and data in order to deliver fully secure portions of messages that are stored in encryption form. It would have been obvious to one having ordinary skill at the time of effective filing the invention to modify the encryption of messages process of Liberman to include the split encryption key method of Karamchedu since Karamchedu teaches the motivation of selective encryption of messages and data in order to deliver fully secure portions of messages that are stored in encryption form.
Claim(s) 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over US Patent No. 11,514,448 B1 by Liberman (Liberman) in view of US Pub No. 2011/0082798 A1 by Michaud et al (Michaud) in view of US Patent No. 11,195,215 B1 by Silver et al. (Silver) as applied to claim 14 above, and further in view of US Pub No. 2020/0410559 A1 by Qaudeer et al. (Qaudeer)
In reference to Claim 17:
The combination of Liberman, Silver and Michaud discloses the limitations of dependent claim 14. Liberman further discloses the limitations of dependent claim 17.
(Currently Amended) The method of claim 13 (see rejection of claim 13), wherein identifying the authorization further includes:
identifying the …[data] provided by the first party in the first decrypted transaction data associated with a particular container of the first one or more containers ((Liberman) in at least Col 23 lines 4-37, Col 32 lines 21-37, Col 35 lines 7-31, Col 49 lines 57-Col 50 lines 1-7, Col 54 lines 33-53, Col 55 lines 5-17, );
providing the …[data] in a data format that can be viewed by the second party within an interface ((Liberman) in at least Col 2 lines 47-59, Col 10 lines 52-67, Col 57 lines 52-67, Col 11 lines 38-67, Col 12 lines 15-25, Col 20 lines 44-51, Col 22 lines 1-4); and
receiving the authorization from the second party through the interface ((Liberman) in at least Col 28 lines 29-42, Col 29 lines 25-35, Col 32 lines 59-67, Col 33 lines 4-17, Col 40 lines 35-45, Col 41 lines 27-39).
Liberman does not explicitly teach:
identifying the invoice provided by the first party … ;
providing the invoice in a data format that can be viewed by the second party within an interface; and
receiving the authorization from the second party through the interface.
Qaudeer teaches:
identifying the invoice provided by the first party in the transaction data associated with a particular container of the …[distributed ledger] ((Qaudeer) in at least para 0015, para 0041, para 0047 wherein the prior art teaches validator ensures consistency with invoice number and other invoice data, para 0049 wherein the prior art teaches invoice records stored in distributed ledgers in a treen with ordering/service nodes; para 0053 wherein the prior art teaches decentralized soliciting of invoice number; para 0059);
providing the invoice in a data format that can be viewed by the second party within an interface ((Qaudeer) in at least para 0032 wherein the prior art teaches use of API to forward invoice records; para 0053 wherein the prior art teaches decentralized application include interfaces to view invoices for example API’s); and
receiving the authorization from the second party through the interface ((Qaudeer) in at least para 0066, para 0069, para 0074).
Both Liberman and Qaudeer are directed toward transaction processes using blockchain/distributed ledger technology. Qaudeer teaches the motivation of a process when a transaction is disputed. It would have been obvious to one having ordinary skill at the time of effective filing the invention to modify the transaction process of Liberman to include a process to apply analysis of invoices as taught by Qaudeer since Qaudeer teaches the motivation of a process when a transaction is disputed.
Claim(s) 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over US Patent No. 11,514,448 B1 by Liberman (Liberman) in view of US Pub No. 2011/0082798 A1 by Michaud et al (Michaud) in view of US Patent No. 11,195,215 B1 by Silver et al. (Silver)as applied to claim 14 above, and further in view of US Pub No. 2004/0030893 A1 by Karamchedu et al (Karamchedu)
In reference to Claim 18:
The combination of Liberman, Silver and Michaud discloses the limitations of dependent claim 14. Liberman further discloses the limitations of dependent claim 18:
(Original) The method of claim 13 (see rejection of claim 13 above) further comprising:
Liberman does not explicitly teach:
encrypting the first party public key and the second party public key using a third encryption and decryption key pair and inserting an encrypted version of the first party public key and the second party public key within a particular container.
Karamchedu teaches:
encrypting the first party public key and the second party public key using a third encryption and decryption key pair and inserting an encrypted version of the first party public key and the second party public key within a particular container [storage] ((Karamchedu) in at least para 0057).
Both Liberman and Karamchedu are directed toward encryption of communication messages ((Liberman) in at least Col 49 lines 57-Col 50 lines 1-30). Karamchedu teaches the motivation of selective encryption of messages and data in order to deliver fully secure portions of messages that are stored in encryption form. It would have been obvious to one having ordinary skill at the time of effective filing the invention to modify the encryption of messages process of Liberman to include the split encryption key method of Karamchedu since Karamchedu teaches the motivation of selective encryption of messages and data in order to deliver fully secure portions of messages that are stored in encryption form.
Claim(s) 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over US Patent No. 11,514,448 B1 by Liberman (Liberman) and further in view of US Pub No. 2019/0340251 A1 by Peddada et al. (Peddada)
In reference to Claim 19:
Liberman teaches:
(Currently Amended) A system ((Liberman) in at least Abstract; , comprising:
a server comprising at least one processor and a non-transitory computer-readable storage medium ((Liberman) in at least Col 73 lines 20-26, lines 39-Col 74 lines 1-23); and
the non-transitory computer-readable storage medium comprising server executable instructions that when executed by cause the at least one processor to perform operations ((Liberman) in at least Col 73 lines 39-Col 74 lines 1-23) comprising:
identifying, by the server a transaction between a first party and a second party ((Liberman) in at least Col 14 lines 28-44, Col 17 lines 3-4 wherein the prior art teaches confirming authenticity of signature, lines 20-26, lines 40-45; col 19 lines 50-63, Col 35 lines 7-31, Col 36 lines 56-Col 37 lines 1-27, Col 38 lines 51-Col 39 lines 1-27, Col 40 lines 46-Col 41 lines 1-17, Col 42 lines 57-Col 43 lines 1-15; Col 71 lines 55-67);
identifying transaction data associated with the transaction by separately receiving a first portion of the transaction data from the first party in a first encrypted format and a second portion of the transaction data the second party in a second encrypted format((Liberman) in at least Col 2 lines 34-37 wherein the prior art teaches database structure to contain data to enable access management; lines 47-52 wherein the prior art teaches information organized using particular format, protocol for storing data, Col 7 lines 20-25 wherein the prior art teaches rules via the consensus protocol which specify participation access and validation protocols; Col 9 lines 60-Col 10 lines 1-9, , Col 10 lines 21-30 wherein the prior art teaches applying different consensus protocols for each data segment, lines 51 lines 51-Col 12 lines 1-3 wherein the prior art teaches defined data formats with each substrate include validation rules and data store consist of independent containers arranged in hierarchical arrangement and each substrate may be permissioned or feature restriction participation, Col 13 lines 35-44, Col 14 lines 1-13 wherein the prior art teaches shared substrate encryption, Col 15 lines 4-18, lines 27-39, Col 16 lines 49-Col 17 lines 1-26, Col 19 lines 5-63 wherein the prior art teaches validation feature includes use of encryption for true per missioning for data delivery, Col 20 lines 14-44, Col 21 lines 49-Col 22 lines 1-37 wherein the prior art teaches sending data in a specified format in the substrate definition, Col 23 lines 57-67, Col 35 lines 7-31, Col 36 lines 56-Col 37 lines 1-26); …
receiving authorization from the first party to process the transaction ((Liberman) in at least Col 36 lines 56-Col 37 lines 1-27, Col 38 lines 51-Col 39 lines 1-27, Col 40 lines 46-Col 41 lines 1-17, Col 42 lines 57-Col 43 lines 1-15; Col 71 lines 55-67);
causing the transaction to be completed on behalf of the first party and the second party using the stream of data ((Liberman) in at least Col 43 lines 37-45, Col 77 lines 10-22); and
causing a notification to be sent to at least one of the first party or the second party when the transaction is completed. ((Liberman) in at least Col 43 lines 37-50, Col 45 lines 50-58), wherein the server is configured to enforce one or more access restrictions on request to access the first decrypted transaction data or the second decrypted transaction data ((Liberman) in at least Col 9 lines 60-Col 10 lines 1-8 wherein the prior art teaches hash chaining of ledgers with includes proof of work for write permission makes it infeasible to modify the ledger; Col 11 lines 38-66 wherein the prior art teaches each substrate/container includes hierarchical arrangement and may be permissions or feature restricted participation such that only certain participants have access to certain substrates/containers; Col 19 lines 4-15)
providing, by the server, particular transaction data to at least one of the first party and the second party after the transaction is completed for a configurable period of time based on the corresponding access right.((Liberman) in at least Col 1 lines 45-51, Col 4 lines 17-33, lines 60-Col 5 lines 1-3, Col 17 lines 1-13, Col 38 lines 51-Col 39 lines 1-13, Col 51 lines 14-29, Col 58 lines 9-35, Col 59 lines 32-48) ((Liberman) in at least Col 22 lines 51-Col 23 lines 1-3, Col 25 lines 58-65, Col 29 lines 36-61, Col 30 lines 47-Col 31 lines 1-16).
Liberman does not explicitly teach;
maintaining the first portion of the transaction data and the second portion of the transaction data such that just the server is capable of decrypting the first portion and the second portion using one or more private keys maintained by the server a first party public key and a second party public key;
receiving, by a transaction processing service the first portion of the transaction data and the second portion of the transaction data in a first encrypted data stream specific to the first party and the second encrypted data stream specific to the second party, such that only the transaction processing service or the server is capable of decrypting the first encrypted data stream into first decrypted transaction data and the second encrypted data stream into second decrypted transaction data to process the first decrypted transaction data and the second decrypted transaction data;
transmitting at least a portion of the first decrypted transaction data and at least a portion of the second decrypted transaction data as a stream of data that is serialized, tagged, or field-defined
Peddada teaches:
maintaining the first portion of the transaction data and the second portion of the transaction data such that just the server is capable of decrypting the first portion and the second portion using one or more private keys maintained by the server a first party public key and a second party public key ((Peddada) in at least abstract; para 0017, para 0019, para 0028-0029, para 0031, para 0041, para 0043, para 0052)
receiving, by a transaction processing service the first portion of the transaction data and the second portion of the transaction data in a first encrypted data stream specific to the first party and the second encrypted data stream specific to the second party, such that only the transaction processing service or the server is capable of decrypting the first encrypted data stream into first decrypted transaction data and the second encrypted data stream into second decrypted transaction data to process the first decrypted transaction data and the second decrypted transaction data ((Peddada) in at least para 0029-0032, para 0036, para 0039-0042, para 0045-0047, para 0056-0063);
transmitting at least a portion of the first decrypted transaction data and at least a portion of the second decrypted transaction data as a stream of data that is serialized, tagged, or field-defined ((Peddada) in at least para 0033-0034, para 0036-0037, para 0039-0040, para 0052-0053, para 0057-0058, para 0155); and
Both Liberman and Peddada are directed toward transaction processes which encrypt data where keys are applied for the decryption process where data is stored in cloud database environment. Peddada teaches the motivation increasing database security migrating encrypted data between databases where the database utilize encryption keys across databased allowing target databases to decrypt data it receives from a source database. It would have been obvious to one having ordinary skill at the time of effective filing the invention to modify the encryption key application and generation of Liberman to include generating encryption database specific key pairs as taught by Peddada since Peddada teaches the motivation increasing database security migrating encrypted data between databases where the database utilize encryption keys across databased allowing target databases to decrypt data it receives from a source database.
Both Liberman and Peddada are directed toward transaction processes which encrypted data is sent and stored as portions within the database. Peddada teaches the motivation of the user sending data to the database where the data includes one or more data fields where the data object includes a set of data fields designated for encryption. It would have been obvious to one having ordinary skill at the time of effective filing the invention to modify the ingestion of data into the database as taught by Liberman to include encryption of data into databased as taught by Peddada since . Peddada teaches the motivation of the user sending data to the database where the data includes one or more data fields where the data object includes a set of data fields designated for encryption with specific named data into as specific data field objects
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MARY M GREGG whose telephone number is (571)270-5050. The examiner can normally be reached M-F 9am-5pm.
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, Christine Behncke can be reached at 571-272-8103. 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.
/MARY M GREGG/Examiner, Art Unit 3695
Prosecution Insights