DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This office action is in response to communication (amendment) filed on 06/17/2026.
Status of claims in the instant application:
Claims 1-20 are pending.
No claim has been canceled.
No new claim has been added.
Claims 1, 4, 5, 7, 8, 11, 12, 14, 15, 18 and 19 have been amended.
Information Disclosure Statement
Information Disclosure Statements (IDS) filed on 06/16/2026 and 04/28/2026 have been considered, and a signed copies of the IDS forms have been attached to this office action.
Response to Arguments
Applicant’s arguments, see pages [9-13] of the remarks filed on 06/17/2026, with respect to claim(s) under 35 USC 103 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Furthermore, Applicant’s claim amendments have rendered new grounds for rejection.
Applicant is also requested to consult the prior arts provided, but not used in rejecting the claims, with this office, specifically the ones under the Pertinent Prior Arts section at the end of this office action.
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 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.
Claims 1-3, 8-10 and 15-17 are rejected under 35 U.S.C. 103 as being unpatentable over Pat. No.: US 11924169 B1 to Yoskowitz et al. (hereinafter “Yoskowitz”) in view of Pub. No.: US 20240340476 A1 to Costa et al. (Costa) and further in view of Pub. No.: US 20230252137 A1 to YAO et al. (hereinafter “YAO”).
Regarding Claim 1. Yoskowitz discloses A method (Yoskowitz, Abstract: … Systems and techniques provide activity monitoring and selective obfuscation of various fields or categories of information included in traffic between servers providing services and end-user devices accessing such services …) comprising:
receiving, at an edge device in a computer network, data [from one or more central servers associated with an organization to which the edge device belongs, the data] specified for an intended recipient device and user, [the edge device including a hardware secure module], wherein the intended recipient device is located more proximate to the edge device than to the one or more central servers (Yoskowitz, Abstract; FIG. 1, 2, 8A-B; col.1,ln.32-67; col.9,ln.30-41; col.19.ln.44-53: … The obfuscation engine may receive traffic responsive to the request (block 865). For example, staying with the example in which the request is a request for information pertaining a customer of interest, the responsive traffic may include any one or more of the following pieces of information: the customer's name, email address, home address, account balance, credit card number, phone number, date of birth, etc. The traffic may be formatted such that it includes one or more fields, each pertaining to a different one of the pieces of information (e.g., a name field, an email address field, etc.) … the obfuscation engine 105 may examine the response to determine the role of the user linked with the end-user device to which the response is addressed. For example, if the request originated from the UI 101a, the role (or a unique identifier linked to the role) may be passed to the obfuscation engine 105 from the traffic routing tool 103a. The role may be linked to log-in credentials (e.g., username and/or password) entered by a user of the end-user device implementing the UI 101a. In an embodiment, the role may be linked to a device ID for the end-user device. In any event, if desired, the obfuscation engine 105 is configured to determine a role associated with a request or traffic responsive to a request … in operation, a proxy server implementing an obfuscation engine may receive traffic from a server that is responsive to a request that the obfuscation engine received from an end-user device and forwarded to the server. The obfuscation engine may analyze the traffic using a set of rules to determine whether the traffic includes categories or fields of information that should be obfuscated and to selectively obfuscate the portions of the traffic corresponding to those categories or fields …), [wherein the organization comprises a plurality of edge devices distributed across a plurality of local area networks, and wherein the edge device and the intended recipient device are connected through a local area network of the plurality of local area networks];
prior to transmitting the data to the intended recipient device, the edge device:
determining one or more data parameters, including: a user role of the recipient user, and a [device type of the] recipient device (Yoskowitz, Abstract, FIG. 8B; col.1,ln.32-67; col.2,ln.18-57; col.9,ln.12-42; col.11,ln.45-59; col.19,ln.54-67: … The described methods and systems enable activity monitoring and selective obfuscation of various fields or categories of information included in traffic between servers providing services and end-user devices accessing such services. The selective obfuscation may account for a user's role and one or more levels of authorization or permission assigned to such a role … a system administrator can customize which services should be monitored, which rules should be applied to each service, and which roles (e.g., roles of an organization of the system administrator) should be restricted from accessing certain portions of the traffic. For example, a rule can be defined that obfuscates email addresses (e.g., by replacing an email address with asterisks or an alias), applies to users having a particular role at the organization, and applies to several different (or all) services (e.g., Redash, Salesforce, Hubspot, etc.). Staying with this example, if an end-user device linked to a user having the particular role requests information from any one of these different services, the end-user device will display obfuscated email addresses instead of displaying the actual email addresses (or may simply displaying nothing at all for email fields) … The end-user device 210 is a computing device such as a mobile phone, tablet, laptop, desktop, etc.) … a proxy server implementing an obfuscation engine may receive traffic from a server that is responsive to a request that the obfuscation engine received from an end-user device and forwarded to the server. The obfuscation engine may analyze the traffic using a set of rules to determine whether the traffic includes categories or fields of information that should be obfuscated and to selectively obfuscate the portions of the traffic corresponding to those categories or fields … After receiving the traffic, the obfuscation engine may analyze the traffic and a set of rules (e.g., the rules 244) to obfuscate at least some data in the traffic, thereby creating selectively obfuscated traffic (block 870). Specifically, the set of rules may specify certain categories or fields of data (e.g., credit card information) that should be obfuscated. For example, the UI 300 shown in FIG. 3 includes fields 311-319. In the shown example, the request related to records for customers 321, 325, and 325. As shown, the obfuscation engine determined that the set of rules 244 indicates that the fields 313 and 316 should be obfuscated. The set of rules may specify that the fields or categories 313 and 316 should always be obfuscated. In an embodiment, analyzing the set of rules includes analyzing a role assigned to a user of the end-user device and permissions assigned to the roles. Example roles may include any suitable role, such as sales role, executive role, human resources (HR) role, accounting role, etc. In short, each role may need different information relating to information handled at the service …);
However, Yoskowitz does not explicitly teach, but Costa from same or similar field of endeavor teaches:
“receiving data from one or more central servers associated with an organization to which the edge device belongs, the data (Costa, FIG. 1, Para [0047, 0119]: … As noted above, the plurality of user devices 306A-306D may request particular content hosted by the origin server 302 by submitting user requests to the plurality of edge servers 304A-304C. Reference character “306” will be used herein as referring to any one of plurality of user devices 306A-306D, or any other user device. A user device 306 may be, for example, a mobile phone, or a tablet, or a laptop, or a personal computer, etc. A user device 306 may include a processor for performing the operations of the user device 306 (e.g., by executing instructions stored in a program memory of the user device 306), a network interface (e.g., a transmitter/receiver with an antenna or a network interface card or a port) for communicating with the origin server 302 and the plurality of edge servers 304A-304C …);
wherein the organization comprises a plurality of edge devices distributed across a plurality of local area networks, and wherein the edge device and the intended recipient device are connected through a local area network of the plurality of local area networks (Costa, FIG. 1, Para [0047, 0119]: … the plurality of user devices 306A-306D may request particular content hosted by the origin server 302 by submitting user requests to the plurality of edge servers 304A-304C. Reference character “306” will be used herein as referring to any one of plurality of user devices 306A-306D, or any other user device. A user device 306 may be, for example, a mobile phone, or a tablet, or a laptop, or a personal computer, etc. A user device 306 may include a processor for performing the operations of the user device 306 (e.g., by executing instructions stored in a program memory of the user device 306), a network interface (e.g., a transmitter/receiver with an antenna or a network interface card or a port) for communicating with the origin server 302 and the plurality of edge servers 304A-304C … While the disclosure throughout contemplates that a ‘merchant’ and a ‘customer’ may be more than individuals, for simplicity the description herein may generally refer to merchants and customers as such. All references to merchants and customers throughout this disclosure should also be understood to be references to groups of individuals, companies, corporations, computing entities, and the like, and may represent for-profit or not-for-profit exchange of products. Further, while the disclosure throughout refers to ‘merchants’ and ‘customers’, and describes their roles as such, the e-commerce platform 100 should be understood to more generally support users in an e-commerce environment, and all references to merchants and customers throughout this disclosure should also be understood to be references to users, such as where a user is a merchant-user (e.g., a seller, retailer, wholesaler, or provider of products), a customer-user (e.g., a buyer, purchase agent, consumer, or user of products), a prospective user (e.g., a user browsing and not yet committed to a purchase, a user evaluating the e-commerce platform 100 for potential use in marketing and selling products, and the like), a service provider user (e.g., a shipping provider 112, a financial provider, and the like), a company or corporate user (e.g., a company representative for purchase, sales, or use of products; an enterprise user; a customer relations or customer management agent, and the like), an information technology user, a computing entity user (e.g., a computing bot for purchase, sales, or use of products), and the like. Furthermore, it may be recognized that while a given user may act in a given role (e.g., as a merchant) and their associated device may be referred to accordingly (e.g., as a merchant device) in one context, that same individual may act in a different role in another context (e.g., as a customer) and that same or another associated device may be referred to accordingly (e.g., as a customer device) …);
role of the recipient user, and a device type of the recipient device (Costa, Para [0018-0119]: … FIG. 8 illustrates an example e-commerce platform 100, according to one embodiment. The e-commerce platform 100 may be used to provide merchant products and services to customers. While the disclosure contemplates using the apparatus, system, and process to purchase products and services, for simplicity the description herein will refer to products. All references to products throughout this disclosure should also be understood to be references to products and/or services, including, for example, physical products, digital content (e.g., music, videos, games), software, tickets, subscriptions, services to be provided, and the like … Furthermore, it may be recognized that while a given user may act in a given role (e.g., as a merchant) and their associated device may be referred to accordingly (e.g., as a merchant device) in one context, that same individual may act in a different role in another context (e.g., as a customer) and that same or another associated device may be referred to accordingly (e.g., as a customer device) …)”
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Costa into the teachings of Yoskowitz, because it discloses that, “The e-commerce platform 100 may provide for a communications facility 129 and associated merchant interface for providing electronic communications and marketing, such as utilizing an electronic messaging facility for collecting and analyzing communication interactions between merchants, customers, merchant devices 102, customer devices 150, POS devices 152, and the like, to aggregate and analyze the communications, such as for increasing sale conversions, and the like. For instance, a customer may have a question related to a product, which may produce a dialog between the customer and the merchant (or an automated processor-based agent/chatbot representing the merchant), where the communications facility 129 is configured to provide automated responses to customer requests and/or provide recommendations to the merchant on how to respond such as, for example, to improve the probability of a sale (Costa, Para [0131])”.
Yoskowitz further discloses:
“identifying one or more data management policies applicable to the one or more data parameters (Yoskowitz, Abstract, FIG. 8B; col.19,ln.54-67: … The set of rules may specify that the fields or categories 313 and 316 should always be obfuscated. In an embodiment, analyzing the set of rules includes analyzing a role assigned to a user of the end-user device and permissions assigned to the roles. Example roles may include any suitable role, such as sales role, executive role, human resources (HR) role, accounting role, etc. In short, each role may need different information relating to information handled at the service. For example, accounting roles may have permission to view financial information (e.g., credit card numbers, account balances, etc.), but sales roles may not have permission to view financial information. In any event, the obfuscation engine may selectively obfuscate traffic based on the role assigned to the end-device (or user of the end-device) that will be receiving the traffic …);
determining, based on the one or more data management policies, that data obfuscation is required ((Yoskowitz, Abstract, FIG. 8A col.17,ln.58-67: … The traffic routing tool may analyze the network address and a set of rules to determine whether or not the request should be routed to an obfuscation engine (e.g., 105 or 205) (block 815). The traffic routing tool may analyze a set of rules (e.g., the rules 224) listing network addresses for services that should be routed through an obfuscation engine … Based on the results of block 815, the traffic routing tool determines whether or not to route the request to an obfuscation engine (block 820) … When the analysis indicates that the rules indicate that the network address is a service associated with the obfuscation engine, the traffic routing tool routes the request to the obfuscation engine (block 830)… In some embodiments, the obfuscation engine is implemented on the same device as the traffic routing tool (e.g., both may be implemented on a proxy server, wherein all employee traffic is routed from the end-user devices through the proxy server) …);
electronically modifying one or more portions of the data to obfuscate information included in the one or more portions of the data based on the one or more data management policies (Yoskowitz, Abstract, FIG. 8B; col.19,ln.54-67: … The set of rules may specify that the fields or categories 313 and 316 should always be obfuscated … the obfuscation engine may selectively obfuscate traffic based on the role assigned to the end-device (or user of the end-device) that will be receiving the traffic …); and
transmitting the electronically modified data to the intended recipient device (Yoskowitz, Abstract, FIG. 8B; col.20,ln.13-18: … After selectively obfuscating the traffic, the obfuscation engine may transmit the selectively obfuscated traffic to the end-user device that originally transmitted the request (block 875). The selectively obfuscated traffic may be transmitted in a manner that enables the end-user device to determine that the traffic is responsive to the original request …).
However, the combination of Yoskowitz-Costa does not explicitly teach, but YAO from same or similar field of endeavor teaches:
“the edge device including a hardware secure module (YAO, Para [0030]: … The ODSS backend 104 is behind a second firewall 112 and provides protected access to the ODSS database 114 and the data signing keys that are stored in an ODSS hardware security module (HSM) 116. It is used to access the ODSS hierarchical entities discussed below and to look up user permissions for different data signing configurations and to perform all authorized crypto operations. The ODSS backend 104 connects to ODSS HSM 116 and using the ODSS HSM 116, performs operations such as data signing, encryption, decryption, and obfuscation. Obfuscation involves the transformation of a human-readable string into a string that is difficult to understand. Unlike encryption, it does not include a cryptographic key. The ODSS backend 104 may implement a plurality of software layers including, from the top software layer to the bottom software layer, an ODSS Service Layer 126, a Business Logic Layer (BLL) 122 and a Data Access Layer (DAL) 124 …)”
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of YAO into the combined teachings of Yoskowitz-Costa, because it discloses that, “systems and methods useable in an online data signing system to detect and then prevent, reduce, or stop excessive use or abuse based on usage pattern, pre-configured usage quota, thus improving system security and preventing revenue loss (YAO, Para [0022])”.
Regarding Claim 2. The combination of Yoskowitz-Costa-YAO discloses the method of claim 1, Yoskowitz further discloses, “wherein electronically modifying one or more portions of the data to obfuscate information included in the one or more portions of the data includes:
replacing the information to be obfuscated with a token, the token including a unique set of characters (Yoskowitz; col.2,ln.18-67; col.7,ln.48-67: … the obfuscation engine can receive and analyze traffic from multiple different servers, each of which may implement a different service and format server responses differently. Using the administrator tool, a system administrator can customize which services should be monitored, which rules should be applied to each service, and which roles (e.g., roles of an organization of the system administrator) should be restricted from accessing certain portions of the traffic. For example, a rule can be defined that obfuscates email addresses (e.g., by replacing an email address with asterisks or an alias), applies to users having a particular role at the organization … There may be several levels of obfuscation or restriction configurable via the administrator tool, and the options may vary based on the category of information. For example, one level of obfuscation may be “fully obfuscate,” which refers to replacing all of the information for a given field with asterisks or another symbol such that none of the original information is readable …) or a link to a network site.”
Regarding Claim 3. The combination of Yoskowitz-Costa-YAO discloses the method of claim 1, Yoskowitz further discloses, “wherein electronically modifying one or more portions of the data to obfuscate information included in the one or more portions of the data includes:
making the information to be obfuscated by deleting the information (Yoskowitz; col.23,ln.1-20: … modifying the traffic may include obfuscating the information … modifying the traffic may include removing the information from the field …) or redacting the information.”
Regarding Claim 8: This claim contains all the same or similar limitations as claim 1, hence similarly rejected as claim 1.
*** Note: YAO, in combination with Yoskowitz, also disclose a “a hardware security module computing one or more hardware-secure cryptoprocessors; and memory storing computer-readable instructions that causes the processor to perform the claimed functions (YAO, Para [0009, 0030, 0116])”
Regarding Claim 9: This claim contains all the same or similar limitations as claim 2, hence similarly rejected as claim 2.
Regarding Claim 10: This claim contains all the same or similar limitations as claim 3, hence similarly rejected as claim 3.
Regarding Claim 15: This claim contains all the same or similar limitations as claim 1, hence similarly rejected as claim 1.
*** YAO, in combination with Yoskowitz, also discloses, “A non-transitory computer-readable medium storing computer-readable instructions that, when executed, cause a hardware-secure edge device comprising at least one hardware-secure cryptoprocessor ((YAO, Para [0009, 0030, 0116]))”
Regarding Claim 16: This claim contains all the same or similar limitations as claim 2, hence similarly rejected as claim 2.
Regarding Claim 17: This claim contains all the same or similar limitations as claim 3, hence similarly rejected as claim 3.
Claims 6, 13 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Pat. No.: US 11924169 B1 to Yoskowitz et al. (hereinafter “Yoskowitz”) in view of Pub. No.: US 20240340476 A1 to Costa et al. (Costa) and Pub. No.: US 20230252137 A1 to YAO et al. (hereinafter “YAO”), as applied to claim 1, and further in view of No.: US 20200285631 A1 to Kwatra et al. (hereinafter “Kwatra”).
Regarding Claim 6. The combination of Yoskowitz-Costa-YAO discloses the method of claim 1, however it does not explicitly teach but Kwatra from same or similar field of endeavor teaches:
“wherein electronically modifying one or more portions of the data to obfuscate information included in the one or more portions of the data includes:
identifying one or more smart contracts in a blockchain corresponding to the one or more data management policies (Kwatra, Para [0037, 0131]: … The present application creates a functional improvement by providing a flexible and automated way to define the endorsing requirements based on contextual and historical data. The approach not only enables the specification of endorsing policies (endorsing requirements) based on the topology of the blockchain network, smart-contract requirements, involved parties, etc., but also provides a way to auto-adjust such requirements … The files 774.sub.2 to 774.sub.N in the other blocks may be equal to the original file or may be a modified version of the original file in the genesis block depending, for example, on the type of processing performed. The type of processing performed may vary from block to block. The processing may involve, for example, any modification of a file in a preceding block, such as redacting information or otherwise changing the content of, taking information away from, or adding or appending information to the files …); and
invoking the one or more smart contracts to perform the electronic modification of the one or more portions of the data (Kwatra, Para [0131-0134]: … the processing may involve merely copying the file from a preceding block, changing a storage location of the file, analyzing the file from one or more preceding blocks, moving the file from one storage or memory location to another, or performing action relative to the file of the blockchain and/or its associated metadata … For example, consider the case where portions of the file in a previous block are redacted, blocked out, or pixelated in order to protect the identity of a person shown in the file. In this case, the block including the redacted file will include metadata associated with the redacted file, e.g., how the redaction was performed, who performed the redaction, timestamps where the redaction(s) occurred, etc. The metadata may be hashed to form the value. Because the metadata for the block is different from the information that was hashed to form the value in the previous block, the values are different from one another and may be recovered when decrypted …).”
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Kwatra into the combined teachings of Yoskowitz-Costa-YAO, because it discloses that, “The present application creates a functional improvement by providing a flexible and automated way to define the endorsing requirements based on contextual and historical data. The approach not only enables the specification of endorsing policies (endorsing requirements) based on the topology of the blockchain network, smart-contract requirements, involved parties, etc., but also provides a way to auto-adjust such requirements (Kwatra, Para [0037])”.
Regarding Claim 13: This claim contains all the same or similar limitations as claim 6, hence similarly rejected as claim 6.
Regarding Claim 20: This claim contains all the same or similar limitations as claim 6, hence similarly rejected as claim 6.
Allowable Subject Matter
Claims 4-5, 7, 11-12, 14 and 18-19 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
As allowable subject matter has been indicated, applicant's reply must either comply with all formal requirements or specifically traverse each requirement not complied with. See 37 CFR 1.111(b) and MPEP § 707.07(a).
Reasons for allowance will be furnished upon allowance.
Pertinent Prior Arts
The following prior arts made of record and not relied upon are considered pertinent to applicant's disclosure.
US 20140013451 A1; Kulka et al.: Kulka discloses Techniques and configurations for implementing data obfuscation for Representational State Transfer (RESTful) web service communications such as those communicated using an Open Data (OData) protocol are described. In one example embodiment, an obfuscation service includes an OData client, an OData server, and an OData obfuscation data server, the obfuscation service operating to intercept and process OData web service requests being transmitted from requesting clients to backend enterprise data services. The obfuscation service may include or integrate with an obfuscation engine, including a context engine, a rules engine, and a hierarchical mapping engine to determine rules for data obfuscation based on determined context and hierarchical mappings. The obfuscation service may apply the determined rules to provide specific access control and data obfuscation results of data retrieved from the backend enterprise services.
Ideally, data obfuscation can be provided on a data field level, based not only on user roles, but also on dynamic aspects, such a user location (e.g., Global Positioning System (GPS) coordinates of a user mobile device), user security level, or user device type. Further, systems such as defense-critical system may even want to show varying levels of "misleading information" or otherwise conceal the use of data obfuscation. This level of detailed access control is particularly complex if not impossible with rule-exclusive approaches.
US 10867063 B1 Avanes et al.: Avanes discloses A shared database platform implementing dynamic masking on data shared between users where specific data is masked, transformed, or otherwise modified based on preconfigured functions that are associated with user roles. The shared database platform can implement the masking at runtime dynamically in response to users requesting access to a database object that is associated with one or more masking policies.
US 20170116428 A1; Wu et al.: Wu discloses Systems and methods for supporting sharing the same table for protected and non-protected data columns. Different data object can be defined on the same database table. A discriminate flag can be defined to identify the data object to which a particular row belongs. The discriminate flag can be built into the data object so that rows belong to the data object are picked up during a query. Data protection can then be configured at the data object level so that rows that belong to the data object are subject to protection such as encryption or tokenization.
In some embodiments, security authentication may be determined based on a role associated with a user requesting a service. The role may be associated with a user requesting access to MCS 122. In some embodiments, a user may request services as a subscriber or tenant of MCS 122 who may be granted access to resources and/or services provided by MCS 122. Authentication may correspond to a user's subscription to MCS 122, such that a user may be authorized to request services via MCS 122 as a subscriber. In some embodiments, the subscription may be limited to a particular set of resources provided by MCS 122. Security authentication may be based on the resources and/or services accessible to the user of MCS 122. In some embodiments, a request may be provisioned a template during execution called a “runtime environment.” The runtime environment may be associated with resources that are allocated for a request, a user, or a device.
US20210157953 A1; Stark; Jay: Stark discloses techniques that provide privacy protection for a user by preventing user device tracking via device fingerprints. A communication may be received from a user device that includes metadata having information related to the user device. An intended recipient of the communication may be identified. Based on one or more of the user device or the recipient, a determination may be made as to what data within the metadata should be scrambled or selectively replaced. The data may then be overwritten with alternative data that may be selected at random, and the communication is forwarded to the recipient.
US 20250053685 A1; Hall et al.: Hall discloses methods and systems for secure data communication amongst computer systems. Encrypted data in a first format is accessed over a secure communication channel from a first source for a first subject. Encrypted data in a second format is accessed over a secure communication channel from a second source for the first subject. The encrypted data in the first format from the first source and in the second format from the second source is decrypted. The decrypted data in the first format from the first source and in the second format from the second source is converted to a third format. At least partly in response to the request for information from a first system, at least a portion of the data from the first source and the second source is accessed from a database The accessed data is transmitted in encrypted form to the first system.
For example, the data may be encrypted before storing it in the database. This ensures that even if someone gains access to the physical storage or backups, the data remains unreadable without the appropriate decryption keys. Encryption keys used to encrypt data may be managed using hardware security modules (HSMs). The data may also be encrypted (e.g., using the HTTPS, SSL/TLS, and SSH protocols) while it's being transmitted between a given application disclosed herein and the database to prevent interception or eavesdropping. Role-based access control (RBAC) may be utilized where roles are assigned to users and access permissions are granted based on such roles. A given user may only be permitted to access data and operations necessary for their responsibilities. In addition, attribute-based access control (ABAC) may be utilized where access is controlled based on specific attributes or conditions, such as user roles, location, time, and data sensitivity. Optionally, multi-factor authentication (MFA) may be utilized where users need to provide multiple forms of verification (e.g., password or a biometric input and a one-time code) to access the database. Data masking may optionally be utilized where a masked version of sensitive data is provided for display to users who don't have the necessary privileges to view the actual data. Data redaction may optionally be utilized where portions of sensitive data are permanently deleted or obscured when displaying it to certain users, even in query results. Logging mechanisms to record database activity and access attempts. A database firewall may be utilized to monitor and filter incoming and outgoing database traffic, preventing unauthorized access and suspicious queries. Optionally, the databases may be segmented to isolate different types of data. This minimizes the impact of a breach and limits access to sensitive information.
US 11818013 B1; Jia et al.: Jia discloses A processing system deployed in a communication network detecting a condition for merging at least a first logical network of the communication network and a second logical network of the communication network. The first logical network may be reserved for use by at least a first plurality of endpoint devices of at least a first public service entity, and the second logical network is reserved for use by at least a second plurality of endpoint devices of at least a second entity. The processing system may then merge the first logical network and the second logical network to create a merged logical network, in response to the detecting of the condition. The merging may include allocating a set of network resources to the merged logical network and authorizing the first plurality of endpoint devices and the second plurality of endpoint devices to access the merged logical network.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MAHABUB S AHMED whose telephone number is (571)272-0364. The examiner can normally be reached on 9AM-5PM EST M-F.
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, Ali Shayanfar can be reached on 571-270-1050. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MAHABUB S AHMED/Examiner, Art Unit 2434
/TESHOME HAILU/Primary Examiner, Art Unit 2434
Prosecution Insights