DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 06 April 2026 has been entered.
Response to Amendment
Applicant amended claim 1 and cancelled claims 3 and 17. Accordingly, claims 1-2, 4-16, and 18-20 remain pending.
Applicant’s amendment to the abstract overcomes the abstract objection of 08 January 2026.
Response to Arguments
Regarding the abstract objections:
Applicant’s arguments, filed 6 March 2026, with respect to abstract objection have been fully considered and are persuasive. The abstract objection of 08 January 2026 has been withdrawn.
Regarding the 35 USC 103 rejection:
Applicant's arguments filed 06 March 2026 have been fully considered but they are not persuasive.
Applicant’s remarks:
Applicant respectfully asserts that the amendments to claim 1 overcome the 35 U.S.C. 103 rejections due to Bayon, Neuman, Lindsay and Palgon. Specifically, in amended claim, different chunks are sent to different API endpoints. Neuman, in combination with the other cited references, does not teach nor disclose the situation where every chunk is sent to respectively different API endpoints.
Applicant’s support:
Tootoonchian , as cited by the present office action, in col. 10, lines 15-22 describes:
In these embodiments, the system may be programmed to split the data block into
multiple sections, and save each portion of the data block in a different LBA.
Tootoonchian does not send a plurality of chunks of data to different API endpoints. Instead, Tootoonchian sends data to a single API several times, with the data being saved to a different logical block address (LBA). Applicant respectfully asserts that an API is different from an LBA, and sending data to multiple LBAs via a single API (Tootoonchian ) is different from sending data chunks to different APIs (amended claim 1). Tootoonchian discloses saving data to multiple LBAs using a single API, which is different from the limitation from claim 3, where "each of said plurality of chunks of data are sent from the client computer to respectively different API endpoints". In other words, while Tootoonchian discloses sending data to different LBAs using a single API, amended claim 1 includes the limitation that data chunks are sent to different APIs. Hence, Tootoonchian does nothing to remedy the deficiencies of Bayon, Nauman, Lindsay and Palgon. Amended claim 1 and associated dependent claims 4-7, 9-12, 14-15, and 18-19 are hence in a condition for allowance over any combination of Bayon, Neuman, Lindsay, Palgon, and Tootoonchian .
Examiner’s remarks:
An API endpoint is a digital location where an API receives and sends data.
Column 10, lines 10-22 of Tootoonchian reveals for many memory APIs, …a single data block may span a few different LBAs. Splitting the data block into multiple chunks and saving each portion of the data/chunks in a different LBA (different digital location). Figure 1 reveals data block API and LBA API. Therefore, data blocks are sent to data block API and LBA API depending on the memory type. Column 6, lines 30-35 discloses data block API preferably directly accesses primary memory using physical memory addresses and indirectly accesses second memory using LBA API, see Figure 6 which reveals requests to write data block to memory from thread. If its main memory, the data block is sent to main memory via data block API, else the copy of the data block is sent to LBA API to write to secondary memory.
As indicated in the examiner’s remarks above and in the current office action, the limitations in the independent claims do not overcome the prior art applied in the 35 USC 103 rejection. Thus, the independent claims are not allowable and their dependent claims are not allowed based on their dependencies
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1, 4-7, 9-12, 14-15, and 18-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bayon et al US 20210167959 (hereinafter Bayon), in view of Neuman et al US 20160294821 (hereinafter Neuman), in further view of Lindsay US 20220067205 (hereinafter Lindsay), in further view of Palgon et al US 8458487 (hereinafter Palgon), and in further view of Tootoonchian US 10191854 (hereinafter Tootoonchian ).
As to claim 1, Bayon teaches a method for storing data in a database in a devalued format, the method comprising:
converting a string of data into a plurality of discrete chunks of data, wherein said string of data represents sensitive data ,whereas individual each chunk of data is non-sensitive; wherein said plurality of chunks of data, when collated, forms said string of data (Figure 4 and paragraphs 46-48 disclose credit card number /sensitive data “sd” as “4444” “3333” “2222” “111” . The credit card number spacing between “4444”, “3333”, “2222”, and “1111” as shown in Figure 4 provided separated chunks (credit card number is separated in chunks for readability and function). The sensitive data 410 is converted into a plurality of chunks which is denoted as the tokenized sensitive data, reference number 430, and is “6628”, “7218”, “8657”, and “2974”. Each of the converted chunks of data is non-sensitive, and when said plurality of chunks of data is collated, it forms the string “6628 7218 8657 2974”);
a system (Figures 1 and 2 disclose a system that comprises a Token Server 130/230, database 150/250 and HSM 140/240) receiving, at an [interface endpoint] a first chunk of data, of said plurality of chunks of data, sent from a client computer (paragraph 30 discloses a client device transmit a tokenization request comprising sensitive data to a server. The tokenized sensitive data in the request is the chunk of data sent from the client device 110/210 (Note: The client devices are shown in Figure 1 depicted as reference numbers 110 and 120, see paragraph 23. Paragraph 81 discloses the client device 110 or computing device 120 may be implemented by one or more computer devices). The sensitive data is credit card number. Credit card number is separated in chunks for readability and function. The sensitive data 410 is converted into a plurality of chunks which is denoted as the tokenized sensitive data, reference number 430, and is “6628”, “7218”, “8657”, and “2974”. Paragraph 84 discloses a I/O interface that is a machine interface that couples the processor to other devices and system such as network and one or more external resources. The application works with the network and external resources by communicating via the I/O interface);
the system generating a by-value token and a by-reference token in response to the … chunk of data (paragraph 30 discloses the token server generates a sensitive data digest based on the sensitive data included in the tokenization request. The sensitive data digest is generated by performing a hash operation on the sensitive data[chunk of data] to generate the sensitive data digest. The sensitive data digest is the by-value token. Paragraphs 3-5 also reveal a token associated with the sensitive data[chunk of data] is generated by the system. This token is by-reference token);
the system transmitting the by-reference token to the client computer (paragraph 32 discloses the token server transmits the token(by-reference token) to the client device); and
the system [stores] the first chunk of data in the database in a table (paragraph 25 discloses that the database stores token mapping data that uniquely associates each token with a particular sensitive data (The sensitive data is credit card number. Credit card number is separated in chunks for readability and function). Figure 2 and paragraph 31 disclose the database 250 stores a mapping table 252 that comprises the sensitive data “sd” and the token “tk”. Paragraph 70 further discloses that for the databases each relational element of the plurality of relational elements maps to: (i) a given sensitive data digest (by-reference token) stored in the database and (ii) a given token digest (by-value token) stored in the database. In an embodiment, each relational element of the plurality of relational elements is an encrypted relational element. In an embodiment, each encrypted relational element maps to: (i) a given sensitive data digest stored in the database and (ii) a given token digest stored in the database. Figure 4 shows the relational element 430 is generated based on modulo of the sensitive data 410 and the token), and
wherein the data is devalued such that it remains non-sensitive (paragraph 30 discloses the request is tokenized; therefore, the sensitive data in the request that is received by the token server is tokenized, and non-sensitive) until the client computer sends the by-reference token which can be used with the by-value token to extract the first chunk of data from the database (paragraph 26 discloses the client/computing device 120 (of Figure 1) transmits to the token server a request that includes the by-reference token that was sent to client device 110. The token server submits a query based on the token to the database. The Token server determines a credit card information (that associated with the token based on a response to the query received from database. The sensitive data is credit card number. Credit card number is separated in chunks for readability and function). The Token server may then transmit a detokenization response including the credit card information to computing/client device (Note: The client devices are shown in Figure 1 depicted as reference numbers 110 and 120, see paragraph 23. Paragraph 81 discloses the client device 110 and computing device 120 may be implemented by one or more computer devices)).
Bayon does not teach a client computer converting a string of data into a plurality of discrete chunks of data; the system receiving at an API endpoint only a chunk of data; generating a by-value token and a by-reference token in response to the first chunk of data; the system indexing the first chunk of data in a database in a key-value table, wherein a first column and second column of the key-value table comprises the by-value token and the first chunk of data respectively; and wherein each of said plurality of chunks of data are sent from the client computer to respectively different API endpoints.
Neuman teaches a client computer converting a string of data into a plurality of discrete chunks of data (paragraph 15 discloses a computing device that divide secret data into multiple partitions. Paragraph 69 discloses user enters secret data which is divided into multiple parts by the mobile device); a system receiving, at an API endpoint (paragraph 66 discloses communication system may use an API object return from the authentication server), only a first chunk of data of said plurality of chunks of data sent from the client device (paragraph 15 discloses the computing device (second device) transmits a first of the multiple portions of secret data to an authentication server/system via the network); generating a by-value token and a by-reference token in response to the first chunk of data (paragraph 69 discloses user enters secret data which is divided into multiple parts by the mobile device. One portion of the user entered secret key is used to obtain a first portion of the symmetric decryption key. A network server uses another portion of the user entered secret data to retrieve the second portion of the symmetric key for decryption. For example, half of the password may be combined with system level data to obtain a half of the decryption key, such as by using that half of the password to decrypt a local block of data containing the half of the decryption key. Therefore, the system level data can be a by-value token and the half of the decryption key is the by-reference token); the system transmits the by-reference token to the client device (paragraph 69 and Figure 6 reveal the split key data/by reference token is returned to the mobile device).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the chunk of data in Bayon’s teachings of converting the string of data, generating a by-value token and a by-reference token in response to the chunk of data, and transmitting the by-reference token to the client device with Neuman’s teachings of using a first chunk from the plurality of chunks of data to provide an improve system for securing data on a mobile device that includes an encrypted data storage location (keystore or datastore) (paragraph 69 of Neuman).
The combination of Bayon in view of Neuman does not teach the system indexing the first chunk of data in a database in a key-value table wherein a first column and second column of the key-value table comprises the by-value token and the first chunk of data respectively and wherein each of said plurality of chunks of data are sent from the client computer to respectively different API endpoints.
Lindsay teaches receiving at an API endpoint a chunk of data (paragraph 6 discloses sensitive data can be sent via an API interface call from a data processing application to a tokenization provider system. Figure 1 and paragraph 54 also disclose credit card number that is partition into chunks) and further teaches the system indexing the first chunk of data in the database in a key-value table (paragraphs 85 and 205 discloses splitting a value/[data] of interest into multiple regions (one region is a first chunk, a second region is a second chunk…) and generating a token/index for each of the multiple regions. In some embodiments, a value of interest from the input single field of data, file, record, or document is stored with a corresponding token/index as a token-value pair in the secure data vault. The database in the secure data vault is a key-value or token-value table database).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the interface and table in Bayon’s method for storing date in view of Neuman’s teachings of using a first chunk from the plurality of chunks of data with the API endpoint and token/key-value table as taught by Lindsay to provide new types of security tokens that can be used in various data security systems (paragraph 7 of Lindsay).
The combination of Bayon in view of Neuman, and Lindsay does not teach wherein a first column and second column of the key-value table comprises the by-value token and a first chunk of data respectively and wherein each of said plurality of chunks of data are sent from the client computer to respectively different API endpoints.
Palgon teaches the system indexing the first chunk of data in the database in a key-value table (Figure 9 and column 15, lines 24-44 disclose database schema table of key index values corresponding to input data string. The data string/chunk of data are in column 906), wherein a first column and second column of the key-value table comprises the by-value token and a first chunk of data respectively (Figure 9 and column 15, lines 24-44 disclose database schema table of key index values corresponding to input data string. The first column 908 is the index column, the adjacent column(s) 904 comprise the hashed token value/by-value token, and the data chunk column is column 902 or 906. The tokenized string 902 shown in Figure 9 has a first chunk “1234”).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the interface and table in Bayon’s method for storing date in view of Neuman’s teachings of using a first chunk from the plurality of chunks of data and the API endpoint and key-value table as taught by Lindsay with Palgon’s teachings of the key-value table and content therein to provide secure and efficient management and utilization of sensitive data in data and transaction processing systems while maintaining the data formation and utilization by existing systems (column 1, lines 16-21and lines 48-50 of Palgon).
The combination of Bayon in view of Neuman, Lindsay, and Palgon does not teach, but Tootoonchian teaches wherein each of said plurality of chunks of data are sent from the client computer to respectively different API endpoints (column 10, lines 15-22 discloses the system is programmed to split the data block into multiple sections/chunks and save each portion of the data in a different LBA, calling the LBA API several times once for each portion of data block saved. Column 10, lines 10-22 reveals for many memory APIs, …a single data block may span a few different LBAs. Splitting the data block into multiple chunks and saving each portion of the data/chunks in a different LBA (different digital location). Figure 1 reveals data block API and LBA API. Therefore, data blocks are sent to data block API and LBA API depending on the memory type. Column 6, lines 30-35 discloses data block API preferably directly accesses primary memory using physical memory addresses and indirectly accesses second memory using LBA API, see Figure 6 which reveals requests to write data block to memory from thread. If its main memory, the data block is sent to main memory via data block API, else the copy of the data block is sent to LBA API to write to secondary memory).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the interface and table in Bayon’s method for storing date in view of Neuman’s teachings of first chunk from a plurality of chunks and the API endpoint and key-value table in Lindsay and Palgon’s teachings of the key-value table with Tootoonchian ’s teachings of sending plurality of data chunks to different API endpoints to provide a system and method to improve the manner in which data is accessed by an application (column 2, lines 5-7 of Tootoonchian ).
As to claim 4, the combination of Bayon in view of Neuman, Lindsay, Palgon, and Tootoonchian teaches wherein the database is a silo (Lindsay: paragraphs 75 and 79 disclose the utilizes content silos that contains sensitive data; thus provide the transfer of tokenized data between applications in an enterprise computing environment, wherein the data processing applications or other applications do not have access to the content silos and secure data vaults).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the interface and table in Bayon’s method for storing date in view of the API endpoint in view of Palgon’s teachings of the key-value table and content therein with Lindsay’s silos such that tokenized data can move between application in an enterprise computing environment without security restrictions that may slow processing time (paragraphs 75 and 79 of Lindsay).
As to claim 5, the combination of Bayon in view of Neuman, Lindsay, Palgon, and Tootoonchian teaches wherein the system is a tangible, non-transitory, machine-readable medium storing instructions that when executed by one or more processors effectuate operations (Bayon: paragraphs 6, 80, and 89 disclose a non-transitory computer-readable storage medium including computer-readable instructions is provided. Upon execution by a processor of a computing device, the computer-readable instructions cause the computing device to perform the method).
As to claim 6, the combination of Bayon in view of Neuman, Lindsay, Palgon, and Tootoonchian teaches wherein the by-value token is stored on a separate encrypted database (Bayon: Figure 2 and paragraph 31 disclose the database depicted as reference number 250 stores the by-value token in the mapping data table 252).
As to claim 7, the combination of Bayon in view of Neuman, Lindsay, Palgon, and Tootoonchian teaches wherein the by-value token and the first chunk of data are stored in a key-value format (Bayon: Figure 2 and paragraph 31 disclose the database depicted as reference number 250 stores the by-value token in the mapping data table 252. Paragraph 25 discloses that the database stores token mapping data that uniquely associates each token with a particular sensitive data. Figure 2 and paragraph 31 disclose the database 250 stores a mapping table 252 that comprises the sensitive data “sd” and the token “tk”. Paragraph 70 further discloses that for the databases each relational element of the plurality of relational elements maps to: (i) a given sensitive data digest (by-reference token) stored in the database and (ii) a given token digest (by-value token) stored in the database. In an embodiment, each relational element of the plurality of relational elements is an encrypted relational element. In an embodiment, each encrypted relational element maps to: (i) a given sensitive data digest stored in the database and (ii) a given token digest stored in the database. Figure 4 shows the relational element 430 is generated based on modulo of the sensitive data 410 and the token. Lindsay: paragraph 205 discloses the database can include key-value type). Motivation the same as the motivation presented in claim 1.
As to claim 9, the combination of Bayon in view of Neuman, Lindsay, Palgon, and Tootoonchian teaches wherein the database is a server (Bayon: paragraph 81 discloses the databases can be implemented via servers).
As to claim 10, the combination of Bayon in view of Neuman, Lindsay, Palgon, and Tootoonchian teaches wherein the server is a relational database management system (Bayon: paragraph 86 discloses the database (paragraph 81 discloses the database can be implemented via servers) can be arranged as a relational database and a database management system).
As to claim 11, the combination of Bayon in view of Neuman, Lindsay, Palgon, and Tootoonchian teaches wherein the key-value format is a table (Lindsay: paragraph 205 reveals the database can be key value type. Key value rely on structured tables ). Motivation similar to the motivation presented in claim 1.
As to claim 12, the combination of Bayon in view of Neuman, Lindsay, Palgon, and Tootoonchian teaches wherein the database is a NoSQL database (Lindsay: paragraph 205 disclose the database is a NoSQL table that utilize key-value type). Motivation similar to the motivation presented in claim 1.
As to claim 14, the combination of Bayon in view of Neuman, Lindsay, Palgon, and Tootoonchian teaches wherein the by-reference token is an opaque token (Bayon: paragraph 23 disclose the token may be implemented as a random number, a pseudo-random number. An opaque token contains no identifiable information and it a random string/number).
As to claim 15, the combination of Bayon in view of Neuman, Lindsay, Palgon, and Tootoonchian teaches wherein the database is encrypted by field-level encryption (Bayon: paragraph 28 discloses algorithms suitable for implementing the encryption algorithm and/or the decryption algorithm include: Advanced Encryption Standard (AES) algorithms; Data Encryption Standard (DES) algorithms; Digital Signature Algorithm (DSA) algorithms; Rivest-Shamir-Adleman (RSA) algorithms. The data in the database is encrypted, see paragraph 44).
As to claim 18, the combination of Bayon in view of Neuman, Lindsay, Palgon, and Tootoonchian teaches wherein the client computer is a mobile phone hosting an application software (Bayon: paragraph 19 discloses the computing device utilizes a cellular networks. Mobile phone utilizes cellular networks).
As to claim 19, the combination of Bayon in view of Neuman, Lindsay, Palgon, and Tootoonchian teaches wherein the client computer sends the chunk of data to the API endpoint via an encrypted means (Bayon: paragraph 30 discloses a client device transmit a tokenization request comprising sensitive data to a server. The tokenized sensitive data in the request is the chunk of data sent from the client device 110/210 (Note: The client devices are shown in Figure 1 depicted as reference numbers 110 and 120, see paragraph 23. Paragraph 81 discloses the client device 110 and computing device may be implemented by one or more computer devices). Paragraph 84 discloses the I/O interface that a machine interface that couples the processor to other devices and system such as network and one or more external resources. The application work with the network and external resources by communicating via the I/O interface. Lindsay: paragraph 6 discloses sensitive data can be sent via an API interface call from a data processing application to a tokenization provider system). Motivation the same motivation presented in claim 1.
Claim(s) 2 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bayon et al US 20210167959 (hereinafter Bayon), in view of Neuman et al US 20160294821 (hereinafter Neuman), in further view of Lindsay US 20220067205 (hereinafter Lindsay), in further view of Palgon et al US 8458487 (hereinafter Palgon), in further view of Tootoonchian US 10191854 (hereinafter Tootoonchian ), and in further view of Singhal US 20020002533 (hereinafter Singhal).
As to claim 2, the combination of Bayon in view of Neuman, Lindsay, Palgon, and Tootoonchian teaches all the limitation presented in claim 1 above, but does not teach each of said plurality of chunks of data are respectively indexed in different databases.
Singhal teaches each of said plurality of chunks of data are respectively indexed in different databases (paragraph 65 discloses card number may be partitioned as partial data elements into separate databases).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the interface and table in Bayon’s method for storing date in view of Neuman’s teachings of first chunk from a plurality of chunk, the API endpoint and key-value table in Lindsay, Palgon’s teachings of the key-value table, and Tootoonchian ’s teachings of sending plurality of data chunks to different API endpoints with Singhal’s teachings of providing chunks of data in different databases to provide a further level of security for protecting the privacy and private data of a customer in data storage and during transaction (paragraph 2 of Singhal).
Claim(s) 8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bayon et al US 20210167959 (hereinafter Bayon), in view of Neuman et al US 20160294821 (hereinafter Neuman), in further view of Lindsay US 20220067205 (hereinafter Lindsay), in further view of Palgon et al US 8458487 (hereinafter Palgon), in further view of Tootoonchian US 10191854 (hereinafter Tootoonchian ), and in further view of Thorpe et al US 20110010612 (hereinafter Thorpe).
As to claim 8, the combination of Bayon in view of Neuman, Lindsay, Palgon, and Tootoonchian teaches all the limitation presented in claim 1 above including the API endpoint (see claim 1 above). The combination of Bayon in view of Neuman, Lindsay, Palgon, and Tootoonchian does not teach, but Thorpe teaches that the API endpoint is identified by a unique uniform resource locator (paragraph 68 discloses API function calls made from the middleware application of a phone to the kernel through the API. An application on a mobile phone makes a function call to the kernel commanding it to address the communication interface and cause it to transmit out to the internet a URL passed to the kernel with the API function call. The application has an API which allows the kernel to call its middleware application and pass it commands or data received from components in the phone).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the interface and table in Bayon’s method for storing date in view of Neuman’s teachings of first data chunk from a plurality of data chunks and the API endpoint and key-value table in Lindsay, Palgon’s teachings of the key-value table, and Tootoonchian’s teachings of sending plurality of data chunks to different API endpoints with Thorpe’s API identified by URL such that an application program and supporting systems and tools can efficiently and rapidly communicate and share data via the network (paragraph 10 of Thorpe).
Claim(s) 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bayon et al US 20210167959 (hereinafter Bayon), in view of Neuman et al US 20160294821 (hereinafter Neuman), in further view of Lindsay US 20220067205 (hereinafter Lindsay), in further view of Palgon et al US 8458487 (hereinafter Palgon), in further view of Tootoonchian US 10191854 (hereinafter Tootoonchian ), and in further view of Welch et al US 20200034463 (hereinafter Welch).
As to claim 13, the combination of Bayon in view of Neuman, Lindsay, Palgon, and Tootoonchian teaches all the limitation presented in claim 1 above including the by-value token (see claim 1 above, wherein Bayon: paragraph 30 discloses the token server generates a sensitive data digest based on the sensitive data included in the tokenization request. The sensitive data digest is generated by performing a hash operation on the sensitive data to generate the sensitive data digest. The sensitive data digest is the by-value token. Paragraphs 3-5 reveal a token associated with the sensitive data is generated by the system. This token is by-reference token).
The combination of Bayon in view of Neuman, Lindsay, Palgon, and Tootoonchian does not teach, but Welch teaches wherein the [data] is in JSON Web Token format (paragraph 64 discloses the data in the table may be include JSON description of the data).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the interface and table in Bayon’s method for storing date in view of Neuman’s teachings of a first data chunk from a plurality of data chunks and the API endpoint and key-value table in Lindsay, Palgon’s teachings of the key-value table, and Tootoonchian ’s teachings of sending plurality of data chunks to different API endpoints with Welch’s data in JSON format to improve the processing capabilities and quality of the data in the table and new data added to the table without any alternation of adjustment by the computing system (paragraph 43 of Welch).
Claims 16 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bayon et al US 20210167959 (hereinafter Bayon), in view of Neuman et al US 20160294821 (hereinafter Neuman), in further view of Lindsay US 20220067205 (hereinafter Lindsay), in further view of Palgon et al US 8458487 (hereinafter Palgon), in further view of Tootoonchian US 10191854 (hereinafter Tootoonchian ), and in further view of Fahey et al US 20150156174 (hereinafter Fahey).
As to claim 16, the combination of Bayon in view of Neuman, Lindsay, Palgon, and Tootoonchian teaches all the limitation presented in claim 1. The combination of Bayon in view of Neuman, Lindsay, Palgon, and Tootoonchian does not teach, but Fahey teaches wherein the database is encrypted by full database encryption (paragraph 48 discloses the data storage service includes data encryption system such that any data received is first encrypted and then stored in the data storage (which according to paragraph 29 the data storage service operate using computing resources such as databases).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the interface and table in Bayon’s method for storing date in view of Neuman’s teachings of a first data chunks from a plurality of data chunks and the API endpoint and key-value table in Lindsay, Palgon’s teachings of the key-value table, and Tootoonchian ’s teachings of sending plurality of data chunks to different API endpoints with Fahey’s database encryption to provide encrypted storage system that is unable to be access by unauthorized parties (paragraph 28 of Fahey).
As to claim 20, the combination of Bayon in view of Neuman, Lindsay, Palgon, and Tootoonchian teaches all the limitation presented in claim 1 above, but does not teach wherein the client computer is encrypted.
Fahey teaches wherein the client computer is encrypted (paragraph 17 discloses the client encrypted separately encrypt each data chunk using a cryptographic key).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the interface and table in Bayon’s method for storing date in view of Neuman’s teachings of first chunk from a plurality of chunks and the API endpoint and key-value table in Lindsay, Palgon’s teachings of the key-value table, and Tootoonchian ’s teachings of sending plurality of data chunks to different API endpoints with Fahey’s encryption to provide secure data that is unable to be access by unauthorized parties (paragraph 28 of Fahey).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to FELICIA FARROW whose telephone number is (571)272-1856. The examiner can normally be reached M - F 7:30am-4:00pm (EST).
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Alexander Lagor can be reached at (571)270-5143. 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.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to FELICIA FARROW whose telephone number is (571)272-1856. The examiner can normally be reached M - F 7:30am-4:00pm (EST).
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Alexander Lagor can be reached at (571)270-5143. 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.
/F.F/Examiner, Art Unit 2437
/BENJAMIN E LANIER/Primary Examiner, Art Unit 2437
Prosecution Insights